Information Lifecycle Management: Prozessimplementierung GERMAN

Xpert.press

Die Reihe Xpert.press vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Wolfgang Sollbach · Günter Thome

Information Lifecycle Management Prozessimplementierung

123

Wolfgang Sollbach Finkenweg 1 49536 Lienen [email protected]

ISBN 978-3-540-35838-1

Günter Thome Am Forsthof 20 52459 Inden [email protected]

e-ISBN 978-3-540-35841-1

DOI 10.1007/978-3-540-35841-1 ISSN 1439-5428 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2008 Springer-Verlag Berlin Heidelberg Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten waren und daher von jedermann benutzt werden dürften. Einbandgestaltung: KünkelLopka, Heidelberg Printed on acid-free paper 987654321 springer.com

Vorwort

Die erfolgreiche wirtschaftliche Entwicklung eines Unternehmens hängt in hohem Maße von qualifizierten und richtigen Entscheidungen ab, die vor dem Hintergrund eines beständigen organisatorischen Wandels zu treffen sind. Der Wandel sowohl im Wettbewerb als auch in der eigenen Unternehmensorganisation kann dabei Formen wie Prozessorientierung, Segmentierung oder Virtualisierung annehmen. Konventionelle IT-Architekturen betrieblicher Informationssysteme sind diesem beständigen Wandel, der auch bei Fusionen oder starkem Wachstum stattfindet, häufig nicht gewachsen. Eine effiziente und leistungsfähige ITInfrastruktur ist deshalb der Wunschtraum vieler Unternehmer.Nur die Unternehmen können schneller auf veränderte Geschäftsanforderungen reagieren, deren IT sich nach den Geschäftsprozessen richtet, die das jeweils benötigte Wissen in Form von geeignet aufbereiteten Informationen bereitstellt, und nicht umgekehrt. Basierend auf der Forderung nach strukturellen Analogien zwischen Unternehmensorganisationen und Informationssystemen wurden deshalb in den letzten Jahren eine Reihe unterschiedlicher Ansätze entwickelt, die von der stärkeren Integration (BI, EAI) über spezifische Ausrichtungen (mySAP) bis zum Outsourcing der gesamten Informationstechnologie reichen. Alle Ansätze werden mit der steigenden Komplexität der Informationstechnologie und der progressiven Kostenentwicklung des Sektors IT begründet. Kernthemen sind dabei Mainframe-Konzepte, Server-Architekturen und die Intelligenz von Clients, die Virtualisierung und die durchgängige Serviceorientierung der Software (SOA). Die dringend notwendige Entscheidungsobjektivierung auf Basis einer strukturierten Vorgehensweise, einer ganzheitlichen Problemsicht und durch den Einsatz pragmatischer Methodenbausteine ist jedoch erst dann gegeben, wenn auch die Speicherung und die Bereitstellung von Informationsservices gemäß den Anforderungen des Geschäftsprozesses die ihr gebührende Berücksichtigung in einer IT-Architektur findet. Moderne Speichersysteme sind längst mehr als nur einfache Festplatten. Mehr und mehr verlagert sich die Intelligenz aus dem Betriebssystem des Servers in das Speichersystem. Information Lifecycle Management (ILM), Hierarchical Storage Management (HSM) und viele andere aktuelle DV-Schlagwörter und DVVerfahren betrachten jedoch üblicherweise lediglich Techniken und Verfahren zur kostenangepassten Speicherung von Informationen gemäß ihrem Alterungsprozess. Dabei wird viel zu wenig auf die (gesetzlichen) Anforderungen und die betrieblichen Notwendigkeiten abgehoben,die Information Lifecycle Management

VI

Vorwort

(ILM) aus kaufmännischer und Gesamtunternehmenssicht erforderlich machen und auch selten die Intelligenz in den Speichersystemen betrachtet. Mit ILM wird der Information erstmals neben dem Charakter eines Produktionsfaktors auch die Eigenschaft eines Produktes zugestanden, das einem Lebenszyklus wie jedes andere Produkt unterliegt. Innerhalb der einzelnen Phasen dieses Zyklus muss die Information entsprechend ihrem Wert für das Unternehmen DV-technisch behandelt werden. Dieses Buch beschreibt, aufbauend auf den Innovationen im SAN (Storage Area Network) und im NAS (Network Attached Storage) sowie bei der Virtualisierungstechnologie, aufgrund welcher gesetzlichen und ökonomischen Grundlagen ILM ein Muss-Thema für jeden CIO eines jeden Unternehmens ist. Auf dieser Basis wird beschrieben, wie ein Projekt zur Implementierung eines ILM aufgesetzt und durchgeführt werden muss. Im Anschluss werden die technischen Realisierungsansätze der gängigen Hersteller dargestellt, mit denen diese auf die betrieblichen Anforderungen reagieren. Die beiden Bücher „Grundlagen und Modelle des Information Lifecycle Management (ILM)“ und „Information Lifecycle Management – Prozessimplementierung“ beschreiben sowohl den klassischen Ansatz der Information als Produktionsfaktor, der einen gewissen Lebenszyklus (Alterungsprozess) durchläuft, als auch den Ansatz, der der Information den Produktcharakter zugesteht und dabei die Information mit einem Produktlebenszyklus betrachtet. Ohne die Erweiterung der Sicht auf die Information würden neue Geschäftsmodelle keine Berücksichtigung finden, die heute lediglich auf dem Auffinden von Informationsinhalten und Quellen basieren – vgl. Google – , die aber in der nahen Zukunft immer größere Bedeutung auch in den Unternehmen gewinnen werden. Wissens- und Informationsmanagement ist für Unternehmen wertvoller denn je. „Man muss nicht alles wissen, man muss wissen, wo es steht“, sagt ein Sprichwort. Für eine höhere Effizienz und Produktivität steht heutzutage in den Unternehmen sowohl die „richtige“ Nutzung der Ressource Wissen im Vordergrund als auch die Vernetzung der Mitarbeiter, die über das Wissen verfügen. In der Praxis fehlt es jedoch häufig an der Umsetzung. Wie die Frauenhofer-Studie „Wissen und Information 2005“1 zeigt, halten immerhin 91 Prozent der Unternehmen das Thema für „wichtig“ bis „sehr wichtig“. Produkte und Dienstleistungen sind immer stärker wissensgetrieben. Information in Form von Wissen unterscheidet sich von allen anderen produktiven Ressourcen darin, dass sie auch ohne technischen Fortschritt teilweise extrem schnell veraltet. Die Kenntnisse und Erkenntnisse, auf die es ankommt, unterliegen schnellen, oft sogar abrupten Veränderungen. Das gilt etwa im Gesundheitswesen von der Pharmakologie bis zur Genetik oder in der Computerindustrie vom PC bis zum Internet. Selbstverständlich wird die Produktivität der Informationsverarbeitung nicht der einzige Wettbewerbsfaktor in der Weltwirtschaft sein. Es lässt sich jedoch absehen, dass dieser Faktor zumindest für die meisten Branchen in den entwickelten Ländern ausschlaggebend sein wird. Die hohe Wahrscheinlichkeit, mit der sich diese Vorhersage bewahrheitet, erfordert daher ein Umdenken 1

www.fraunhofer-studie.de

Vorwort

VII

bei den Unternehmen und ihren Führungskräften.Von großer Tragweite ist dabei, dass es auch zukünftig in der Weltwirtschaft sehr wettbewerbsintensiv und turbulent zugehen wird – nicht zuletzt als Folge der abrupten Veränderungen sowohl bei den Eigenschaften als auch bei den Inhalten der relevanten Information. Den Erfolg der besseren Integration der IT in den Geschäftsprozess zeigt der Vergleich der Produktivitätszuwächse zwischen den USA und Europa. In den letzten 12 Jahren konnten die US-Unternehmen pro eingesetzter Arbeitsstunde einen größeren Erfolg und damit einen deutlich höheren Produktivitätszuwachs erzielen als ihre europäischen Wettbewerber. Das Londoner Centre of Economic Performance (CEP) kam in einer aktuellen Analyse zu dem Ergebnis, dass die USUnternehmen einfach ihre Informationstechnologie besser nutzen. Vor dem Hintergrund der globalen Veränderungen werden sich die Informationsbedürfnisse von Unternehmen und Führungskräften ebenfalls rasch ändern. In den vergangenen Jahren lag der Schwerpunkt auf der Verbesserung der traditionellen Formen der Informationsvermittlung, bei der es fast ausschließlich darum geht, was sich innerhalb einer Organisation abspielt. Im Rechnungswesen – herkömmlich das Informationssystem schlechthin – werden die Vorgänge im Unternehmen nachgezeichnet,und darauf stützen sich die meisten Führungskräfte bislang bei ihren Entscheidungen. Die neueren Verbesserungen im Rechnungswesen,wie die Prozesskostenrechnung,die Balanced Scorecard und die Wertanalysen, zielen alle darauf ab, über das Geschehen im Unternehmen besser zu informieren. Auch die Daten, die von der Mehrzahl der neuen Informationssysteme hervorgebracht werden, dienen diesem Zweck. Und tatsächlich beziehen sich annähernd 90 Prozent oder mehr der von einem Unternehmen gesammelten Informationen auf unternehmensinterne Vorgänge. Doch eine erfolgreiche Strategie wird in zunehmendem Maße Informationen über Vorgänge und Bedingungen außerhalb der Organisation erfordern: Kenntnisse über Nichtkunden, über bislang weder vom Unternehmen noch von seinen Mitbewerbern genutzte Technologien, über noch nicht erschlossene Märkte und so weiter. Nur im Besitz solcher Informationen wird ein Unternehmen entscheiden können, wie es seine Ressourcen einsetzen muss, um Höchsterträge zu erzielen. Nur mit solchen Informationen kann das Unternehmen sich auf neue Situationen und Anforderungen einstellen, wie sie aus plötzlichen Verwerfungen in der Weltwirtschaft sowie aus der Art und den Inhalten der Information selbst hervorgehen. Die Entwicklung rigoroser Methoden zum Sammeln und Analysieren externer Informationen wird für Unternehmen und Informationsexperten zur Herausforderung. Information bringt Ressourcen in Bewegung. Dabei zeigt sich eine Besonderheit: Informationsarbeitern gehören die Produktionsmittel selbst. Denn anders als bei den Arbeitern, die in der industriellen Fertigung tätig sind, tragen Informationsarbeiter teilweise ihre Produktionsmittel in ihren Köpfen mit sich, wodurch sie natürlich zu jedem beliebigen Arbeitsplatz mitgenommen werden können. Wahrscheinlich ändern sich gleichzeitig fortwährend die Informationsbedürfnisse der Organisationen. Künftig stellen die für den Unternehmenserfolg in den entwickelten Ländern entscheidenden Arbeitskräfte - zumal jene mit ho-

VIII

Vorwort

her Bezahlung – zunehmend Menschen dar, die sich nicht im herkömmlichen Sinn „managen“ lassen.Denn in vielen Fällen sind diese Informationsarbeiter im Unternehmen gar nicht fest angestellt, sondern Auftragnehmer, Berater, Teilzeitkräfte, Joint-Venture-Partner oder Ähnliches. Von diesen Menschen werden sich mehr und mehr eher mit ihren Kenntnissen und Fertigkeiten identifizieren als mit den Organisationen, für die sie arbeiten. In Zukunft ist mit einer bunten Vielfalt an „Organisationen“ zu rechnen – so unterschiedlich wie eine Ölraffinerie und ein Automobilmontagewerk, obwohl beide Fabriken sind. Jede Organisation in den entwickelten Ländern (und das gilt nicht nur für Unternehmen) muss nach ihrem spezifischen Auftrag und den besonderen zeitlichen, örtlichen oder auch kulturellen Umständen gestaltet werden. Künftig wird der Schwerpunkt der Managementtätigkeit darin liegen, neue Konzepte, Methoden und Praktiken zu entwickeln, um die Informationsressourcen nutzbar zu machen. Das zentrale Element der neuen Organisation ist dabei der Datenspeicher und sein Management.„Information Lifecycle Management (ILM)“ beschreibt das Management und nutzt Information als Produktionsfaktor. ILM ist eine Managementphilosophie, mit der Unternehmen ihre Datenbestände und damit ihren Produktionsfaktor Information optimal einsetzen. Bei der Sicht,Information als Produkt aufzufassen,unterliegt die Information – wie jedes andere Produkt auch – einem Lebenszyklus. Hierunter ist für „Information“ die erwartete oder aus der Vergangenheit interpolierte Nutzbarkeit der Information bis zum Ausscheiden aus dem Informationsportfolio des Unternehmens zu verstehen.Wie jedes andere Produkt durchläuft auch die Information zunächst eine Einführungsphase, in der die Kosten der Informationsgewinnung und -haltung den Nutzen der Information übersteigen. Hier ist die Information am „wertvollsten“, weil am aktuellsten für das Unternehmen. Hier entscheidet sich, ob durch geeignete Nutzung der Information zukünftig der Ertrag aus der Information die Kosten der Information übersteigen wird. In ihrer Wachstumsphase wird Information gewinnbringend in die Geschäftsprozesse des Unternehmens eingebaut. In dieser Phase erhöhen sich evtl. noch die Kosten der Informationshaltung, die Erträge der Information steigen. In der Reifephase halten sich die Kosten der Information in Grenzen, der Gewinn erreicht sein Maximum. Hier ist die gewonnene und gespeicherte Information selbstverständlicher Teil sämtlicher relevanten Geschäftsprozesse des Unternehmens geworden. Die Sättigungsphase wird erreicht, wenn die Information zur Selbstverständlichkeit aller Marktteilnehmer geworden ist, das Unternehmen also keinen Wettbewerbsvorteil aus dem Besitz der Information mehr erzielen kann. In dieser Phase muss massiv über die Gewinnung neuer Informationen nachgedacht werden. Die Degenerationsphase beschreibt den Status der Information als für die Geschäftsprozesse des Unternehmens nicht mehr relevant. Über sämtliche Phasen des Produktlebenszyklus der Information spielen eine Vielzahl von internen und externen Parametern eine Rolle, die die Gewinnung, Speicherung und Nutzung der Information stark beeinflussen. So gibt der ordnungspolitische Rahmen moderner Industriegesellschaften einen Kanon juristischer Vorschriften im Umgang mit Information vor, wie bspw. die Anforderung,

Vorwort

IX

geschäftsrelevante Daten bis zu 30 Jahre zugreifbar zu halten2 . Der „Wert“ der Information als Wettbewerbsinstrument klassifiziert Informationen in diverse Vertraulichkeitsstufen. Auch hier existiert ein umfangreicher juristischer Komplex (BSI3 ) bzgl. des Schutzes von Informationen (bspw. personenbezogener Daten). Bei dem Rating von Aktiengesellschaften gemäß Basel II4 fließen so genannte „weiche Faktoren“ mit bis zu 60 Prozent in die Bewertung des Unternehmens ein. Zu den weichen Faktoren gehören unter anderem auch das Informationsportfolio des Unternehmens bzgl. seines Marktes (Mitbewerber, Kunden) sowie die Nutzung dieses Portfolios z.B. durch eine sozial verantwortliche Außenwirkung des Unternehmens.Vergleichbar Basel II befassen sich die deutschen Versicherungen zurzeit mit der Umsetzung von Solvency II, einem Ansatz zum strategischen Risikomanagement, der besondere Anforderungen an die Qualität und die Verfügbarkeit von Daten stellt. Auch beim Information Lifecycle Management mit Fokus auf Information als Produkt, besteht die Notwendigkeit, dass die Unternehmen ihre Datenbestände in den Griff bekommen. Mit ILM steht bei Investitionen im Speicherbereich nicht mehr der Aufbau von Kapazität im Vordergrund, sondern ein besseres Management der gespeicherten Daten. An ein explosionsartiges Wachstum der klassisch zu speichernden Datenmengen glauben einer Studie der Hitachi-Tochter Hitachi Data Systems (HDS) zufolge immer weniger IT-Verantwortliche. Die große Mehrheit der befragten Führungskräfte rechnet für die kommenden zwei Jahre lediglich mit einem Wachstum ihrer Datenbestände von 30 Prozent. Die großen Anbieter setzen deshalb verstärkt auf Beratungsdienstleistungen und Software.Die Anbieter von Speichersystemen zeigen so dem Kunden, wie sie effizienter mit dem Equipment arbeiten können, das sie bereits haben. Massive Infrastruktur-Investitionen im Gleichschritt mit steigenden Datenvolumen sind durch ILM nicht mehr nötig. Die Computerwoche berichtet auf der Seite für Zahlen, Prognosen und Trends unter der Überschrift „Im Fokus: Information Lifecycle Management“: „Die Meinungen, was Information Lifecycle Management (ILM) eigentlich bedeutet und was es impliziert, gehen weit auseinander.“5 Die Marktforscher der Experton Group6 haben untersucht, ob und wie sich Unternehmen des Themas ILM annehmen. Demnach haben 3,5 Prozent der 200 befragten IT- und Speicherverantwortlichen ILM unternehmensweit komplett umgesetzt. Weitere 25,5 Prozent haben punktuell Erfahrungen gesammelt und hegen kurzfristige Umsetzungspläne. Das Gros der Befragten (47,5 Prozent) plant langfristig die – zumindest teilweise – Umsetzung, und nur 22 Prozent verfolgen keine entsprechenden Projekte. Ziele, die mit ILM-Projekten erreicht werden sollen, sind an erster Stelle Business Continuity und Disaster Recovery (12,3 Prozent), gefolgt von der Bewältigung der ständig ansteigenden Datenflut (10,5). Außerdem ist die Einhaltung gesetzlicher Bestimmungen und Regularien (9,3) ein Treiber, 2 3 4 5 6

Vgl. bspw. www.aerzteblatt.de/v4/archiv. BSI – Bundesamt für Sicherheit in der Informationstechnologie, www.BSI.de. Vgl. www.basel-ii.info. www.computerwoche.de, 15/6 Seite vom 14. April 2006, S. 50. www.computerwoche.de, vgl. auch, www.experton-group.de.

X

Vorwort

ebenso die allgemeine Kostenkontrolle (7,4) und das Bestreben, Server- und Speicherlandschaft zu konsolidieren (6,8). Rund die Hälfte der Befragten hat bereits die technischen Grundlagen für ILM geschaffen. Dazu zählen Konsolidierung der Server- und Speicherumgebung sowie der Backup- und Recovery-Architektur.Storage Area Networks (SANs) und NAS-Konzepte (Network Attached Storage) sind von 44 bzw. 31 Prozent der Befragten umgesetzt. Insgesamt 40 Prozent wollen ein zentrales Storage-Resource-Management (SRM) aufbauen – Ende 2005 waren allerdings erst 19 Prozent so weit. Folgt man dieser Bewertung, so steckt Information Lifecycle Management aktuell noch in den Anfängen. Zudem gibt es noch keinen allgemein akzeptierten Standard. Die großen Speicheranbieter beginnen hier erste marktfähige ILMProdukte und Dienstleistungen anzubieten, d. h., wir befinden uns erst in der Einführungsphase,noch ohne klar erkennbare Orientierung.Natürlich realisiert jedes Unternehmen mehr oder weniger explizit oder implizit Aktivitäten im Sinne eines ILM-Konzeptes in seinem Streben, schon heute die gesetzlichen Vorgaben und die Anforderungen der Geschäftsprozesse, die Compliance, zu erfüllen. Der sehr unterschiedliche Wissensstand der Entscheidungsträger über ILM als Strategie und den Umsetzungsgrad der ILM-konformen Ansätze hat uns, die beiden Autoren, veranlasst, das Thema in zwei Bänden abzuhandeln, um die für den Leser im Sinne eines Dienstleisters jeweils relevanten Informationen kompakter und zielgerichteter vorstellen zu können. Beide Bände „Grundlagen und Modelle des Information Lifecycle Management“ und „Information Lifecycle Management – Prozessimplementierung“ haben zusammen den Anspruch, über den klassischen Hardware- und Softwarelösungsansatz hinaus das gesamte für ein Information Lifecycle Management relevante Umfeld zu beschreiben.

Information Lifecycle Management – Prozessimplementierung Im vorliegenden Band werden in einem kurzen Abriss in Kapitel 1 und 2 nur die wichtigsten Informationen zum Thema ILM vorgestellt. Den Abschluss bildet die Beschreibung des sich klar abzeichnenden Trends, Speicher und IT-Sicherheit in einer Lösung zu vereinen. Dabei machen wir eindringlich deutlich, dass es ohne ein systematisches Management der Informationen keinen wirksamen Schutz gibt. Dazu wird unter Berücksichtigung der empfohlenen spezifischen „Security Policies“ der einzelnen Hersteller ein gesamthaftes IT-Sicherheitskonzept im Rahmen eines ILM-Konzeptes geschickt geknüpft. Sie sollten nach dem Studium der Kapitel 1 und 2 des Buches aufgrund der beschriebenen Anforderungen und Risiken nicht zu der Erkenntnis gelangen, dass ILM für Ihr Unternehmen zu anspruchsvoll oder zu komplex ist, da Ihnen die Know-how-Basis der Unternehmens-IT als nicht ausreichend erscheint. Wichtig für uns ist, dass Sie die Erkenntnis aus der Lektüre der beiden Kapitel mitnehmen, dass ILM weder eine Laisser-faire-Vorbereitung noch ein Nonchalance-Durchführung erlauben.

Vorwort

XI

Im Kapitel 3 Information Lifecycle Management – Projektorganisation und -struktur sowie im Kapitel 4 Information Lifecycle Management – der Projektverlauf wird dargestellt, wie ein Projekt zur Implementierung eines Information Lifecycle Management geplant, aufgesetzt und durchgeführt werden muss, um den beschriebenen Anforderungen gerecht zu werden.Wir zeigen auf,dass die Komplexität der Aufgabe eine Herauslösung des Themas aus dem Tagesgeschäft zwingend postuliert. Die erste Phase des Projektes stellt die Prozess- und Informations-Istaufnahme dar, auf deren Grundlage die geschäftszentrierten IT-Prozesse definiert werden. Diesem Schritt folgt das Assessment zur geschäftszentrierten und Policy-basierten Infrastrukturanpassung an den Wert der Informationen gemäß den vorgestellten Modellen.Hier erfolgt die Klassifikation der Daten und Anwendungen nach klassischen Geschäftsregeln sowie die Beschreibung der Implementierung von Policies anhand von Informationsmanagement-Tools. Ferner wird die Klassifizierung von Speicherressourcen zur Anpassung an Datenklassen zur Repräsentation der Informationswerte vorgenommen. Darauf aufbauend werden klassische Anforderungen an die„Tiered“-Speicherinfrastruktur (Hardware und Software) abgeleitet, definiert und beschrieben. In der erarbeiteten ILM-Entscheidungsmatrix werden sämtliche aus unserer Sicht relevanten Parameter/Anforderungen an IM/ILM-fähige Hard- und Softwaresysteme beschrieben und mit einer gemäß unseren Erfahrungswerten aussagekräftigen Gewichtung versehen. Für die Projektphase Ausschreibung und Herstellerauswahl zeigen wir, wie die Ausschreibungsunterlagen zu erstellen sind. Dieser Abschnitt enthält auch ein technisch detailliertes Pflichtenheft, das zur Ausschreibung an die in Frage kommenden Hersteller versandt wird. Außerdem beschreiben wir in diesem Buch die Projektphase Implementierung der Geschäftsprozesse und „Tiered“Speicherinfrastruktur sowie die Projektphase Migration (Daten- und Servermigration) sowie das kontinuierliche Qualitätsmanagement im Projekt und über das Projekt hinaus. Abschließend werden die Technologien, Produkte und Verfahren der marktrelevanten Hersteller und Integratoren zur Implementierung eines ILM dargestellt. Zunächst wird hinsichtlich ILM das Regelwerk der Storage Networking Industry Association (SNIA) untersucht und der Frage nachgegangen, ob es seitens der Herstellervereinigung Vorgaben oder evtl. sogar Standards zur Implementierung gibt. Dieser Einleitung folgend werden dann zunächst die ILM-Ansätze der Hardware-Protagonisten und Generalisten vorgestellt. Hier sind mit EMC2, HP, IBM, Sun (StorageTek) und Hitachi Data Systems (HDS) insbesondere die großen fünf im Markt für externe Speichersysteme gefragt. Auch die Ansätze von Network Appliances (NetApp), Fujitsu Siemens Computers (FSC) und Dell werden vorgestellt, um die in Europa gängigen Systemlieferanten komplett abzudecken. Die Aussagen eines der führenden SAN-Lieferanten – Brocade – , der während der Erstellungszeit des Buches seinen in Europa einzig relevanten Mitbewerber McData übernommen hat, kommen zur Sprache. Cisco Systems, die ebenfalls die für die ILM-Strategie notwendige Netzwerk- und SAN-Infrastruktur bereitstellt, ist in Europa mit keinem nennenswerten Marktanteil im SAN-Umfeld vertreten

XII

Vorwort

und wird daher hier nicht betrachtet. Interessant wird in diesem Abschnitt auch die Darstellung der Konzepte und Produkte der LSI-Logic Inc., die in Europa nicht direkt auf dem Markt für Speichersysteme auftritt, jedoch für einige der oben genannten Unternehmen das Equipment baut, das diese lediglich mit ihrem Namen und Logo versehen als OEM der LSI Logic vertreiben. Letztendlich werden die Ansätze einiger Beratungshäuser und Integratoren kurz gestreift, so sie ihre Kunden überhaupt auf IM- und ILM-Projekte ansprechen. Die Beschreibung der von den Anbietern verfolgten Ansätze in Verbindung mit der erstellten Entscheidungstabelle gibt dem CIO, der Information Lifecycle Management einführen muss, das Instrumentarium in die Hand, sein ILM-Projekt erfolgreich mit den passenden Partnern zu initiieren und durchzuführen.

Grundlagen und Modelle des Information Lifecycle Management (ILM) In diesem Band werden die ökonomischen und juristischen Grundlagen für Informationsmanagement und Information Lifecycle Management erläutert. Das Aufzeigen der Grundlagen macht deutlich, dass die Einführung und Optimierung eines Informationsmanagements und Information Lifecycle Management unabdingbar für den juristisch einwandfreien und ökonomisch sinnvollen Einsatz der IT erforderlich sind. Hierbei wird die Bedeutung der Information und der an sie gebundenen Geschäftsprozesse erläutert. Es wird ein geschäftszentriertes und vereinheitlichtes Informationsmanagement beschrieben, bei dem auf den Wert der Information abgehoben wird. Es wird dargestellt, dass eine Policy-basierte Infrastrukturanpassung an diesen Wert der Information erfolgen muss. Im Abschnitt über den Produktlebenszyklus des Produktes und Produktionsfaktors Information wird das betriebswirtschaftliche Konzept des Produktlebenszyklus beschrieben und – ausgehend von diesem – der Lebenszyklus des Produktes Information erarbeitet. Die juristischen Grundlagen des Informationsmanagement und das Information Lifecycle Management definieren die Anforderungen, die von ordnungspolitischer Seite heute an die IT eines Unternehmens gerichtet werden. Vorstandsund Aufsichtsratsmitglieder einer AG, Geschäftsführer einer GmbH sowie die geschäftsführenden Gesellschafter einer OHG oder KG, d. h. die Geschäftsleiter, sind zunehmend einem persönlichen Haftungsrisiko ausgesetzt. Dies gilt auch für schwere Fälle von Datenverlust in Unternehmen. In der Gesetzgebung und Rechtsprechung sind Tendenzen feststellbar, dass Geschäftsführer verstärkt von ihren Gesellschaften in die Haftung (Regress) genommen werden können. Bereits seit der „ARAG-Garmenbeck“-Entscheidung des BGH vom 21.04.19977 steht fest, dass der Aufsichtsrat einer AG grundsätzlich dazu verpflichtet ist, durchsetzbare Schadensersatzansprüche gegen Vorstandsmitglieder zu verfolgen. Nur in Ausnahmefällen darf der Aufsichtsrat davon absehen, einen Schadensersatzanspruch 7

BGHZ 135, 244 = NJW1997, aus www.uni-frankfurt.de/fb/fb01/ifawz1/segna/files/0607/ koll-0607-synopsis.de.

Vorwort

XIII

geltend zu machen. Darüber hinaus wird die entsprechende Bereitschaft zur persönlichen Inanspruchnahme der Geschäftsleiter auch durch die Verbreitung des Shareholder-Value-Gedankens bei Aktionären und Gläubigern gefördert. Die spezifischen Anforderungen machen es notwendig,auf den Sarbanes-Oxley Act (SOX), Basel II,das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG), das Transparenz- und Publizitäts-Gesetz (TransPubG), die Regelungen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GdPdU), die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) und das Handelsgesetzbuch (HGB) detaillierter einzugehen. Die innerbetrieblichen Anforderungen an die Datenhaltung sind ein weiterer determinierender Parameter für die Notwendigkeit eines Information Lifecycle Management. Hier beleuchten wir juristische und betriebliche Anforderungen an Datenschutz und Datentypen, die aus dem BSI-Grundschutz entspringen. Wir betrachten die Anforderung an Echtzeit- oder echtzeitnahe Recherche sowie als deren Voraussetzung, Policies und Verfahren zur Datenspeicherung. Abschließend betrachten wir die Serviceanforderungen, die an das Information Lifecycle Management gestellt werden. Hierbei gelten für die Ausgestaltung insbesondere die internationale ISO 20000-Norm und die aktuelle ITILv3-Version mit ihrem „Best Practice“-Ansatz als Maßstab. Der Fokus liegt dabei beim Service Design, dem Service Transition, dem Service Operations und dem Continual Service Improvement. Dabei gilt es insbesondere, die Verfügbarkeit (Availability) für Application Services, den Zugriff (Access) für Content Services, die Business Continuity und die Migration für Data Management Services und letztlich die Virtualisierung und Spezialisierung für Plattform-Services zu behandeln. Auch für ILM-Projekte gilt: Auch der längste Weg beginnt mit dem ersten Schritt.8 Sie sollten nach dem Studium des Buches vor dem Hintergrund der beschriebenen Anforderungen und Risiken nicht zu der Erkenntnis gelangen, dass ILM für Ihr Unternehmen zu anspruchsvoll oder zu komplex ist. Wichtig für uns ist, dass Sie die Erkenntnis aus der Lektüre mitnehmen, dass ILM weder eine Laisser-faire-Vorbereitung noch ein Nonchalance-Durchführung erlaubt. Wir demonstrieren Ihnen, dass sehr wohl ILM-Projekte auch aus wirtschaftlicher Sicht vorteilhaft sein können und dass die beschriebenen Risiken zu managen sind. Die den Bänden 1 und 2 zugrunde liegende Auswahl der Inhalte entspringt zwar einer subjektiven Sicht der Dinge, beruht jedoch auf den langjährigen Erfahrungen der beiden Autoren in einschlägigen Projekten. Es besteht der Anspruch, sowohl einen Überblick über dieses beeindruckende Thema der derzeitigen ITLandschaft zu liefern, als auch konkrete und einschlägige Projekterfahrungen aus Großprojekten weiterzugeben. Im Laufe dieses Buches werden eine Vielzahl von Firmen-, Produkt- und Methodennamen verwendet, deren Eigentümer zu nennen wir uns stets bemüht ha-

8

Chinesische Weisheit, www.onlinecat.de.

XIV

Vorwort

ben. Sämtliche Produkt-, Firmen- und Methodennamen sind Warenzeichen oder eingetragene Warenzeichen ihrer Eigentümer. Wir möchten das Vorwort mit Danksagungen an die Personen abschließen, mit denen wir Projekte realisierten, die uns erst in die Lage versetzten, das notwendige Know-how aufzubauen und zu verifizieren. Wir danken all unseren Kollegen und Freunden, die die Entstehung des Buches aktiv unterstützt haben. Insbesondere möchten wir hier Armin Hochberger (BTC AG),Rudolf Kerber und Ralf Sczepanski (EMC2 ), Dieter Lohnes (HRES GmbH), Mario Vosschmidt (LSI), Georg Bonn, Ralf Aniol, Torsten Hannig, Franz-Josef Hellweg, Ulrich Kleineaschoff, Bettina Laue, Marco Münning, Peter Spanier (T-Systems Enterprise Services GmbH) nennen, die uns – bewusst oder unbewusst – eine Vielzahl wertvoller Hinweise im Rahmen der gemeinsamen einschlägigen Projekte gegeben haben, die in dieses Buch eingeflossen sind. Ebenso gilt der Dank Guido Hamacher (IC2IT), der viel Energie aufgewendet hat, weitere Informationen zu besorgen, die Versionen verwaltete und mit der notwendigen Akribie die erforderlichen Korrekturen durchführte. Fehler in diesem Buch sind jedoch die unseren und nur auf unser beschränktes Verständnis der wertvollen Hinweise und Erläuterungen von Zusammenhängen durch andere zurückzuführen. Wir danken den Hersteller- und Beratungsunternehmen, die uns als externen Consultants die Informationen zu ihrer ILMStrategie mehr oder weniger bereitwillig verfügbar gemacht haben. Wir danken insbesondere auch unserem Verlag für die gute Betreuung und die unglaubliche Geduld mit zwei Autoren. Letztendlich danken wir den Menschen, die unzählige Stunden an Entbehrungen und Einschränkungen ihres und unseres gemeinsamen Lebens hinnehmen mussten, die nicht selbstverständlich sind – unseren Familien. Lienen und Aachen im September 2007

Wolfgang Sollbach und Günter Thome

Inhaltsverzeichnis

Vorwort

V

1

. . .

1 1 3 5 7

. . . . .

8 10 12 15 32

Information Lifecycle Management (ILM-) Modelle 2.1 Herausforderung: Strategisches Handeln . . . . . . . . . . . . . . . 2.2 Zusammenspiel zwischen Geschäftsprozess,Information Lifecycle und Data Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Die Ziele der strategischen IT-Planung . . . . . . . . . . . . . . . . 2.4 Entwicklungstrends Speichernetzwerke . . . . . . . . . . . . . . . . 2.5 Strategische Einführungskonzepte für ILM . . . . . . . . . . . . . . 2.5.1 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.4 Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.5 Phase 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Strategische ILM-Prozessmodelle . . . . . . . . . . . . . . . . . . . 2.6.1 ILM als Prozessmodell . . . . . . . . . . . . . . . . . . . 2.6.2 ILM als Modell mit dem Fokus Adaptive Enterprise . . 2.7 Schlüsselfaktor Klassifizierungskonzepte . . . . . . . . . . . . . . . 2.8 Schlüsselfaktor IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . 2.9 Schlüsselfaktor Qualitätssicherung . . . . . . . . . . . . . . . . . . 2.10 Schlüsselfaktor Risikomanagement . . . . . . . . . . . . . . . . . .

37 38

2

Information – Treibstoff für Produktion und Dienstleistung 1.1 Anforderungen an das Information Lifecycle Management (ILM) 1.2 Information Lifecycle und Information Lifecycle Management . 1.2.1 Zugriff, Verfügbarkeit und Schutz . . . . . . . . . . . . 1.2.2 Reduktion der Risiken der Non-Compliance . . . . . . 1.2.3 Fähigkeit, Informationsmanagement anhand des Informationswertes zu priorisieren . . . . 1.3 Der Informationslebenszyklus . . . . . . . . . . . . . . . . . . . . 1.3.1 Kosten im Informationslebenszyklus . . . . . . . . . . 1.4 Der Informationslebenszyklus-Strategien-Mix . . . . . . . . . . . 1.5 Die Informationswert-Aufbewahrungszeit-Matrix . . . . . . . .

41 44 50 54 56 56 56 57 57 57 58 58 60 62 65 66

XVI

Inhaltsverzeichnis

2.11 ILM-Projektmanagement: Anforderungen an die Projektorganisation und -Struktur . . . . . . . . . . . . . . . . . . . 3

67

Information Lifecycle Management – Projektorganisation und -struktur 69 3.1 Projektkurzbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2 Anforderungen an das Projektmanagement . . . . . . . . . . . . . . 71 3.2.1 Allgemeine Anforderungen an das Projektmanagement 71 3.2.2 Anforderungen an ein V-Modell und V-Modell-XT basiertes Projektmanagement . . . . . . . . . . . . . . . 72 3.2.3 Anforderungen an ein von der Gesellschaft für Projektmanagement (GPM) konformes Projektmanagement-Modell . . . . . . . . . . . . . . . . 73 3.2.4 Anforderungen an das Projektmanagement basierend auf “Henley Projectmanagement Course“ . . . . . . . . . 74 3.2.5 Anforderungen an das Projektmanagement basierend auf “PRINCE2“ . . . . . . . . . . . . . . . . . . . . . . . . 74 3.2.6 Anforderungen an das Projektmanagement hinsichtlich des IT-Grundschutzes . . . . . . . . . . . . . . . . . . . . 75 3.2.7 Anforderung an das Projektmanagement hinsichtlich ISO 20000 konformer Optimierung der Service-Geschäftsprozesse . . . . . . . . . . . . . . . 76 3.2.8 Weitere Projektmanagement-Dienstleistungen . . . . . 77 3.2.8.1 CMM und CISA . . . . . . . . . . . . . . . . . . . . . . . . 77 3.2.8.2 Projekt-Exit-Management . . . . . . . . . . . . . . . . . . 78 3.3 Anwendung des Projektmanagements in den beteiligten Unternehmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.4 Aktivitäten der Startphase . . . . . . . . . . . . . . . . . . . . . . . . 81 3.4.1 Erstellung des Projektleitfadens/ Projektmanagementplans . . . . . . . . . . . . . . . . . . 81 3.4.1.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.4.1.2 Geltungsbereich . . . . . . . . . . . . . . . . . . . . . . . . 81 3.4.1.3 Projektgremien . . . . . . . . . . . . . . . . . . . . . . . . 81 3.4.1.4 Besprechungen . . . . . . . . . . . . . . . . . . . . . . . . 82 3.4.1.5 Eskalationsbehandlung . . . . . . . . . . . . . . . . . . . 83 3.4.1.6 Gesamtprojektplan . . . . . . . . . . . . . . . . . . . . . . 83 3.4.1.7 Berichtswesen . . . . . . . . . . . . . . . . . . . . . . . . . 84 3.4.1.8 Änderungsmanagement . . . . . . . . . . . . . . . . . . . 85 3.4.1.9 Definition der Projektziele . . . . . . . . . . . . . . . . . 86 3.4.2 Die Projektumfeldanalyse . . . . . . . . . . . . . . . . . . 90 3.5 Aktivitäten über die komplette Projektlaufzeit . . . . . . . . . . . . 93 3.5.1 Die Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . 93 3.5.2 Projektstrukturierung . . . . . . . . . . . . . . . . . . . . 100 3.5.3 Projektorganisation KONCOM/IT . . . . . . . . . . . . . 101 3.5.4 Phasenmodell und Meilensteine . . . . . . . . . . . . . . 103

Inhaltsverzeichnis

3.5.5 3.5.6 3.5.7 3.5.8 3.5.9 3.5.10 4

Ablauf- und Terminplanung . . . . . . . . . . . . . . Einsatzmittelplanung . . . . . . . . . . . . . . . . . . Kostenplanung/Finanzmittelplanung . . . . . . . . . Berichtswesen, Statusgespräche, Projektinformationswesen . . . . . . . . . . . . . . . Projektsteuerung (Arbeitsweise und Hilfsmittel zur Termin-, Leistungs- und Kostensteuerung) . . . . . . Projektkultur, Teambildung und Teamarbeit . . . . .

XVII

. . 105 . . 106 . . 107 . . 108 . . 112 . . 112

Information Lifecycle Management Projekt 4.1 Der Projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Die erarbeiteten Grundlagen . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Generelle Migrationsverfahren . . . . . . . . . . . . . . 4.2.2 Generelle Migrationsverfahren . . . . . . . . . . . . . . 4.3 Vorbereitung und Durchführung der Ausschreibung . . . . . . . . 4.3.1 Speicherkonzept und Technologieauswahl . . . . . . . . 4.3.1.1 Anbindung von Plattenkapazitäten über Network Attached Storage (NAS) . . . . . . . . . . . . . . . . . . . 4.3.1.2 Anbindung von Speichersystemen über Storage Area Networks (SAN) . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.3 Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.4 Schlussfolgerungen für EurAmFi AG und KONCOM/IT 4.3.1.5 Storagefunktionalität . . . . . . . . . . . . . . . . . . . . 4.3.1.6 Technische Anforderung Speichersysteme, Switche und Direktoren . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.7 „Pre Site“-Anforderungen und Standort . . . . . . . . . 4.3.1.8 Definition der Speicher-Schutzklassen . . . . . . . . . . 4.3.1.9 LUN-Größen . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.10 Anzahl der Host Bus Adapter (HBA) . . . . . . . . . . . 4.3.1.11 Anzahl Switch Ports . . . . . . . . . . . . . . . . . . . . . 4.3.1.12 Hochverfügbare Services und Schutzklassen . . . . . . 4.3.1.13 Failover-Konzept . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.14 Backup-Konzept . . . . . . . . . . . . . . . . . . . . . . . 4.3.1.15 IT-Sicherheits-Konzept . . . . . . . . . . . . . . . . . . . 4.3.1.16 Wartungsverträge für Einzelkomponenten . . . . . . . . 4.3.1.17 Abhängigkeiten zu anderen Entwicklungsvorhaben . . 4.3.2 Die Ausschreibungsunterlagen und Informationen zur Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2.1 Die Anfrage und die beteiligten Unternehmen . . . . . 4.3.2.2 Erwartungen an das Angebot . . . . . . . . . . . . . . . 4.3.2.3 Vorgehen zur Bieterauswahl und Beauftragung . . . . . 4.3.2.4 Angebot als „Try- and Buy-Lösung“ . . . . . . . . . . . . 4.3.2.5 Angebotsfristen . . . . . . . . . . . . . . . . . . . . . . . 4.3.2.6 Fragen zur Ausschreibung . . . . . . . . . . . . . . . . . 4.3.2.7 Ansprechpartner . . . . . . . . . . . . . . . . . . . . . . .

119 119 140 140 141 150 150 150 154 156 159 159 161 162 163 164 165 165 169 172 179 181 182 183 184 184 185 186 186 186 187 187

XVIII Inhaltsverzeichnis

4.3.2.8 4.3.2.9 4.3.3 4.3.4 4.3.5 4.3.5.1 4.3.5.2

Datenschutz- und Geheimhaltungserklärung . Ist-Situation . . . . . . . . . . . . . . . . . . . . . Zielumgebung . . . . . . . . . . . . . . . . . . . Anforderungskatalog und Leistungsverzeichnis Migrationsverfahren und Test der Migration . Migration der Daten . . . . . . . . . . . . . . . . Die Entscheidungstabelle zur Anbieterauswahl

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

187 187 196 197 198 199 201

5 Testkonzept zur Qualitätssicherung 5.1 Generalisierter Testplan . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Allgemeiner Überblick – generalisierter Testplan . . . . 5.1.3 Ausfall eines HBAs . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Ausfall eines primären Servers . . . . . . . . . . . . . . . 5.1.5 Ausfall eines Primärspeichersystems . . . . . . . . . . . 5.1.6 Ausfall des Primärstandortes . . . . . . . . . . . . . . . . 5.1.7 Wiederherstellung eines primären Servers . . . . . . . . 5.1.8 Wiederherstellung des Primärstandortes . . . . . . . . . 5.1.9 Backup eines Produktionssystems . . . . . . . . . . . . . 5.1.10 SNAP von Primärsystem und Mapping an Backup-Server . . . . . . . . . . . . . . . . . . . . . . 5.1.11 Restore eines Primärsystems aus einem SNAP . . . . . 5.1.12 SNAP der Spiegelgeräte und Mapping der SNAP-Geräte an Backup-Server . . . . . . . . . . . . . . . . . . . . . . 5.1.13 Restore eines Systems aus dem SNAP-Spiegel . . . . . . 5.2 Testplan Windows-Cluster . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Konfigurationsorientierte Tests . . . . . . . . . . . . . . 5.2.3 Namensauflösung . . . . . . . . . . . . . . . . . . . . . . 5.2.4 Servicerelevante Tests . . . . . . . . . . . . . . . . . . . . 5.2.4.1 Online-Austausch HBA . . . . . . . . . . . . . . . . . . . 5.2.4.2 Failover-Tests Clustermember 1 . . . . . . . . . . . . . . 5.2.4.3 Failover-Tests Clustermember 2 . . . . . . . . . . . . . . 5.2.4.4 Skalierungsmöglichkeiten . . . . . . . . . . . . . . . . . 5.3 Backup und Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Erstellen eines Snapshots . . . . . . . . . . . . . . . . . . 5.3.2 Backup und Restore einzelner Dateien und Verzeichnisse mit Snapshots . . . . . . . . . . . . . . . . 5.3.3 Backup und Restore kompletter Datenträger mit Snapshots . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Ermittlung der SAP-Datenbanklast für einen Testvergleich bei Inbetriebnahme des SAN . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Test der Datentypisierung und Archivierung . . . . . . . . . . . . .

209 210 210 211 211 212 212 213 213 214 215 216 218 219 220 221 221 222 222 223 223 223 227 230 231 231 231 232 232 233

6

Inhaltsverzeichnis

XIX

Datenklassifizierung 6.1 Speicherklassifizierungskonzepte . . . . . . . . . . . . . . . . . . . 6.2 Generische Klassifizierungsansätze . . . . . . . . . . . . . . . . . . 6.2.1 Statische Klassifizierungsmodelle . . . . . . . . . . . . . 6.2.1.1 Modell: Anwendungsklassifizierung . . . . . . . . . . . 6.2.1.2 Modell: Archivierungsbasierte Klassifizierung . . . . . 6.2.1.3 Modell: Auskunftsklassifizierung . . . . . . . . . . . . . 6.2.1.4 Modell: Business-Transaction-basierte Klassifizierung 6.2.1.5 Modell: Data-Protection-Initiative-Klassifizierung . . . 6.2.1.6 Modell: Datenverwaltungs-DienstleistungenKlassifizierung . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1.7 Modell: Datumsklassifizierung . . . . . . . . . . . . . . . 6.2.1.8 Modell: Dienstleistungsklassifizierung . . . . . . . . . . 6.2.1.9 Modell: Disaster-Recovery-Klassifizierung . . . . . . . . 6.2.1.10 Modell: Geschäftsfeldklassifizierung . . . . . . . . . . . 6.2.1.11 Modell: Informationsmanagement-DienstleistungenKlassifizierung . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1.12 Modell: Metadatenbasierte Klassifizierung . . . . . . . . 6.2.1.13 Modell: Security-based-Klassifizierung . . . . . . . . . . 6.2.1.14 Modell: Standardbasierte Klassifizierung . . . . . . . . 6.2.1.15 Modell: Value-driven-Klassifizierung . . . . . . . . . . . 6.2.1.16 Modell: XAM-Klassifizierung . . . . . . . . . . . . . . . 6.2.2 Dynamische Klassifizierungskonzepte . . . . . . . . . . 6.3 Tiered Storage als Lösungsinstrument bei der operativen Umsetzung der Klassifizierung . . . . . . . . . . . . . . . . . . . . . 6.4 Projektbezogene Umsetzung . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Betriebsstandards der EurAmFi AG . . . . . . . . . . . . 6.4.1.1 Infrastrukturstandards . . . . . . . . . . . . . . . . . . . 6.4.1.2 Speichersysteme . . . . . . . . . . . . . . . . . . . . . . . 6.4.1.3 Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 Standards für Sekundärinfrastruktur . . . . . . . . . . . 6.4.2.1 Stromversorgung . . . . . . . . . . . . . . . . . . . . . . . 6.4.2.2 Klimatisierung . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2.3 Verschiedene Standorte . . . . . . . . . . . . . . . . . . . 6.4.3 Klassifizierung nach Server und Anwendungen . . . . . 6.4.4 Abgrenzung zwischen Klassifizierung nach Verfügbarkeit, Verfügbarkeitsklasse und SLA . . . . . . 6.4.4.1 Attribute von Verfügbarkeitsklassen . . . . . . . . . . . 6.4.4.2 Maximale Hardwareausfallzeit (physikalische Wiederherstellzeit) . . . . . . . . . . . . . . . . . . . . . . 6.4.4.3 Maximale logische Wiederherstellzeit . . . . . . . . . . 6.4.4.4 Notwendigkeit eines Service-Desk . . . . . . . . . . . . 6.4.4.5 Notwendigkeit einer Betriebsbereitschaft . . . . . . . . 6.4.4.6 Reaktionszeiten . . . . . . . . . . . . . . . . . . . . . . . 6.4.4.7 Betriebszeiten . . . . . . . . . . . . . . . . . . . . . . . .

235 235 239 240 240 240 241 242 244 244 245 245 245 246 246 247 247 248 248 249 251 252 253 254 254 255 255 256 256 256 256 257 259 259 261 261 262 263 264 265

XX

Inhaltsverzeichnis

6.4.4.8 6.4.4.9 6.4.4.10 6.4.4.11 6.4.5 6.4.6 6.4.7 6.4.8 7

Sonderzeiträume . . . . . . . . . . . . . . . . . . . . . . . Wartungszeiträume . . . . . . . . . . . . . . . . . . . . . Maximaler geplanter Datenverlust . . . . . . . . . . . . . Betriebsumgebung der Anwendung . . . . . . . . . . . . Verfügbarkeitsklassen . . . . . . . . . . . . . . . . . . . . Verfügbarkeitsklassen und KONCOM/IT-Datenklassen Klassifizierung mit Hilfe von Metadaten . . . . . . . . . Content-basierte Klassifizierung . . . . . . . . . . . . .

266 266 266 267 267 268 270 270

Sicherheit 7.1 Speichersicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Klassische Sicherheitskonzepte bei zentraler Datenspeicherung . 7.2.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Virtual Private Network . . . . . . . . . . . . . . . . . . . 7.2.3 Access Control List . . . . . . . . . . . . . . . . . . . . . . 7.2.4 FC-Verkabelung . . . . . . . . . . . . . . . . . . . . . . . 7.2.5 Kontinuierliche Datensicherung . . . . . . . . . . . . . . 7.3 Klassische Sicherheitskonzepte in einer verteilten Speicherumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Ergänzende Maßnahmen . . . . . . . . . . . . . . . . . . 7.3.2 Port Based Network Access Control . . . . . . . . . . . . 7.3.3 Mandatory Access Control . . . . . . . . . . . . . . . . . 7.3.4 Role Based Access Control . . . . . . . . . . . . . . . . . 7.3.5 Management der Speicherinfrastruktur . . . . . . . . . 7.4 Security-Management-Planung im Bereich Speicheradministration . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Maßnahmenkatalog Infrastruktur (M 1) . . . . . . . . . 7.4.2 Maßnahmenkatalog Organisation (M 2) . . . . . . . . . 7.5 SAN-Zoning und LUN-Masking . . . . . . . . . . . . . . . . . . . . 7.6 Anforderung an die Organisation und die Betriebsführung . . . . 7.6.1 Das Sicherheitsmanagement . . . . . . . . . . . . . . . . 7.6.2 Management des kontinuierlichen Geschäftsbetriebs . 7.6.2.1 Definition der Sicherheitspolitik . . . . . . . . . . . . . 7.6.2.2 Definition des Umfangs des ISMS . . . . . . . . . . . . . 7.6.2.3 Risikoidentifikation und -analyse . . . . . . . . . . . . . 7.6.2.4 Risikomanagement . . . . . . . . . . . . . . . . . . . . . 7.6.2.5 Auswahl von Steuerungszielen und -maßnahmen . . . 7.6.2.6 Erklärung der Anwendbarkeit . . . . . . . . . . . . . . . 7.6.3 Anforderungen an die Organisation und die Standards 7.7 Allgemeine Sicherheitsanforderungen an eine verteilte Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Backup als Bestandteil einer Sicherheitsstrategie . . . . . . . . . . 7.8.1 SLA als Kernforderung für den Backup- und Wiederherstellprozess . . . . . . . . . . . . . . . . . . . . 7.8.2 Wiederherstellungsprozess . . . . . . . . . . . . . . . . .

273 273 274 274 275 276 277 277 278 278 279 279 279 280 281 281 281 285 286 287 288 288 288 288 289 289 289 289 290 290 291 292

Inhaltsverzeichnis

XXI

Backup Medium Festplatte . . . . . . . . . . . . . . . . . Backup-Medium Band . . . . . . . . . . . . . . . . . . . Verschlüsselung des Backups als Bestandteil einer Sicherheitsstrategie . . . . . . . . . . . . . . . . . . . . . 7.8.5.1 Sicheres Verschlüsselungsverfahren . . . . . . . . . . . . 7.8.5.2 AES-Algorithmus II . . . . . . . . . . . . . . . . . . . . . 7.8.5.3 Verschlüsselung am besten in der Virtual-Tape-Library . . . . . . . . . . . . . . . . . . . . 7.8.5.4 Authentizität der Daten . . . . . . . . . . . . . . . . . . . 7.8.5.5 Schlüsselverwaltung . . . . . . . . . . . . . . . . . . . . . 7.9 Disaster Recovery als Bestandteil einer Sicherheitsstrategie . . . . 7.10 Archivierung als Bestandteil einer Sicherheitsstrategie . . . . . . . 7.10.1 Rechtliche Anforderungen an die Archivierung . . . . . 7.10.2 Lotus Notes und E-Mail als rechtsrelevante elektronische Erklärungen . . . . . . . . . . . . . . . . . 7.10.3 Lotus Notes und E-Mail als Beweismittel bei der Dokumentation betriebswichtiger Vorgänge . . . . . . . 7.10.4 Grenzen der Dokumentation: Lotus Notes und E-Mail versus Mitarbeiterschutz . . . . . . . . . . . . . . . . . . 7.10.5 Lotus Notes und E-Mail als Gegenstand der gesetzlich zwingenden Dokumentation von Geschäftsvorfällen . . 7.10.6 Zulässige Archivierungsformen . . . . . . . . . . . . . . 7.10.7 Folgen einer Verletzung der Archivierungspflicht . . . . 7.10.8 Archivierungsprozess . . . . . . . . . . . . . . . . . . . . 7.10.9 Archivierungsformate und Archivierungsformatanforderungen . . . . . . . . . . . 7.10.10 Langzeitstabile Formate für textbasierte Informationen: SGML, HTML und XML . . . . . . . . . 7.10.10.1 SGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.10.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.10.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.11 Langzeitstabile Formate für Pixelgrafiken: TIFF . . . . 7.10.12 Langzeitstabile Formate für Pixelgrafiken: PNG . . . . . 7.10.13 Langzeitstabile Formate für Pixelgrafiken: GIF, BMP, JPEG, JPEG 2000 . . . . . . . . . . . . . . . . . . . . . . . 7.10.13.1 GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.13.2 BMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.13.3 JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.13.4 JPEG 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.14 Langzeitstabile Formate für Vektor- und kombinierte Grafiken: EPS . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.15 Langzeitstabile Formate für Vektorgrafiken: SVG . . . . 7.10.16 Langzeitstabile Formate für Seitenbeschreibung und beliebige Grafiken: PDF . . . . . . . . . . . . . . . . . . . 7.10.16.1 PDF als ISO-Norm . . . . . . . . . . . . . . . . . . . . . .

293 294

7.8.3 7.8.4 7.8.5

294 295 295 295 296 296 297 298 298 299 300 300 301 301 302 303 304 305 305 306 306 307 308 309 309 309 309 309 310 311 311 312

XXII

Inhaltsverzeichnis

7.10.16.2 7.10.16.3 7.10.16.4 7.10.16.5 7.10.16.6 8

PDF als Web-Format PDF-Features . . . . PDF-Probleme . . . PDF/X . . . . . . . . PDF/A . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

312 312 313 313 314

ILM aus der Sicht der Anbieter 8.1 ILM und die Vollsortimenter . . . . . . . . . . . . . . . . . . . . . . 8.1.1 EMC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 Hewlett-Packard inklusive TSG9 . . . . . . . . . . . . . . 8.1.3 IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.4 Fujitsu Siemens Computers (FSC) . . . . . . . . . . . . . 8.1.5 Network Appliances (NetApp) . . . . . . . . . . . . . . . 8.1.6 SUN Microsystems mit der ILM-Lösung IM310 . . . . . 8.1.7 Hitachi Data Systems: Der gewachsene Vollsortimenter 8.1.8 LSI Logic: Innovation mit Silicon-to-Systems . . . . . . 8.1.8.1 IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.8.2 SUN/StorageTek . . . . . . . . . . . . . . . . . . . . . . . 8.1.8.3 CRAY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.8.4 TERADATA (NCR) . . . . . . . . . . . . . . . . . . . . . . 8.1.8.5 Silicon Graphics (SGI) . . . . . . . . . . . . . . . . . . . . 8.1.8.6 Verari Systems . . . . . . . . . . . . . . . . . . . . . . . . 8.1.8.7 Linux Networks . . . . . . . . . . . . . . . . . . . . . . . 8.1.8.8 MaXXan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.8.9 SEPATON . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Interessante Spezialisten . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Softwarelösungen . . . . . . . . . . . . . . . . . . . . . . 8.2.1.1 ECM-Lösungen . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1.2 Tool zur Unterstützung der Klassifizierung . . . . . . . 8.2.1.3 Symantec – der Vollsortimenter im Softwarebereich . . 8.2.2 Brocade – dateibasiertes Information Lifecycle Management (ILM) auf Basis des File Area Networking (FAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2.1 File Lifecycle Management . . . . . . . . . . . . . . . . . 8.2.2.2 FAN ist die Basis für ILM . . . . . . . . . . . . . . . . . . 8.2.2.3 Einfache, regelbasierte Datenhaltung in Prozessen . . . 8.2.2.4 Global Namespace und File Lifecycle Management . . . 8.2.2.5 ILM – Komplexität der Umsetzung . . . . . . . . . . . . 8.2.3 DELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 ILM-Ansätze der Dienstleister . . . . . . . . . . . . . . . . . . . . . 8.3.1 Accenture . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 BCG – Boston Consulting Group . . . . . . . . . . . . . . 8.3.3 Computacenter Compunet . . . . . . . . . . . . . . . . . 8.3.4 CSC Ploenzke . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.5 EDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

315 315 315 316 317 318 318 318 320 326 333 334 335 336 336 336 336 337 337 343 343 343 346 347

347 347 348 350 350 351 352 355 355 355 355 356 356

Inhaltsverzeichnis XXIII

8.3.6 8.3.7 8.3.8 8.3.9 8.3.10 8.3.11 8.3.12 8.3.13 8.3.14 9

Ernst & Young . . . . . . . . . . . . . . Kienbaum . . . . . . . . . . . . . . . . . Logica CMG . . . . . . . . . . . . . . . . Materna GmbH . . . . . . . . . . . . . . McKinsey & Company . . . . . . . . . . PriceWaterhouseCoopers (PWC) . . . Roland Berger Strategy Consultants . . Siemens (hier SBS) . . . . . . . . . . . . Deutsche Telekom AG (hier T-Systems)

Zusammenfassung und Fazit

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

356 357 357 357 357 358 358 358 358 361

Literaturverzeichnis

363

Sachwortverzeichnis

375

1 Information – Treibstoff für Produktion und Dienstleistung

1.1

Anforderungen an das Information Lifecycle Management (ILM)

Märkte und Technologien, die sich mit der Speicherung und Verwaltung von Dokumenten bzw. Informationen beschäftigen, befinden sich aktuell in einem dramatischen Umbruch um den gestiegenen Anforderungen gerecht zu werden, denn die Datenbestände von Unternehmen wachsen kontinuierlich.Die Bedeutung der zielgerichteten Speicherung und der späteren Bereitstellung von Information steigt in allen volkswirtschaftstheoretischen Sektoren, d. h. sowohl im primären (Rohstoffgewinnung und -verarbeitung), im sekundären (industrielle Produktion) als auch insbesondere im tertiären Sektor (Dienstleistungen). Im Zeitalter des E-Business wurden zudem zahlreiche weitere neue Applikationen entwickelt. Neben ERP-Systemen gibt es heute zunehmend in Unternehmen auch Customer Relationship Management (CRM), Data-Warehouse-Systeme und Supply Chain Management (SCM), um nur die wichtigsten zu nennen. Diese Applikationen zeichnen sich nicht nur durch ihre Bedeutung für den geschäftlichen Erfolg für die Unternehmen aus, sie haben auch einen enormen Bedarf an Speicherressourcen, der ständig weiter ansteigt. Die IT-Abteilung eines durchschnittlichen Unternehmens hat pro Jahr einen Bedarf an neuem Speicher von 50 bis 70 Prozent des bestehenden Speichervolumens. Alte Daten können zudem nicht einfach gelöscht werden, da es zahlreiche gesetzliche Bestimmungen gibt, zu deren Erfüllung umfangreiche Archive angelegt werden und Daten jederzeit verfügbar sein müssen. Gleichzeitig liegt ein wachsender Kostendruck auf den IT-Abteilungen. Umso wichtiger wird ein einheitliches und dabei kostensensitives Datenmanagement, welches die richtigen Daten zum richtigen Zeitpunkt dort verfügbar macht, wo sie aktuell benötigt werden. In den letzten Jahren hat sich in diesem Umfeld ILM als probates Konzept etabliert, um den Anforderungen der modernen Datenspeicherung zu begegnen. Nur im engeren Sinne handelt es sich bei ILM um ein Speichermanagementkonzept,das Informationsobjekte während der gesamten Lebenszeit auf der Basis eines Regelwerkes aus Prozessen und Technologie aktiv verwaltet. Aktuelle ILM-Modelle unterscheiden in ihren Konzepten nicht zwischen operationellen und nicht operationellen Daten. Diese Unterscheidung ist jedoch für den Bereich Business Intelligence (BI) zentral. Die Informationen, die in Busi-

2

1 Information – Treibstoff für Produktion und Dienstleistung

ness Performance Management (BPM-) Systemen gehalten werden, bestimmen den Unternehmenswert maßgeblich. Heute existiert jedoch keine einheitliche BISystemarchitektur, die zu einem integrierten Datenmodell von Data Warehouses und der Vielzahl von Tabellen- und Berichtsdokumenten führen könnte. Die Klassifizierung von Informationsobjekten sollte also nicht nur aus Sicht der regulatorischen Vorgaben und der Speicherkosten erfolgen. Darüber hinaus sind Kriterien einzuführen, die die Bedürfnisse von BI abdecken. So sind sowohl die operationellen Daten wie auch Data Warehouses mit allen zur Entscheidungsunterstützung verwendeten Informationsobjekten entsprechend zu klassifizieren und innerhalb eines DLM-Konzeptes zu behandeln. Im Idealfall hat ein Unternehmen eine durchgängige BI-Architektur umgesetzt. Die operativen Daten werden über Data Warehouses verdichtet, die zusammengefasst sämtliche für die Steuerung eines Unternehmens relevanten Informationen, Funktionen und Prozesse enthalten. Ein Viertel der täglichen Arbeitszeit verbringt jeder Beschäftigte im administrativen Bereich im Schnitt mit der Suche nach Informationen, und oft genug ist die Suche vergeblich. Wer kennt nicht die Situation, in der ein Mitarbeiter nicht erreichbar ist und seine Kollegen sehr zeitaufwändig versuchen, die Daten eines Angebots zu rekonstruieren, die irgendwo abgelegt wurden, im Zweifelsfall auf der Festplatte im Notebook des Mitarbeiters. In gleicher Weise führt die aus Kostengesichtspunkten notwendige Limitierung des E-Mail-Accounts regelmäßig dazu, dass Mitarbeiter ihre eigene lokale Ablage aufbauen, die zeitaufwändig gepflegt wird – teilweise sind die Mitarbeiter ganze Arbeitstage damit beschäftigt – und die dann bei fast jedem Releasewechsel wiederum zeitaufwändig rekonstruiert werden muss. Diese Situationsbeschreibung ist immer noch der Normalzustand, der selbst bei führenden Speichersystemanbietern anzutreffen ist, wie die beiden Autoren aus langjährigen, leidvollen Erfahrungen bestätigen können. Obwohl die produktionswirtschaftlichen Grundmodelle der industriellen Produktion und der Dienstleistungserstellung noch nicht alt sind, werden wesentliche Aspekte der betrieblichen Praxis nicht ausreichend berücksichtigt. Der einzelne Nachfrager stellt für die betriebliche Leistungserstellung externe Prozessinformationen zur Verfügung, mit deren Hilfe er in den Leistungserstellungsprozess eingreift und ihn steuert. Durch den Kontakt zum Anbieter während des Leistungserstellungsprozesses ist der Nachfrager ebenfalls in einen Prozess der Informationsgewinnung eingebunden. So fließen ihm Informationen verschiedenster Art zu. Die Informationen über das Leistungspotenzial, den Leistungserstellungsprozess und das Leistungsergebnis bzw.seine Teilergebnisse stellen für den Nachfrager zunächst nur Daten dar. Im Zuge ihrer Aufbereitung und Speicherung können sie aber das Wissensreservoir des Nachfragers anreichern und im Rahmen seines Leistungspotenzials weiter genutzt werden. So kann der Nachfrager aus dem Verlauf des Leistungserstellungsprozesses und den Informationen über das Leistungspotenzial des Anbieters wichtige Anregungen bezüglich der Gestaltung seiner eigenen internen Prozesse gewinnen. Das im eigenen Leistungsprozess aktivierte Wissen steuert als externe Prozessinformation dann einen neuen Leistungserstellungsprozess. Jeder Leistungserstellungsprozess wird somit durch die Integration zumindest von Information angestoßen. Dies erfolgt unabhängig davon, ob auch

1.2 Information Lifecycle und Information Lifecycle Management

3

eine technische Integration der vom Nachfrager zur Verfügung gestellten Objekte stattfindet, und unabhängig davon, in welchem Umfang der Nachfrager räumlich oder zeitlich während des Leistungserstellungsprozesses anwesend sein muss. Insbesondere für die immer stärker von den Nachfragern geforderte Individualisierung des Leistungsergebnisses ist dabei die Integration von Information ausschlaggebend.Dies gilt auch für die Qualität des Leistungsergebnisses.Information ist damit mehr als ein Verbrauchsfaktor. Information ist vielmehr der Treibstoff der heutigen betrieblichen Produktion und der Dienstleistungserstellung.

1.2

Information Lifecycle und Information Lifecycle Management

Der Weg der Gesellschaft von einer industrialisierten zu einer Informations- und Dienstleistungsgesellschaft stellt die „Informationsverantwortlichen“ der Unternehmen vor neue Herausforderungen. War IT in ihren Anfängen zuvorderst vor allem Informationssammlung und Informationsverarbeitung,so war sie in der vergangenen Dekade geprägt durch Verfahren, die gesammelten Informationen zur Verarbeitung wiederzufinden und zu verdichten. Der Einsatz von Instrumenten wie Customer Relationship Management (CRM-) Softwaresystemen, Enterprise Ressource Planning (ERP-) Systemen und Data Warehouses (DW-) mit Data Minning (DM-) Verfahren sind die IT-technischen Ausprägungen dieser Aufgabenstellung. Jedoch, Informationsmanagement wird aufgrund der unmäßigen Sammlung von Informationen vor neue Aufgaben und Herausforderungen gestellt. Hier fällt allein schon in der Terminologie ein häufig verwirrendes Durcheinander zwischen Daten und Informationen auf. Diese beiden Begriffe werden gerne synonym verwendet: „Die Informatik und Datenverarbeitung (EDV) benutzen Daten als (maschinen-) lesbare und bearbeitbare Repräsentation von Information. Die Information wird dazu in Zeichen (bzw. Zeichenketten) codiert, deren Aufbau strengen Regeln folgt, der so genannten Syntax. Daten werden zu Informationen, wenn sie in einem Bedeutungskontext stehen.“1 Das unnachgiebige Wachstum der Informationsmengen mag sich an der Steigerung des Kapazitätsbedarfes an Festplattenplatz dokumentieren. Hier stellt man fest, dass ein Speicherbedarf von mehreren Terabyte heute auch bei mittelständischen Unternehmen keine Seltenheit mehr darstellt. Ein Kapazitätsbedarf über mehrere Petabyte ist bei Finanzinstituten, TK-Unternehmen und international tätigen Konzernunternehmen an der Tagesordnung. Noch Mitte der 80er Jahre des 20ten Jahrhunderts war es üblich,dass Festplatten mit einem Speichervolumen von unter 1 GB ein 15-Zoll-Format hatten. Man stelle sich den Raumbedarf vor, wenn diese Größenkategorien auch heute noch gültig wären. Unabhängig von nicht vorhandener Anschlusstechnik würden Turnhallen an Stellfläche benötigt, um allein ein Petabyte Kapazität verfügbar zu machen. 1

Wikipedia, http://de.wikipedia.org/wiki/Daten#Informatik.

4

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.1. Anforderungen an das Informationsmanagement

Die technische Entwicklung in Richtung externer Speichersubsysteme und der Anschluss über Storage Area Networks (SAN), Network Attached Storage (NAS) und internet Small Computer System Interface (iSCSI) führten dazu, dass Petabyte an Festplattenkapazität in einigen wenigen Speichersubsystemen untergebracht werden können.2 Betrachten wir jedoch die Entwicklung der Informationsspeicherung der vergangenen Dekaden, so stellen wir fest, dass Speicherkonsolidierungsprojekte allein den Zweck verfolgten, auf neue Anschlusstechniken wie SAN und NAS zu migrieren und die technische Entwicklung der Speichersysteme zu implementieren. Speicherkonsolidierungen in Form von „Einsparungen“ von Daten, also Datenreduktion, haben nicht stattgefunden. Diese technologiegetriebene Speicherkonsolidierung führt zu den beiden ersten Herausforderungen an das Informationsmanagement. • Skalierung der IT-Infrastruktur innerhalb der Budgetgrenzen Das Informationswachstum sorgt für Innovationsprojekte innerhalb der IT. Die Infrastrukturanpassungen sind technologiefolgend und eher nicht geschäftsprozess-orientiert. Die Budgetierung dieser Anpassungen sind Investitionen in die IT, ohne direkt den Nutzen für den Geschäftszweck des Unternehmens darstellen zu können. 2

Vgl. auch: Sollbach, Wolfgang: Storage Area Networks/Network Attached Storage. Hohe Datenverfügbarkeit durch Speichernetzwerke, München, 2001. Vgl. auch: Robbe, Björn: SAN. Storage Area Network, Wiesbaden, 2004.

1.2 Information Lifecycle und Information Lifecycle Management

5

• Skalierung sämtlicher Ressourcen zur Verwaltung der Komplexität Auch die Skalierung stellt den CIO der Unternehmen heute vor die Frage, ob diese Herausforderungen von der unternehmenseigenen IT angegangen oder – da deren Lösung nicht unmittelbar dem Geschäftszweck des Unternehmens dient – eventuell besser ein Outsourcing geeignet ist. So konzentriere sich die IT „mit beachtlichem Erfolg auf die Technik. Das beweist der Schub bei der prozess- und serviceorientierten Ausgestaltung von Anwendungslandschaften. Doch nutzt es der IT-Abteilung auf Dauer wenig, ein hervorragender Technologiepartner zu sein. Denn Technologie-Know-how ist in Zeiten zunehmender Standardisierung von IT-Landschaften und wachsender Bereitschaft zur Auslagerung der nicht zum Kerngeschäft gehörenden Tätigkeiten kein Garant für eine gesicherte Zukunft.“3 Dieser Tendenz entgegen wirkt die zweite von uns zu betrachtende Entwicklung der IT in der letzten Dekade. Information hat für jedes Unternehmen eine ständig steigende strategische Bedeutung. Daraus folgen die dritte und vierte aktuelle Herausforderung an die IT und den CIO eines Unternehmens.

1.2.1

Zugriff, Verfügbarkeit und Schutz

Die aktuelle Speicherinfrastruktur (Disk, Arrays, IP und SAN-Fabrics, NAS und Tapes) bietet potenzielle Ziele für Angriffe (Attacks), da insbesondere hier die Lücken zwischen dem Know-how der Administratoren und dem Level der Implementierung von IT-Sicherheitskonzepten derart groß sind, dass Angriffe sehr einfach und erfolgversprechend für potenzielle Angreifer sind.Die steigende Nachfrage an Datenmanagementanbieter nach mehr Sicherheit bei gleichzeitig wachsender Integration von immer mehr • Speicherfunktionen, • Verschlüsselungsfunktionen sowie • Sicherheitsfunktionen in ihren Systemen, führt dazu, dass Unternehmen inkompatible Managementsysteme für die jeweiligen Chiffreschlüssel ihrer Lieferanten zu betreiben haben. Notwendig ist ein Business- und Technologieframework für genormte, integrierte Verschlüsselungslösungen. Standardisierte APIs für das Lifetime Key Management (LKM) Appliance,Developer Kits,Installationsreferenzen und technischer Support sind die notwendigen Voraussetzungen für die Integration und Interoperabilität der Lösungen verschiedener Hersteller. Die Herausforderung für den Zugriff besteht darin, bei möglichst optimalen Kosten möglichst zeitnah die für den jeweiligen Geschäftsprozess benötigten Daten zugreifbar zu machen. Hier geht es um die je nach Wertigkeit und Bedeutung unterschiedliche Speichertechnologie und Zugriffssoftware. Die Verfügbarkeit (Availability) gepaart mit der Business Continuity ist die Forderung nach der 3

Nilsson, Ragnar: Die Evolution der IT-Abteilung, in: COMPUTERWOCHE 26/2006, München, 2006, S. 26.

6

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.2. Die IT-Infrastruktur für Zugriff, Verfügbarkeit und Schutz unternehmenskritischer Informationen

24x7-Zugreifbarkeit der geschäftskritischen Informationen. Insbesondere internationale zeitzonenübergreifende Geschäfte erfordern rund um die Uhr Verfügbarkeit der Daten an sieben Tagen pro Woche. Man stelle sich eine internationale Handelsbank und deren Abhängigkeit von den aktuellen Marktinformationen vor und berechne die Kosten, die ein Ausfall eines Handelssystems allein für einige Minuten verursacht, so erkennt man die Notwendigkeit von lokal und remote gespiegelten Daten, Business Continuity gewährleistenden Snapshots und ClonePlatten sowie funktionierende Backup- und Recovery-Strategien und -Systeme. Der Schutz der unternehmenskritischen Informationen kann als Schutz vor Verlust definiert werden. Hier kommen ebenfalls die für die Verfügbarkeit und Business Continuity notwendigen Prozesse und Systeme in Betracht.Definiert man Schutz als Schutz vor Ausspähung oder Missbrauch,so geht es bei dieser Herausforderung um organisatorische und technische Verfahren zur Implementierung eines IT-Grundschutzes. Dieser Service ist ebenfalls eine strategische Herausforderung an die IT der Gegenwart.

1.2 Information Lifecycle und Information Lifecycle Management

1.2.2

7

Reduktion der Risiken der Non-Compliance

Non-Compliance bedeutet die Nichterfüllung gesetzlicher Anforderungen an die Haltung und Verwaltung von Informationen. Eine Vielzahl nationaler und internationaler Regelwerke definieren die Anforderungen an IT-Systeme, deren Einhaltung in Summe den Grad der Compliance der Unternehmens-IT bestimmt. Der Herausforderung Compliance wird durch ein Business Intelligence System (BIS) geantwortet, das über die Erfüllung gesetzlicher Auflagen hinaus die Wettbewerbsfähigkeit von Unternehmen durch höhere Effizienz der Geschäftsprozesse steigern soll. Dennoch: „Wegen fehlerhafter oder fehlender Unternehmenskennzahlen ins Gefängnis? – So weit ist es noch nicht. Aber nach Enron- und Worldcom-Pleite drohen zumindest amerikanische Richter mit drakonischen Strafen, falls CEOs an US-Börsen falsche Bilanzen abliefern – willentlich oder aus purer Ahnungslosigkeit. Aber auch in Deutschland fordert der Gesetzgeber mehr Budgetklarheit. Gesetzliche Auflagen wie das KonTraG oder die Kreditvergaberichtlinien nach Basel II sollen schon heute für mehr Klarheit über die Unternehmenszahlen sorgen; eine EU-Richtlinie, die nach Ansicht von Experten Sarbanes-Oxley ähneln könnte, ist in Vorbereitung.“4 Die Bedeutung dieser vierten Herausforderung an die IT mag auch daran ermessen werden, dass analog zur IT-Infrastructure-Library (ITIL, aktuell ITILv3) als standardisiertes Best Practices (BP-) Prozessset zur Gestaltung der IT-Services mit COBIT (Control Objectives for Information and related Technology) ein Quasi-Standardset zur Einhaltung der Compliance-Anforderungen zumindest aus dem Sarbanes-Oxley Act geschaffen wurde, welches auch innerhalb europäischer Unternehmen zur Kennzahlenermittlung und -präsentation immer mehr an Bedeutung gewinnt. Die Steuerbehörden der Bundesrepublik Deutschland haben mit der Umsatzsteuer-Nachschau in §27 b Umsatzsteuer (USTG) seit 01.01.2002 auch das Recht,für Zwecke der Umsatzsteuer ohne vorherige Ankündigung während der Geschäftsoder Arbeitszeiten die Grundstücke und Räume von Unternehmern zu betreten, die eine gewerbliche oder berufliche Tätigkeit selbständig ausüben.5 Damit müssen die Compliance-Anforderungen nicht nur zu einem definierten Stichtag, sondern jederzeit erfüllt werden. Die dritte zu untersuchende Entwicklung innerhalb der Informationstechnologie führt uns zum Information Lifecycle als speziellen Produktlebenszyklus der Information. Information verändert im Zeitverlauf ihren Wert für das Unternehmen.

4 5

Business Intelligence, Verlegerbeilage, COMPUTERWOCHE 26/2006, München, 2006, S. 27. § 27 b Umsatzsteuergesetz (USTG).

8

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.3. IT-Strategien für das Informationsmanagement

1.2.3

Fähigkeit, Informationsmanagement anhand des Informationswertes zu priorisieren

Informationsmanagement will mit Prozess-Know-how, Fach- und Branchenkompetenz die Geschäftsprozesse des Unternehmens unterstützen und muss deshalb für sämtliche Herausforderungen Strategien zur Erfüllung der Anforderungen entwickeln und erfolgreich einsetzen. Die Strategien des Informationsmanagement zur Erfüllung der Anforderungen: • Skalierung der IT-Infrastruktur innerhalb der Budgetgrenzen und • Skalierung sämtlicher Ressourcen zur Verwaltung der Komplexität sind technologiegetrieben. Die optimale Auslastung der IT-Infrastruktur sowie die Vereinfachung und die Automatisierung der Administration beim Betrieb der Informationsinfrastruktur sind Strategien, deren Erfolg die IT als Technologiepartner des Business im Unternehmen belässt. Diese beiden Anforderungen sind jedoch auch die kritischen Punkte zur Legitimation der internen IT. Sind die hier gewählten Strategien nicht erfolgreich, so ist die interne IT stark durch Outsourcing gefährdet. Die Steigerung der Kosteneffizienz für Zugriff, Business Continuity und Schutz der unternehmensrelevanten Informationen als Strategie erfordern die Erfüllung der Anforderung:

1.2 Information Lifecycle und Information Lifecycle Management

9

Abb. 1.4. Entwicklungsschritte der IT6

• TCO-Betrachtung für Zugriff, Verfügbarkeit und Schutz der unternehmenskritischen Informationen sowie die Sicherstellung der Compliance durch Policy- (prozess-) basierte Business Intelligence (PBI-) Verfahren und • Reduktion der Risiken der Non-Compliance machen die IT zum Prozesspartner des Business und eventuell sogar bereits zum Partner des Business. Die Strategie zur Lieferung eines informationswertorientierten IT-Services als Lösungsstrategie für Anforderung der • Fähigkeit, Informationsmanagement auf Grundlage des Wertes der Information zu priorisieren, lässt die IT ihre höchste Evolutionsstufe erreichen. Diese Strategie macht die Unternehmensziele zu IT-Zielen. Sie ist die umfangreichste Strategie und durchläuft sämtliche Evolutionsstufen der Entwicklung der IT. Daher enthält sie quasi als Container auch sämtliche Strategien der Vorläufer-Evolutionsschritte. Aus diesem Grunde müssen wir uns in diesem Buch auch mit sämtlichen Strategien und deren Umsetzung auseinandersetzen, auch wenn dem äußeren Schein nach nur die letzte Herausforderung und die Strategien zu deren Erfüllung dem Thema des Buches entsprechen.

10

1 Information – Treibstoff für Produktion und Dienstleistung

1.3 Der Informationslebenszyklus Das Informations-Zeit-Diagramm in Abbildung 1.5 zeigt den typischen Lebenszyklus von Informationen. In der Erstellungsphase werden Informationen erzeugt. Als Beispiel mag hier der Prozess zur Erstellung eines neuen Auftrages dienen. Zur Erstellung des Auftrages werden die Kundendaten aufgenommen, die Auftragsdaten erzeugt, Zahlungskonditionen und -wege erfasst. Es werden Kundenstammdaten, Auftragsstammdaten, Rechnungsstammdaten erzeugt und Abgleiche mit der Schufa und bestehenden Daten durchgeführt. Die Zwischenergebnisse der Prozesse werden gespeichert. Letztendlich wird der gesamte neue Auftrag als Information gespeichert. Die Verdichtungsphase ist die Phase, in der die Information verarbeitet wird. In unserem Beispiel ist dies die Phase der Auftragsbearbeitung. Hier wird die Lieferung zusammengestellt, an den Kunden versandt sowie die Rechnungsstellung veranlasst. Gespeichert werden unterschiedliche Status der auftragsbezogenen Informationen. Die Phase der Nutzung der Information ist in unserem Beispiel der Zeitraum bis zum vollständigen Abschluss des Auftrages und dem Eingang der Zahlung. Der Nutzungszeitraum von Teilinformationen wie beispielsweise den Kundenstammdaten ist natürlich bedeutend länger. In diesem Beispiel wäre der Nutzungszeitraum dieser Daten bis zu dem Zeitpunkt ausgedehnt, an dem die Geschäftsbeziehungen zu diesem Kunden enden. Die Bewahrungsphase ist der Zeitraum, in dem eine Information zwar keiner Änderung mehr unterliegt, dennoch permanent zugreifbar gehalten wird, um Statusänderungen schnell begegnen zu können. Im Beispiel der Auftragsbearbeitung ist der Bewahrungszeitraum der Zeitabschnitt zwischen Auftragsabschluss und Ablauf von Garantie- und Gewährleistungsfristen. Die Archivierungsphase ist die Phase, in der Informationen aus gesetzlichen oder betrieblichen Anforderungen aufbewahrt, jedoch nicht mehr direkt zugreifbar gehalten werden müssen. Für das Beispiel unserer Auftragsbearbeitung ist der Archivierungszeitraum beispielsweise die 10-jährige Aufbewahrungspflicht und Wiederherstellbarkeitsanforderung sämtlicher geschäftsvorfallbezogener kaufmännisch relevanter Dokumente. Der Wert der Information ist in der Erstellungs-,Verdichtungs- und Nutzungsphase hoch. Hier wird aktiv mit der Information gearbeitet. Die Information wird stetig genutzt, auf sie wird beständig zugegriffen. Die Information selbst oder ihr Status unterliegt einer häufigen Änderung. Informationen in diesen Phasen sind in der Informationsgesellschaft „Anlagegüter“, ihre Aktualität macht ihre Qualität und ihren Wert aus. In der Bewahrungsphase sinkt zunächst der Wert der Information. Die Information ist auf einem letzten Zustand eingefroren (abgeschlossener Auftrag). Der Wert der Information kann nochmalig stark ansteigen, wenn eintretende Gewährleistungspflichten oder Garantien Aktualisierungen des letzten Status erfordern. In der Archivierungsphase verliert die Information an Wert für das Unternehmen. Sie wird für geschäftliche Zwecke des Unternehmens nicht mehr genutzt, 6

Nilsson, Ragnar: a.a.O., S. 26.

1.3 Der Informationslebenszyklus

Abb. 1.5. Der Lebenszyklus der Information

Abb. 1.6. Informationswert im Lebenszyklus

11

12

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.7. Informationsqualität im Lebenszyklus

sondern lediglich aus Aufbewahrungspflichten wiederherstellbar gespeichert. Ist die Aufbewahrungsfrist abgelaufen, wird die Information gelöscht. Der Wert der Information ist natürlich abhängig von ihrer Qualität. Die Qualität der Information wird dadurch charakterisiert, dass sie vollständig genutzt werden kann und kein Teil der die Information repräsentierenden Daten unnötig ist. Die Qualität der Information lebt mit der Qualität der Prüfung zum Erstellungszeitpunkt, die sicherstellen soll, dass die Information eine hohe Visibilität besitzt. Besonders bei der Erfassung unstrukturierter Daten (E-Mails, Textdokumente etc.) ist hier häufig ein Mangel an Visibilität festzustellen. Es besteht eine signifikante Gefahr darin, Ressourcen für Informationen mit geringem Wert zu verschwenden.Werden die so gewonnenen Informationen hoher Qualität in ihrem Lebenszyklus verwendet, muss der notwendige Zugriff auf die jeweils statuskonforme Kopie gewährleistet werden. Hier muss darauf geachtet werden, dass keine unnötigen Kopien ein und derselben Information gehalten werden, nur weil der Zugriff nicht befriedigend gelöst wurde.

1.3.1

Kosten im Informationslebenszyklus

Betrachtet man die Kosten der Information über ihren Lebenszyklus, so lassen wir zunächst die eventuell nicht unerheblichen Kosten der Informationsgewinnung außer Acht. Die Kosten der Information setzen sich zusammen aus:

1.3 Der Informationslebenszyklus

13

• Kosten der Softwareinfrastruktur der Informationshaltung, • Kosten der Hardwareinfrastruktur der Informationshaltung und • Kosten der Prozessinfrastruktur der Informationshaltung. Die Kosten der Softwareinfrastruktur der Informationshaltung ergeben sich zusammen aus den Beschaffungs- und Lizenzkosten für eingesetzte Softwaresysteme, Kosten für Beschaffung und Lizenzen benötigter Schnittstellensysteme sowie eventuell zusätzlichem Wartungsaufwand für die eingesetzten Softwaresysteme. Die Kosten der Hardwareinfrastruktur der Informationshaltung addieren sich über die Beschaffungs- und Wartungskosten der benötigten Primärtechnik (Server, Clients, Speichersysteme, SAN, Netzwerkinfrastruktur etc.) sowie der eingesetzten Sekundär- und Tertiärtechniken (Strom, Wasser, Kühlung, Abluft und Kosten des Rechenzentrumsbetriebes). Die Kosten der Prozessinfrastruktur der Informationshaltung bestehen aus den Personalkosten des Rechenzentrumsbetriebes, Beratungskosten, Abstimmung zwischen Fachabteilung und IT etc. Zum Zeitpunkt der Erstellung der Information erzeugt diese hohen Kosten, da sie zu Beginn ihres Lebenszyklus für den direkten Zugriff auf den Produktionssystemen des Unternehmens gespeichert und verarbeitet wird. Dieser direkte Zugriff bedingt, dass die Information hier auf teurer Primärtechnik abgelegt ist. Erfasst werden Informationen aus CRM-Systemen, anschließend werden sie in ERP-Systeme als zentrale Anwendungssysteme des Unternehmens eingepflegt und mit bereits existierenden Informationen im Informationszusammenhang (Kunde, Kundenort, Vertriebsweg usw.) abgeglichen. Die Kosten der Prozessinfrastruktur sind in dieser Phase ebenfalls hoch. Man betrachte die involvierte Softwareinfrastruktur. Diese Systeme stellen in aller Regel die Produktivsysteme der Unternehmens-IT dar. Auf Grundlage der in diesen Systemen gespeicherten Daten und Prozesse unterstützt die IT die Geschäftsprozesse des Unternehmens. Diesen Systemen gilt im Betrieb, d. h. der IT-Produktion, die höchste Aufmerksamkeit. Service Level Agreements (SLA) für diese Systeme sind hinsichtlich Verfügbarkeit, Business Continuity, Performance, Betriebsneben- und Betriebshauptzeiten die umfangreichsten, die das Unternehmen mit seinem Technologiepartner abgeschlossen hat. Die eingesetzte Primärtechnik ist für hohe Verfügbarkeit ausgestattet. Die verwendeten Serversysteme sind häufig Clustersysteme, die über ein Storage Area Network (SAN) auf externe Speichermedien zugreifen. Der Zugriff ist auch noch redundant über multiple Zugriffspfade abgesichert, die über mehrere Switches innerhalb der SAN-Fabric verlaufen. Die physikalischen Speichermedien (HDAs) sind innerhalb der Speichersysteme gespiegelt oder mit einem hohen RAID-Schutz abgesichert. Optimale Business Continuity ist gewährleistet durch den Einsatz von Cloning- und SnapshotTechnologien. Durch Datensicherungsstrategien über mehrere Generationen auf Disk- oder Magnetband-Libraries, eventuell sogar eine Zwischensicherung auf SATA-Platten im Speichersystem, wird gewährleistet, dass bei logischen und physi-

14

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.8. Die Kosten der Information im Lebenszyklus

kalischen Fehlern die Ausfallzeiten minimiert und ein Datenverlust ausgeschlossen wird. Diese hochausfallsicheren Produktivsysteme werden häufig noch aus Disaster Recovery (DR-) Gründen auf identischen Remote-Systemen in Notfall-, Katastrophenfall- oder Desaster-Rechenzentren gespiegelt. Dies ermöglicht den Zugriff auf die Daten mit einer minimalen Verzögerung auch im Falle elementarer Katastrophen,bei denen eine komplette RZ-Infrastruktur verloren geht.Die häufig genannten Einsatzszenarien für solche Remote-Systeme wie Flugzeugabsturz oder Terroranschlag sind zwar jeweils bereits eingetreten, entbehren jedoch aufgrund ihrer extrem geringen Eintrittswahrscheinlichkeit des notwendigen Furchtpotenzials. Weniger häufig genannte Szenarien sind jedoch um vieles wahrscheinlicher. Man denke an die Gefährdung eines Rechenzentrums durch Verkehrsunfälle mit ätzenden Chemikalien an viel befahrenen Eisenbahnstrecken, die Gefährdung durch lokale Naturkatastrophen (Wassereinbruch bei starken Gewittern) oder auch die weltweit häufiger werdenden Wetterereignisse. Hurrikan Caterina oder die Elbeflut der Jahre 2002 und 2006 haben in weitaus höherem Umfang das Umschalten zu Notfallrechenzentren erfordert als die Terror-Katastrophe des 11. September in New York. Gehen wir davon aus, dass nahezu 100 Prozent der Daten in der Phase der Erstellung in einer solchen Umgebung gespeichert und betrieben werden, so sind die hohen Kosten der Software-, der Hardware- und der Prozessinfrastruktur in dieser Lebenszyklusphase einleuchtend.

1.4 Der Informationslebenszyklus-Strategien-Mix

15

Während der Verdichtungsphase und der Nutzungsphase wird die Information weiter auf der teuren Primärtechnik gespeichert. Somit steigen auch hier sowohl die Kosten der Software- als auch der Prozessinfrastruktur. Während in der Erstellungsphase Rohdaten erzeugt wurden (Kundenstammsatz, Auftragsdaten, Daten zur Rechnungsstellung), werden diese in der Verdichtungsphase für die Geschäftsprozesse des Unternehmens aufbereitet. Die Bewahrungsphase ist dadurch gekennzeichnet, dass die Kosten für Hardware- und Softwareinfrastruktur abnehmen, da die Information von teuren auf günstigere Medien verlagert wird. Ferner sollte hier eine Reduktion der Daten vorgenommen werden. Nur noch die Daten, die aufbewahrt werden müssen, um die Geschäftsvorfälle des Unternehmens zu unterstützen oder gesetzlichen Auflagen gerecht zu werden, sollten gehalten werden. Auch die Kosten der Prozessinfrastruktur sinken. Die Information unterliegt seltenen Änderungen. Datensicherungsverfahren und -häufigkeiten werden dieser Situation angepasst. Die Archivierungsphase ist charakterisiert durch noch günstigere Medien sowie keine sonderlich hohen zusätzlichen Kosten für Software- und Prozessinfrastruktur.In dieser Phase werden geschäftsbezogene Dokumente für einen teilweise großen Zeitraum dokumentenecht und schreibgeschützt aufbewahrt. Die hier anfallenden Kosten entstehen für die Beschaffung, den Betrieb und die Wartung der Archivierungshard- und -software. Nach Abschluss der Archivierungsphase wird die gespeicherte Information gelöscht und verursacht keine weiteren Kosten.

1.4

Der Informationslebenszyklus-Strategien-Mix

Zentrale Wettbewerbsvorteile, die auch als kritische Erfolgsfaktoren bezeichnet werden können, ändern sich im Zeitablauf. So beruhte der Wettbewerb in den 70er Jahren in erster Linie nur auf Kostenvorteilen. In den 80er Jahren trat demgegenüber der reine Kostenvorteil in den Hintergrund und Qualität gewann zunehmend an Bedeutung. In den 90er Jahren schließlich wurde angesichts der Dynamik auf den Märkten und der ständigen Produktinnovationen die „Time to Market“ bedeutender. Heute ist Information und Wissen der kritische Erfolgsfaktor. Die Flexibilität und die Fähigkeit, die sich abzeichnenden Umweltveränderungen zu antizipieren oder gar im Sinne der eigenen Interessen selbst zu bestimmen, basiert im Wesentlichen auf Information. Dies gilt sowohl für die industrielle Produktion mit den Möglichkeiten zum Global Sourcing als auch insbesondere für Dienstleistungen. Das Qualitätsmanagement von Produktion und Dienstleistungen hat sowohl eine strategische als auch eine operative Komponente und weist somit eine Verbindung zu den strategischen und operativen Managementaufgaben auf. Die strategische Verbindung ergibt sich aus der Bedeutung der Qualität als möglicher Wettbewerbsvorteil.Qualitätsmanagement wirkt dabei sowohl nach innen als auch nach außen. Die Aufgaben des Qualitätsmanagements liegen sowohl im Bereich des Leistungserstellungsprozesses als auch der Sicherung des Leistungspotenzials.

16

1 Information – Treibstoff für Produktion und Dienstleistung

Qualität weist auf der operativen Ebene eine enge Verbindung zur Effektivität auf und damit zum Kostenmanagement. Ebenso wie für das Qualitätsmanagement besteht für das Kostenmanagement von Dienstleistungen eine hohe Korrelation mit der Wettbewerbsfähigkeit. Allerdings bezieht sich Kostenmanagement in stärkerem Maße auf die Realisierung eines Anbietervorteils, da geringere „Produktionskosten“ zu einem Kostenvorteil aus Sicht des Kunden führen können. Kostenmanagement ist daher in operativer Hinsicht der Effizienz verbunden und wird durch das Wirtschaftlichkeitsprinzip realisiert. Für Produkte und insbesondere für Dienstleistungen sind Informationen von mehrfacher Bedeutung. Mit ihrer Hilfe kann das Unternehmen seinen eigenen Leistungserstellungsprozess steuern. So können etwa die Informationen aus Kundenkontakten und Kundenbeschwerden für die Verbesserung der Produkte und Dienstleistungen genutzt werden. Dies gilt auch für die Beobachtung des Kundenverhaltens. Die Weiterleitung, Speicherung und vor allem die Nutzung dieser kundenbezogenen Informationen sind von besonderer Bedeutung für den Aufbau von Wettbewerbsvorteilen. Hier steht auch der Aufbau von Kernkompetenzen zur Disposition. Nachdem neben dem Merkmal Wert auch die wichtigen Größen Qualität und Kosten der Information in ihrem Lebenszyklus untersucht wurden, muss nun der IT-Strategien-Mix pro Lebenszyklusphase erarbeitet werden, um einen jeweils geeigneten IT-Strategien-Mix gemäß der aktuellen Wettbewerbssituation zur Verfügung zu stellen. Bei der Analyse des IT-Strategien-Mix fällt auf, dass unabhängig von der Lebenszyklusphase die Strategie für die Software-, Hardware- und Prozessinfrastruktur sowie die Anpassung an den Wert der Information stets die gleiche zu sein scheint. Dieser Eindruck verliert sich jedoch, wenn man phasenbezogen die einzelnen Maßnahmen zur Implementierung der Strategie vergleicht. Außerdem unterscheiden sich die jeweiligen Anforderungen in den einzelnen Phasen hinsichtlich der Ausprägung bestimmter beschreibender Attribute. Diese beschreibenden Attribute sollen hier nur auf die Produktivsysteme angewandt werden. Dennoch können diese Kriterien ebenfalls an die Systeme in Entwicklungs-, Testund PreLife-Umgebungen angesetzt werden. Der IT-Strategien-Mix in der Erstellungsphase wird implementiert, indem bei der Softwareinfrastruktur die neuen Daten möglichst schnell den existierenden Geschäftsanwendungen verfügbar gemacht werden. DieVereinfachung der Administration der Softwareinfrastruktur erfordert hier ein Release-Management das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind.Außerdem muss sichergestellt sein, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden.An jedem Arbeitsplatz muss die Softwareinfrastruktur vorhanden sein, die zur Erfassung einer Information und deren Transport zur zentralisierten IT benötigt wird. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Erstellungsphase, dass am Ort der Informationserstellung jeder an der Erstellung

1.4 Der Informationslebenszyklus-Strategien-Mix

17

Abb. 1.9. Der IT-Strategien-Mix im Informationslebenszyklus

beteiligte Unternehmensmitarbeiter Zugriff auf die benötigte Hardware hat. Dies bedeutet nicht, dass jeder Mitarbeiter einen festen ihm allein zugeordneten Arbeitsplatzrechner für die von ihm benötigten Anwendungen hat. Falls ein Arbeitsplatzrechner mit diesen Anwendungen ausgelastet ist,nun gut.Falls nicht – und das dürfte in der Mehrzahl der Fälle so sein –, wird Auslastungsoptimierung eventuell durch einen Terminalservice erzielt, der die Funktionalität auf einen Server konzentriert und die Präsentation je Mitarbeiter über Terminals gewährleistet. Dies bedeutet in dieser Phase jedoch auch, dass die RZ-Infrastruktur die hohen Anforderungen der Erstellungsphase erfüllen muss. Hier wird hochverfügbare Server-, Clusterserver- und Speicherinfrastruktur benötigt. Die Wahrscheinlichkeit, dass auf Daten der Erfassungsphase sehr schnell wieder zugegriffen wird, ist sehr hoch. Dies erfordert in der Erfassungsphase ITPrimärtechnik der Enterprise-Klasse mit hoher Performance und gespiegelten Systemen. Auslastungsoptimierung bedeutet hier stets, zu überwachen, dass hinreichend Server- und Speichersystemkapazität für das Erfassungswachstum vorhanden sind, jedoch auch zu prüfen, welche Daten auf diesen Systemen zur Gewährleistung direkter Zugreifbarkeit gelagert werden müssen,und sicherzustellen, dass Daten späterer Informationslebenszyklusphasen auf weniger kostenintensive Medien migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von „tiered“-IT-Plattformen. Die IT-Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur auch in der Erstellungsphase

18

1 Information – Treibstoff für Produktion und Dienstleistung

bedeutet, dass die IT die Geschäftsprozesse der Erstellungsphase in IT-Prozesse umsetzen kann.Hier ist die IT als Prozesspartner des Unternehmens gefragt.Wenn Hardware- und Softwareinfrastruktur die in der Erstellungsphase zur Erfüllung ihrer Strategien benötigten Systemkomponenten bereitstellen, so muss hier die Prozesskette eines ITILv3-konformen Service-Management zur Verfügung gestellt werden. Für die Compliance sind automatisierte Business Intelligence Processes (BIP) vonnöten, die beispielsweise den Weg der Information durch die Lebenszyklusphasen steuern. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. gefragt. Die Unterstützung der Geschäftsprozesse in Verbindung mit „tiered“Speichersystemen als Realisierung für die Hardwareinfrastruktureffizienz stellen die Strategie für die Informationswertanpassung in der Erstellungsphase dar. Wie wichtig der korrekteStrategien-Mix für die Erstellungsphase ist, zeigt die Entwicklung der weltweit generierten Daten. Alle im Unternehmen anfallenden Daten können durch eine bedarfsgerechte Aufarbeitung aussagekräftige Informationen hervorbringen. Mit Hilfe dieser Informationen ist das Management schließlich in der Lage, die Erreichung bereits festgelegter Ziele zu überwachen, Entscheidungen auf fundierter Basis zu treffen und Verbesserungen für die Zukunft zu planen. Ein wesentliche Methode der Informationsdarstellung auch für das Objekt Information sind Kennzahlen. Sie ermöglichen es, eine Menge von messbaren, entscheidungsrelevanten Daten nach festgelegten Kategorien zu bündeln und in einem größeren, unternehmerischen Zusammenhang überschaubar und aussagefähig darzustellen. Eine wichtige Größe in Bezug auf ILM ist die mehrfache Nutzung der Daten im Sinne einer Zweit-, Dritt- bzw. Mehrfachbenutzung bereits erzeugter Daten. Natürlich könnte man hier auf den Gedanken kommen, erheblich Kosten im Bereich der Speicherung, des Backups und der Archivierung von Informationen zu sparen, wenn man Information als Wegwerfgut mit Einmalcharakter auffassen würde. Die beschriebenen spezifischen rechtlichen Anforderungen sollten bereits im Ansatz dieses Ansinnen desavouieren. Aus betriebwirtschaftlicher Sicht muss es das Ziel eines jeden Unternehmens sein, eine bereits erstellte Information möglichst häufig im internen Wertschöpfungsprozess zu verwenden.Wer kennt nicht aus seinem persönlichen Arbeitsumfeld zahllose Beispiele, in denen die weit verbreitete Nonchalance bei der Ablage dazu führt, dass wertvolle Arbeitszeit für die Wiederherstellung bereits erstellter Information verschwendet wird, nur weil die Suche in der Ablage zu umständlich ist. Wiederverwendung darf nicht mit der Mehrfachspeicherung der gleichen Daten verwechselt werden. Die Zirkulation einer Vielfalt von Kopien verschwendet nicht nur Ressourcen,sondern gefährdet auch die Konsistenz der Geschäftsprozesse des Unternehmens. Entscheidungen auf Grundlage einer „falschen“ Kopie, die die aktuellen Statusänderungen der Information nicht beinhaltet, können fatale Auswirkungen haben. Am Ende des Lebenszyklus der Information muss sichergestellt werden, dass die Archivierung der Compliance-Anforderung Genüge tut und dass nach Ablauf sämtlicher Aufbewahrungsfristen die nun nicht mehr benötigte Information prozessbasiert automatisch gelöscht wird. Ist dies nicht der Fall, so

1.4 Der Informationslebenszyklus-Strategien-Mix

19

Abb. 1.10. Wiederverwendungswahrscheinlichkeit von Daten

besteht die Gefahr, dass nicht mehr benötigte Informationen über lange Zeiträume Ressourcen in Anspruch nehmen. Laut der Second Study on Digital Data Creation der University of California, Berkeley werden weltweit im Jahr 2006 über 5 Exabytes an Daten neu erstellt.7 Dabei werden diese Daten von derzeit 4 Hauptplattformen aus erzeugt. Systeme mit dem Betriebssystem z/OS, also die klassischen z/Series Mainframes, erzeugen ca. 4 Prozent der Daten im Jahre 2006 mit einer jährlichen Wachstumsrate von 45 Prozent.Unix dominiert heute die Erzeugung digitaler Daten mit einem Bestand von 47 Prozent und einer Wachstumsrate von 63 Prozent. Microsoft WindowsSysteme erzeugen 38 Prozent der Daten mit einer Wachstumsrate von ebenfalls 63 Prozent. Das Betriebssystem mit dem höchsten Wachstum von 102 Prozent stellt Linux dar, das heute bereits mit 7 Prozent an der Datenerzeugung beteiligt ist. Andere Betriebssysteme mit einem Anteil von 4 Prozent an der Erzeugung digitaler Daten und einer Wachstumsrate von 31 Prozent können nahezu vernachlässigt werden. Dabei werden die heute digital erzeugten Daten zu 20 Prozent auf Festplatten (Magnetplatten) und zu 80 Prozent auf Wechselmedien (Magnetbänder und optische Medien) gespeichert. Der Strategien-Mix in der Verdichtungs- und Nutzungsphase wird implementiert, indem bei der Softwareinfrastruktur die erzeugten Daten beständig den exis7

Moore, Fred: Storage New Horizons, Boulder, 2006, S. 8.

20

1 Information – Treibstoff für Produktion und Dienstleistung

tierenden Geschäftsanwendungen verfügbar gemacht werden. Gemäß der Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten (s.Abbildung 1.10) ist in diesen beiden Phasen die Wahrscheinlichkeit, dass eine einmal erfasste Information wieder verwendet wird, am größten. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Verdichtungs- und Nutzungsphase, dass eine zugriffsort-/zugriffszeit-/zugriffsrechtoptimierte Autorisierung vorliegt. Die RZ-Infrastruktur muss sowohl die hohen Anforderungen der Verdichtungs- als auch der Nutzungsphase erfüllen. Hier wird hochverfügbare Server-, Clusterserver- und Speicherinfrastruktur benötigt. Die Wahrscheinlichkeit, dass auf Daten der Verdichtungs- und der Nutzungsphase sehr schnell wieder zugegriffen wird ist sehr hoch. Dies erfordert in dieser Phase IT-Primärtechnik der Enterprise-Klasse mit hoher Performance und gespiegelten Systemen. Auslastungsoptimierung bedeutet hier, stets zu überwachen, dass hinreichend Server- und Speichersystemkapazität für das Datenvolumen vorhanden sind, jedoch auch zu prüfen, welche Daten auf diesen Systemen zur Gewährleistung direkter Zugreifbarkeit gelagert werden müssen,und sicherzustellen,dass Daten späterer Informationslebenszyklusphasen auf weniger kostenintensive Medien migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von „tiered“-IT-Plattformen. Die Verdichtungs- und Nutzungsphase ist innerhalb dieser „tiered“-IT-Plattform durch die Nutzung von „primary“-Systemund -Speichertechnologie gekennzeichnet. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Verdichtungs- und der Nutzungsphase bedeutet, dass die IT die Geschäftsprozesse dieser beiden Phasen in IT-Prozesse umsetzen kann. Hier ist die IT als Prozesspartner des Unternehmens gefragt. Wenn Hardware- und Softwareinfrastruktur die zur Erfüllung ihrer Strategien der Verdichtungs- und Nutzungsphase benötigten Systemkomponenten zur Verfügung stellen, so muss hier die Prozesskette eines ITILv3-basierten Servicemanagement bereitgestellt werden. Gefragt sind hier zumindest die Prozesse für ein Incident-Management, bei dem über das Service-Desk die Fehler schnell zur Bearbeitung kanalisiert und Lösungen dokumentiert werden und zur Behebung eines erneuten Fehlerfalles herangezogen werden können. Ein Change-Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, unerwarteten Ausfallzeiten oder sogar Datenverlust führen. Das Problem-Management muss Fehlerhäufigkeiten überwachen, Schwachstellen ermitteln und über den ChangeManagementprozess diese beseitigen. Release-Management, Business-ContinuityManagement und Configuration-Management sind ebenfalls von zentraler Bedeutung für die prozessuale Kompetenz in der Verdichtungs- und Nutzungsphase. Letztlich sollte auch für die interne IT ein Service Level Agreement (SLA) abgeschlossen und durch ein Service Level Management (SLM) sichergestellt werden, dass die spezifischen Anforderungen des Kerngeschäfts an die IT definiert und die Erfüllung dieser Anforderungen strikt überwacht werden. Nur ein gemeinsam vereinbarter und in der betrieblichen Praxis umgesetzter Prozess stellt sicher, dass die interne IT nicht nur zum austauschbaren Technologiepartner des

1.4 Der Informationslebenszyklus-Strategien-Mix

21

Tabelle 1.1. IT-Strategien für die Verdichtungs- und Nutzungsphase (Teil 1) Strategienfeld

Strategie

Softwareinfrastruktur

Bereitstellung eines geschäftskritischen OLTP-Systems. Bereitstellung eines hochverfügbaren CRM-Systems. Bereitstellung eines hochverfügbaren ERP-Systems. Bereitstellung performanter Datenbankmanagementsysteme mit Schutz vor Mehrfacherfassungen (regelbasiert, triggerbasiert). Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc. (beispielsweise Einsatz von Altiris zum Deployment von Software). Verhinderung von Mehrfachkopien.

Unternehmens, sondern zu einem wertvollen Prozesspartner wird, dessen Produktionsprozesse verwoben sind mit den Geschäftsprozessen des Unternehmens. Den Erfolg der besseren Integration der IT in den Geschäftsprozess zeigt der Vergleich der Produktivitätszuwächse zwischen den USA und Europa. In den letzten 12 Jahren konnten die US-Unternehmen pro eingesetzter Arbeitsstunde einen größeren Erfolg und damit einen deutlich höheren Produktivitätszuwachs erzielen als ihre europäischen Wettbewerber. Das Londoner Centre of Economic Performance (CEP) kam in einer aktuellen Analyse zu dem Ergebnis, dass die US-Unternehmen einfach ihre Informationstechnologie besser nutzen. Für die Compliance sind automatisierte Business Intelligence Processes (BIP) vonnöten,die beispielsweise den Weg der Information durch die Lebenszyklusphasen steuern. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. gefragt. Diese in Verbindung mit den „tiered“-Speichersystemen stellen die Strategie für die Informationswertanpassung in der Verdichtungs- und der Nutzungsphase dar. Der Strategien-Mix in der Bewahrungsphase wird implementiert,indem bei der Softwareinfrastruktur die erzeugten Daten zwar den existierenden Geschäftsanwendungen verfügbar gemacht werden, aber nicht mehr mit dem Aufwand und der Sicherheit, wie dies in den drei früheren Phasen des Produktlebenszyklus der Fall war. Hier werden hardwareseitig so genannte Nearline-Techniken als Gegensatz zu den Online-Techniken der ersten drei Informationslebenszyklusphasen eingesetzt. Dies spiegelt einerseits die Entwicklung der Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten wider (vgl. Abbildung 1.5), die in der Phase der Bewahrung eine deutliche Abnahme der Wiederverwendungswahrscheinlichkeit anzeigt, als auch die Kurve des Wertes der Information für das Unternehmen, die einen Anstieg des Wertes nur durch das Eintreten von Ausnahmesituationen darstellt, ansonsten jedoch die Bewahrungsphase bereits als Phase sinkenden Wertes der Information für die Geschäftsprozesse des Unternehmens sieht. Der Zugriff des Unternehmens und der Berechtigten auf die benötigten Services muss zwar störungsfrei gewährleistet sein, jedoch nicht unbedingt sofort ermöglicht werden. Sicherheitsmechanismen für die digitale Sicherheit müssen

22

1 Information – Treibstoff für Produktion und Dienstleistung

Tabelle 1.2. IT-Strategien für die Verdichtungs- und Nutzungsphase (Teil 2) Strategienfeld

Strategie

Hardwareinfrastruktur

Bereitstellung einer hochverfügbaren und abgesichertenNetzwerkinfrastruktur. Bereitstellung (hochverfügbarer) Serversysteme (eventuell der Enterprise-Klasse) in der zentralen IT. Eventuell Bereitstellung von Clustersystemen. Eventuell Bereitstellung von Spreaded-Cluster-Systemen zur Absicherung des Katastrophenfalls (K-Fall). Bereitstellung hochverfügbarer Speichersysteme (eventuell der Enterprise-Klasse) im SAN oder NAS. Bereitstellung remote gespiegelter Speichersysteme zur Absicherung des K-Falls. Bereitstellung eines qualitätsgesicherten Backup-/Restore-Verfahrens.

Prozessinfrastruktur

Bereitstellung eines ITILv3-konformen Service Management. Mindestens Prozessunterstützung von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business Intelligence (BI-) Lösung. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informationswertanpassung

Implementierung der Strategien zu Software-,Hardware- und ProzessInfrastruktur.

automatisiert greifen, Business Intelligence (BI-) Lösungen für die Gewährleistung der Compliance müssen automatisiert durchgeführt werden. Die Vereinfachung der Administration der Softwareinfrastruktur erfordert hier ein ReleaseManagement, das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind. Außerdem muss dafür gesorgt sein, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden. Idealerweise steht auch für den Betrieb der IT-Umgebung für die Bewahrungsphase eine Software zur Verfügung, die den Service Support (zumindest Incident-,Problem- und Change-Management) für die zentralisierte IT unterstützt. Eine Systemmanagementumgebung, die die komplette Infrastruktur (Primär-, Sekundär- und Tertiärtechnik) steuert und überwacht (beispielsweise Tivoli oder z.T.) auch EMC2 mit ECC), ist hier ebenfalls sinnvoll, angepasst an die reduzierte Verfügbarkeitsanforderung und Wertigkeit der Daten. Die spezifischen Alarmierungs- und Eventzyklen sind dabei jedoch länger. Eine permanente Ad-hoc-Verfügbarkeit und Business Continuity auch im Störungsfall ist nicht mehr gefordert. Daher ist ein Cluster-Softwareeinsatz nicht mehr erforderlich und die Softwareunterstützung von lokalen und remote Mirroring-Verfahren, Daten-Cloning und Snapshots sind nur noch bedingt notwendig. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Bewahrungsphase, dass Daten von der kostenintensiven Primärtechnik auf preis-

1.4 Der Informationslebenszyklus-Strategien-Mix

23

Tabelle 1.3. IT-Strategien für die Bewahrungsphase (Teil 1) Strategienfeld

Strategie

Softwareinfrastruktur

Bereitstellung des Zugriffs durch das geschäftskritische OLTP-System, das hochverfügbare CRM-System und das hochverfügbare ERPSystem der Vorphasen. Bereitstellung des Zugriffs durch die performanten Datenbankmanagementsysteme der Vorphasen. Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc. (beispielsweise Einsatz von Altiris zum Deployment von Software). Verhinderung von Mehrfachkopien.

Hardwareinfrastruktur

Bereitstellung einer hochverfügbaren und abgesichertenNetzwerkinfrastruktur. Bereitstellung ausreichend dimensionierter Serversystemein der zentralen IT. Absicherung des K-Falls durch geeignete Datenauslagerungs- oder Remote-Backup-Verfahren. Bereitstellung (hochverfügbarer) Speichersysteme im SAN oder NAS. Bereitstellung eines qualitätsgesicherten Backup-/Restore-Verfahrens.

wertere Sekundärtechnik migriert werden müssen. Die RZ-Infrastruktur wird an die gesunkene Wiederverwendungswahrscheinlichkeit und den gesunkenen Informationswert angepasst. Hier wird keine hochverfügbare Server-, Clusterserverund Speicherinfrastruktur mehr benötigt.Dies erfordert in dieser Phase IT-Sekundärtechnik der Midrange-Klasse mit ausreichender Performance und maximal noch lokal gespiegelten Systemen bzw. Speicher.Auslastungsoptimierung bedeutet hier,stets zu überwachen,dass auf Sekundärtechnik hinreichend Server- und Speichersystemkapazität für das Datenvolumen vorhanden sind, jedoch im Wesentlichen zu prüfen,welche Daten von der Primärtechnik der Enterprise-Klasse auf diese Systeme migriert werden müssen. Ferner gilt es sicherzustellen, dass Daten der Archivierungsphase, also Daten, die nicht mehr für eventuell geschäftsvorfallnahe Verarbeitung benötigt werden, auf die am wenigsten kostenintensiven Medien der Archivierungsphase migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von„tiered“-IT-Plattformen.Die Bewahrungsphase ist innerhalb dieser „tiered“-IT-Plattform durch die Nutzung von Sekundärssystemund Speichertechnologie gekennzeichnet. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Bewahrungsphase bedeutet, dass die IT die Geschäftsprozesse der beiden Vorläuferphasen in IT-Prozesse reduziert, die lediglich die bewahrende Sicherung und den Nearline-Zugriff auf die Daten dieser Phase ermöglichen. Hier ist die IT wiederum als Prozesspartner des Unternehmens gefragt. Wenn Hardware- und Softwareinfrastruktur die zur Erfüllung ihrer Strategien der Bewahrungsphase benötigten Systemkomponenten bereitstellen, so muss hier vor allem die Kenntnis der Geschäftsprozesse die Migration zumindest automatisiert

24

1 Information – Treibstoff für Produktion und Dienstleistung

Tabelle 1.4. IT-Strategien für die Bewahrungsphase (Teil 2) Strategienfeld

Strategie

Prozessinfrastruktur

Bereitstellung eines ITILv3-konformen Service Management. Mindestens Prozessunterstützung von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business Intelligence (BI-) Lösung. Bereitstellung von Migrationsprozessen zur Überführung der Daten aus den Vorphasen in die Software- und Hardwareinfrastruktur der Bewahrungsphase. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informationswertanpassung

Implementierung der Strategien zu Software-,Hardware- und Prozessinfrastruktur.

initiieren. Die Prozesskette des ITILv3-konformen Service Management der vorangehenden Phasen wird weiter genutzt. Gefragt sind hier noch immer die Prozesse für ein Incident-Management, bei dem über einen Service-Desk die Fehler schnell zur Bearbeitung kanalisiert werden und Lösungen dokumentiert werden, die zur Behebung eines erneuten Fehlerfalles herangezogen werden können. Ein Change-Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, unerwarteten Ausfallzeiten oder sogar Datenverlust führen. Das Problem-Management muss dabei u.a. die Fehlerhäufigkeiten überwachen, Schwachstellen ermitteln und über den Change-ManagementProzess diese beseitigen.Release-Management,Business-Continuity-Management, Configuration-Management sind ebenfalls von zentraler Bedeutung für die prozessuale Kompetenz in der Bewahrungsphase. Letztlich sollte auch für eine interne IT ein SLA-Management sicherstellen, dass diese genau weiß, welche Anforderungen das Kerngeschäft an die IT in der Bewahrungsphase hat, und die Erfüllung dieser Anforderungen strikt überwachen. Dieses Kostenbewusstsein mit dem Ziel der Senkung der Total Cost-of-Ownership (TCO) durch datenwertorientierte Datenhaltung bindet die interne IT in die Geschäftsprozesse des Unternehmens ein. Für die Compliance sind die automatisierten Business Intelligence (BI-) Prozesse vonnöten, die beispielsweise den Weg der Information durch die Lebenszyklusphasen steuern. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen usw. gefragt. Diese in Verbindung mit den „tiered“-Speichersystemen als Realisierung für die Hardwareinfrastruktureffizienz stellen ebenfalls die Strategie für die Informationswertanpassung in der Bewahrungsphase dar. Der Strategie-Mix in der Archivierungsphase bedeutet für die Softwareinfrastruktur, die erzeugten Daten lediglich als Fixed-Content, also nicht mehr änderbar, über Archivierungssoftware speicher- und wieder auffindbar zu machen. Dies verursacht einen weitaus geringeren Aufwand bei hoher Sicherheit, der dadurch verursacht wird, dass die Daten nicht mehr online oder nearline zugreifbar sind,

1.4 Der Informationslebenszyklus-Strategien-Mix

25

wie dies in den früheren Phasen des Produktlebenszyklus möglich war. Hier werden hardwareseitig Magnetbandarchivierungen und Content Addressable Storage (CAS-) Magnetplattensysteme für langfristige Aufbewahrungsfristen eingesetzt. Dies spiegelt einerseits die Entwicklung der Kurve der Wiederverwendungswahrscheinlichkeit der erstellten Daten wider, die in der Phase der Archivierung die deutlich niedrigste Wiederverwendungswahrscheinlichkeit der Daten anzeigt, als auch die Kurve des Informationswertes für das Unternehmen, die eine starke Degression des Wertes der Information für die Geschäftsprozesse des Unternehmens sieht. Die Softwareinfrastruktur muss in der Archivierungsphase eine dokumentenechte Abspeicherung der zu archivierenden Daten und eine dokumentenechte Wiederherstellung zu jedem Zeitpunkt der Archivierungsdauer sicherstellen. In der zentralen IT müssen seitens der Softwareinfrastruktur die benötigten Anwendungen zur Archivierung und Retrieval zur Verfügung gestellt werden. Der Zugriff des Unternehmens und der Berechtigten auf die benötigten Services muss zwar störungsfrei gewährleistet sein, jedoch nicht unbedingt sofort ermöglicht werden. Sicherheitsmechanismen für die digitale Sicherheit müssen automatisiert greifen, Business Intelligence (BI-) Lösungen für die Gewährleistung der Compliance müssen automatisiert durchgeführt werden. Die Vereinfachung der Administration der Softwareinfrastruktur erfordert auch hier ein Release-Management, das sicherstellt, dass sämtliche Arbeitsplätze mit dem jeweils gültigen Releasestand der verwendeten Software ausgestattet sind. Außerdem muss sichergestellt sein, dass Updates, Korrekturen und Hilfestellungen automatisiert stattfinden. Im Idealfall steht auch für den Betrieb der IT-Umgebung für die Archivierungsphase eine Software zur Verfügung, die den Service Support (zumindest Incident-, Problem- und Change-Management) für die zentralisierte IT unterstützt. Notwendig ist eine Systemmanagementumgebung, die die komplette Infrastruktur (Primär-, Sekundär- und Tertiärtechnik) steuert und überwacht (beispielsweise Tivoli oder z.T. auch EMC2 ’s mit ECC), ist hier ebenfalls sinnvoll, d. h. angepasst an die reduzierte Verfügbarkeitsanforderung und die Datenwertigkeit. Dabei sind hier die Alarmierungs- und Eventzyklen wesentlich größer. Eine permanente Adhoc-Verfügbarkeit und Business Continuity auch im Störungsfall ist nicht mehr gefordert. Daher ist ein Cluster-Softwareeinsatz nicht mehr notwendig und in der Folge eine Softwareunterstützung von lokalen und von „remote“-MirroringVerfahren, Daten-Cloning und Snapshots nur noch bedingt über die Steuerungsund Administrationssoftware der eingesetzten Archivierungshardware. Bezüglich der Hardwareinfrastruktur erfordert die Realisierung der Strategie der Steigerung der Infrastruktureffizienz durch Auslastungsoptimierung in der Archivierungsphase, dass Daten von der kostenintensiven Primär- und/oder Sekundärtechnik auf preiswerte Archivierungstechnik migriert werden müssen. Die RZ-Infrastruktur wird an die gesunkene Wiederverwendungswahrscheinlichkeit und den gesunkenen Informationswert angepasst. Hier wird keine hochverfügbare Server-, Clusterserver- und Speicherinfrastruktur mehr benötigt. Dies erfordert in dieser Phase IT-Archivierungstechnik für Fixed Content (FC) mit automatisiert gespiegelten SATA-Platten oder Magnetbandbibliotheken mit den jeweils not-

26

1 Information – Treibstoff für Produktion und Dienstleistung

Tabelle 1.5. IT-Strategien für die Archivierungsphase Strategienfeld

Strategie

Softwareinfrastruktur

Bereitstellung von Fixed-Content-Archivierungs- und dearchivierungssoftware. Gewährleistung automatischer Softwareupdates, Korrekturen, Releasewechsel etc.(beispielsweise Einsatz von Altiris zum Deployment von Software). Verhinderung von Mehrfachkopien.

Hardwareinfrastruktur

Bereitstellung einer hochverfügbaren und abgesicherten Netzwerkinfrastruktur. Bereitstellung ausreichend dimensionierter Serversysteme in der zentralen IT zur Archivierung und Dearchivierung. Absicherung des Katastrophenfalls durch geeignete Datenauslagerungs- oder Remote-Backup-Verfahren. Bereitstellung (hochverfügbarer) Content Addressable Storage (CAS) oder archivierungssichererTape-Systeme. Bereitstellung eines qualitätsgesicherten Backup- und Restore-Verfahrens.

Prozessinfrastruktur

Bereitstellung ITILv3-konformen Service Management. Mindestens Prozessunterstützung von Incident-, Change-, Problem-, Configuration- und Release-Management. Compliance-Überwachung durch Einführung einer prozessgeführten Business Intelligence (BI-) Lösung. Bereitstellung von Migrationsprozessen zur Überführung der Daten aus den Vorphasen in die Software- und Hardwareinfrastruktur der Archivierungsphase. Bereitstellung eines (automatisierten) Monitoring- und Administrationssystems für die komplette Hard- und Softwareinfrastruktur.

Informationswertanpassung

Implementierung der Strategien zu Software-,Hardware- und Prozessinfrastruktur.

wendigen Umkopierungsaktivitäten bei Medien- oder Software-Releasewechseln. Auslastungsoptimierung bedeutet zu überwachen, dass die Archivierungstechnik hinreichend Server- und Speichersystemkapazität zur Verfügung hat und damit welche Daten von der Primärtechnik der Enterprise-Klasse und der Sekundärtechnik der Midrange-Klasse auf diese Systeme migriert werden. Realisiert wird die Infrastruktureffizienz durch die Implementierung von „tiered“-IT-Plattformen. Die Archivierungsphase ist innerhalb dieser „tiered“-ITPlattform durch die Nutzung von Archivierungssystem- und Speichertechnologie gekennzeichnet. Die Strategie der Unterstützung der Geschäftsprozesse durch die Prozessinfrastruktur in der Archivierungsphase bedeutet, dass die IT die Geschäftsprozesse zur Archivierung in IT-Prozesse reduziert, die lediglich die dokumentenechte Langzeitspeicherung und die dokumentenechte Wiederherstellung dieser Daten ermöglichen. Hier ist die IT wiederum als Prozesspartner des Unternehmens gefragt, um gemäß den Geschäftsprozessen die Migration zumindest automatisiert

1.4 Der Informationslebenszyklus-Strategien-Mix

27

zu initiieren und eventuell projektorientiert durchzuführen. Die Prozesskette des ITILv3-konformen Service Management der vorangehenden Phasen wird weiter genutzt. Gefragt sind hier noch immer die Prozesse für ein Incident-Management, bei dem über einen Servicedesk die Fehler schnell zur Bearbeitung kanalisiert werden und Lösungen dokumentiert werden, die zur Lösung eines erneuten Fehlerfalles herangezogen werden können. Ein Change-Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, unerwarteten Ausfallzeiten oder sogar Datenverlust führen. Das ProblemManagement muss Fehlerhäufigkeiten überwachen, Schwachstellen ermitteln und über den Change-Management-Prozess diese beseitigen. Release-Management, Business-Continuity-Management und Configuration-Management sind ebenfalls von Bedeutung für die prozessuale Kompetenz in der Archivierungsphase. Letztlich sollte auch für eine interne IT ein SLA-Management sicherstellen, das genau weiß, welche Anforderungen das Kerngeschäft an die IT in der Archivierungsphase hat, und die Erfüllung dieser Anforderungen strikt überwachen. Dieses Kostenbewusstsein mit dem Ziel der Senkung der TCO durch datenwertorientierte Datenhaltung bindet die interne IT in die Geschäftsprozesse des Unternehmens ein. Für die Compliance sind automatisierte Business Intelligence (BI-) Prozesse vonnöten, die den Weg der Information durch die Lebenszyklusphasen steuern. Hier sind Prozesse zur Benutzerautorisierung, Datenschutz, Datensicherheit, synchrone und asynchrone Abgleiche mit zentralen Systemen gefragt. Dieses in Verbindung mit den „tiered“-Speichersystemen als Realisierung für die Hardwareinfrastruktureffizienz stellen die Strategie für die Informationswertanpassung in der Archivierungsphase dar. Die Compliance-Anforderungen an langfristige Speicherung und Aufbewahrung geschäftsvorfallrelevanter Informationen sorgen für einen immensen Anstieg der gesamten zu speichernden (und wiederzugewinnenden) Datenmenge. So sind die gemäß Sarbanes-Oxley Act und diversen anderen Gesetzgebungen für die USA definierten Aufbewahrungszeiten unterschiedlicher Informationen beträchtlich. Sämtliche Informationen, bezogen auf die Herstellung, Verarbeitung und Verpackung von Lebensmitteln, müssen für mindestens zwei Jahre nach Verkauf aufbewahrt werden (Pharmaceutical/Life sciences 21 CFR Part II). Die Daten zu Herstellung, Verarbeitung und Verpackung von Drogeriewaren und Waren der pharmazeutischen Industrie müssen mindestens 3 Jahre nach Auslieferung aufbewahrt werden (Pharmaceutical/Life sciences 21 CFR Part II). Herstellungsdaten biologischer Produkte müssen 5 Jahre nach Herstellungsende archiviert werden (Pharmaceutical/Life sciences 21 CFR Part II). Sämtliche fallspezifischen Informationen aus Krankenhäusern müssen 5 Jahre archiviert werden (Health Care HIPAA). Medizinische Daten von Minderjährigen müssen 21 Jahre aufbewahrt werden (Health Care HIPAA). Sämtliche Patientendaten müssen bis 2 Jahre nach dem Tod eines Patienten archiviert werden (Health Care HIPAA). • Im Bereich der Finanzinstitutemüssen nach SEC 17a-4 sämtliche Kontenbewegungen für drei Jahre, die Zulassungen für Broker (Makler) und Dealer (Händler) müssen bis zur Liquidation des Handelshauses oder der Firma des Mak-

28

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.11. Die Entwicklung des Speicherbedarfs

lers und Händlers aufbewahrt werden. Sämtliche Transaktionen eines Kunden eines Händlers oder Maklers müssen 6 Jahre nach Abschluss der letzten Transaktion dieses Kunden aufbewahrt werden. • Die Occupational Safety and Health Administration (OSHA) regelt den Umgang mit Daten geprüfter Personen, die Kontakt zu toxischen Substanzen haben. Daten dieses Personenkreises müssen bis zu 30 Jahre nach dem Audit der Person aufbewahrt werden. • Der Sarbanes-Oxley Act fordert die dokumentenechte Aufbewahrung jeglicher Dokumente aus einer Rechnungsprüfung von börsennotierten Unternehmungen für mindestens 4 Jahre nach Abschluss der Rechnungsprüfung. Diese Entwicklung sorgt für einen exponentiellen Verlauf der Kurve der archivierten Daten mit einer Steigerungsrate von jährlich über 60 Prozent, während die auf primären und sekundären Speichersystemen gespeicherten und administrierten Datenmengen hingegen relativ moderat mit lediglich etwas mehr als 20 Prozent Steigerungsrate ansteigen. Dies zeigt, dass trotz der immensen Menge der zu speichernden Daten der Erfassungs-, Verdichtungs- und Nutzungsphase des Informationslebenszyklus eine weitaus größere Herausforderung in der Datenflut der Bewahrungs- und Archivierungsphase liegt.

1.4 Der Informationslebenszyklus-Strategien-Mix

29

Abbildung 1.12 setzt diese Steigerungsrate der gespeicherten und archivierten Datenmengen in Relation zu der Wiederverwendungshäufigkeit der Daten. Diese Relation zeigt wiederum deutlich, dass die Wiederverwendungshäufigkeit des weitaus größten Teils der gespeicherten Daten relativ gering ist. Dies deutet darauf hin, dass Daten mit geringem operativem Wert für das Unternehmen den weitaus größten Teil des Speicherbedarfs darstellen. Hier muss aus TCO-Betrachtungen mit Projekten angesetzt werden, die Speicherkonsolidierung dahingehend betreiben, dass die zu bewahrenden und zu archivierenden Datenmengen auf TertiärSpeichertechnologien migriert werden und nicht teure Primär- und Sekundärspeichertechnologien nutzen. Primär-Speichertechnologien (Tier 1 Storage) sind gekennzeichnet durch • Magnetplatten(-systeme) der Enterprise-Klasse (HDS TagmaStore,EMC2 Symmetrix DMX etc.), • hochperformante Speicheranwendungen (beispielsweise EMC2TimeFinder, SRDF usw.), • Mirroring und Replikation und • synchrone und asynchrone Spiegelung. Sie werden eingesetzt in den Phasen Erstellung, Verdichtung und Nutzung und bedienen vor allem die so genannten Mission-critical-Anwendungen wie hochperformante OLTP-Systeme, CRM- und ERP-Systeme. Sekundär-Speichertechnologien (Tier 2 Storage) setzen auf • Midrange Magnetplatten(-systeme) (beispielsweise EMC2 CLARiiON, Sun/ StorageTek FLX-Systeme, IBM DS8xxx Speichersysteme etc.) eventuell mit günstiger SATA-Technologie und Disk-Libraries (virtuelle Magnetbänder). • Point-in-Time-Replikationen und Snapshots werden für unveränderliche Daten aus den ersten Informationslebenszyklusphasen, für die Daten der Bewahrungsphase sowie für Backup, Recovery und Referenzdaten verwendet. Tertiär-Speichertechnologien (Tier 3 Storage) werden verwendet für • die langfristige Aufbewahrung von Daten und für gemäß Archivierungsvorschriften zu archivierende unveränderliche Daten der Archivierungsphase des Informationslebenszyklus, • Audio-, Video- oder medizinische Daten sämtlicher Lebenszyklusphasen, • Content Addressable Storage (CAS; z.B. EMC2 CENTERA), • Magnetbandbibliotheken, Deep Archive und • optische Speichermedien. Die Umsetzung der IT-Strategien für sämtliche Phasen des Informationslebenszyklus wird durch die IT-Industrie im Allgemeinen und die Speicherindustrie im Besonderen durch Bereitstellung der entsprechenden Produkte und Dienstleistungen unterstützt. Die Umsatzentwicklung der Speicherindustrie trägt bereits heute dem Trend zum Information Lifecycle Management durch die Implementierung der IT-Strategien Rechnung. So waren 2004 die Dienstleistungen im Speichermarkt

30

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.12. Wiederverwendungswahrscheinlichkeit-Datenmenge-Relation

mit einem Jahresumsatz von 24,9 Milliarden US-Dollar bereits der mit Abstand größte Umsatzträger der Speicherindustrie. Diese Dienstleistungen sind heute im Wesentlichen solche, die die Implementierung von „tiered“-Speichertechnologien unterstützen, also Services, die bei der Implementierung der Prozessinfrastruktur und der Informationswertanpassung für sämtliche Phasen des Informationslebenszyklus helfen. Die Umsätze im Segment der Speichersoftware haben in den letzten Jahren immens zugenommen und in 2004 bereits einen Jahresumsatz von 7,8 Mrd. US $ erreicht. Die Speichersoftware umfasst die Bereiche der direkten Steuerung und der Performance-Steigerung der Speichersysteme (Micro- und Flarecodes) sowie Spiegelungs- und Business Continuity (BI-) Funktionen. Mit jährlichen Umsatzwachstumsraten von über 30 Prozent tragen heute insbesondere auch die integrierten Administrationsapplikationen bei. Diese unterstützen die IT-Strategien zur Softwareinfrastruktur über sämtliche Phasen des Informationslebenszyklus. Die Umsätze für Speicherhardware unterteilen sich im Jahr 2004 in 20,6 Mrd. US $ für (Platten-)Speichersysteme (sowohl Tier 1 und Tier 2, als auch die CASSysteme der Tier-3-Speichertechnologie), 2 Mrd. US $ für Fiber Channel Switches, Direktoren und Host Bus Adapter sowie 4,3 Mrd. US $ für die Magnetbandautomation (Libraries) für sämtliche Phasen des Informationslebenszyklus. Diese Techniken stellen das Reservoir für die phasenkonforme Implementierung der Hardwareinfrastruktur dar.

1.4 Der Informationslebenszyklus-Strategien-Mix

31

Auf Basis der Informationswertaufbewahrungszeit-Matrix (im nächsten Abschnitt detailliert) zeigt die Portfolioanalyse das Informationsmanagement eines Unternehmens in Form des IT-Strategien-Mix über die Phasen des Informationslebenszyklus. Die angebotenen Technologien und Services leisten bei der Implementierung einen wesentlichen Beitrag zum Information Lifecycle Management. Allein eine Total Cost-of-Ownership (TCO-) Betrachtung über sämtliche Phasen des Informationslebenszyklus fordert von der IT, die Erfolgspartner ihres Unternehmens sein will, ein Information Lifecycle Management zu implementieren. Als Prozesspartner des Unternehmens ist sie allein zur Unterstützung der legislativen Anforderungen an die Datenhaltung gefragt, wie wir sie im Anschluss an die Informationswertaufbewahrungszeit-Matrix darstellen werden.Die IT muss die Archivierungsprozesse zur Implementierung der Geschäftsprozesse der Archivierung über eine „multi tier“ Information Lifecycle Management (ILM-) Landschaft implementieren. Damit wird die Unternehmens-IT zu einem wirklichen Produktpartner Ihres Unternehmens. Ein Beispiel dafür könnte die IT eines Telekommunikationsunternehmens darstellen (siehe Beispiel in Kapitel 3). Diese beschafft zur Speicherung der Daten der Archivierungsphase des Informationslebenszyklus eine Tier-3-Speicherhardware und -software. Diese ist jedoch auch zu nutzen für ein Client-Online-Backup, die Datensicherung von PCs der Kunden, die von dem Telekommunikationsunternehmen die DSL-Zugänge zum Internet geliefert bekommen. Das Client-OnlineBackup wird somit zu einem zusätzlichen Produkt des Kerngeschäftes des Telekommunikationsunternehmens, das aus der IT als Produktpartner des Unternehmens in das Kerngeschäft des Unternehmens gegeben wurde. Information Lifecycle Management ist also nicht nur als lästige Aufgabe zu betrachten. Es liefert über TCO-Betrachtungen hinweg dem IT-Management eine Vielzahl an Möglichkeiten, sich enger in das Kerngeschäft seines Unternehmens einzubinden.

32

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.13. IT-Entwicklung und ILM

1.5

Die Informationswert-Aufbewahrungszeit-Matrix

Aus Sicht von Moore wird es immer wichtiger zu verstehen, wo Daten während ihres Lebenszyklus idealerweise gespeichert und wie sie verwaltet werden sollten. Er postuliert für die Mehrzahl digitaler Daten die Maxime „90 Tage auf Platte und 90 Jahre auf Magnetband“8 und stellt dabei die These auf, Daten sollten 30 Tage nach ihrer Erstellung auf Tier-1-Speichersystemen, vom 31. bis 90. Tag ihrer Existenz auf Tier-2-Speicher und danach auf Tier-3-Speicher aufbewahrt werden.Diese These wird in Abbildung 1.14 noch durch den Parameter „Wiederherstellungszeitziel“ unterstrichen, die die diametrale Entwicklung von Aufbewahrungszeit und Wiederherstellungszeit dokumentiert. Dabei unterstellt Moore in seinem Datenlebenszyklusmodell, dass der Wert der Information jeweils innerhalb der einzelnen Speicherebenen (Tier 1 bis Tier 3) ansteigt und abfällt, der Informationswert eine alternierende Folge zwischen ansteigenden und abfallenden Werten darstellt. Diese Einschätzung vom Verlauf des Informationswertes hat unseres Erachtens die Schwachstelle, dass Moore bei diesem Verlauf schlicht von einer festen 90-Tage-Maxime ausgeht und dabei unterschiedliche Lebenszyklen von Informationen außer Acht lässt. Außerdem sind für ihn die determinierenden Parameter lediglich

8

Moore, Fred: Storage New Horizons, a.a.O., S. 12.

1.5 Die Informationswert-Aufbewahrungszeit-Matrix

33

Abb. 1.14. Das Datenlebenszyklusmodell nach Moore9

• • • •

Wiederverwendungswahrscheinlichkeit, Datenmenge, Zeitraum seit Datenerstellung und Wiederherstellungszeitziel.

Wir haben in unseren Projekten im Rahmen umfangreicher Analysen festgestellt, dass sich jede Information innerhalb eines Zyklus in den Erstellungs-, Verdichtungs-, Nutzungs-, Bewahrungs- und Archivierungsphase bewegt, die nicht nach einem bestimmten oder festen Theorem hinsichtlich ihrer jeweiligen Dauern gespeichert werden müssen. Außerdem konnten wir feststellen, dass die Parameter für die Strategien innerhalb des Informationslebenszyklus über die Moore’schen hinaus sich ergeben aus: • • • • • • • • 9

Betriebszeit, Betriebsnebenzeiten, Physische Wiederherstellzeit, Logische Wiederherstellzeit, Maximaler geplanter Datenverlust, Notwendigkeit eines Service-Desks, Reaktionszeit und Notwendigkeit einer Bereitschaft. Moore, Fred, Storage New Horizons, a.a.O., S. 12.

34

1 Information – Treibstoff für Produktion und Dienstleistung

Abb. 1.15. Der Wert der Daten, u.a. nach Moore10 und eigenen Analysen

Informationen gewinnen in den späteren Lebenszyklusphasen nur durch Eintreten von Sonderbedingungen nochmals an operativem Wert für das Unternehmen.Ansonsten verlieren sie jedoch in den späteren Lebenszyklusphase (Bewahrungs- und Archivierungsphase) überproportional an Wert, so dass sich die Kurve der Wertentwicklung für die Information im Informationslebenszyklus der Wiederverwendungswahrscheinlichkeit annähert. Daher kann eine Portfolioanalyse zum Aufbau des Informationsmanagements unseres Erachtens auf Basis der Informationswertaufbewahrungszeit-Matrix nur dergestalt ausfallen, dass die beiden Faktoren klar die IT-Strategien für das Information Lifecycle Management und damit für eine IT als Erfolgspartner des Unternehmens repräsentieren. Die Problem Children (s.Abbildung 1.16), bezogen auf die gespeicherten Informationen, sind die Daten die in der Erstellungsphase mit hohem Informationswert für das Geschäft des Unternehmens und einer noch nicht klar bestimmten Aufbewahrungszeit anfallen. Diese Informationen durchlaufen die Verdichtungsphase, bis sie genutzt werden. Hier haben eine Vielzahl der erfassten Informationen nur eine kurze Lebenszeit. Wir stimmen mit dem Moore’schen Theorem in der Weise insofern überein, als innerhalb der ersten Phase, bei Moore die ersten 30 Lebenstage, in unserem Modell in Abhängigkeit vom Geschäftsprozess (d. h. innerhalb einer Spanne von wenigen Tagen bis Monaten), es sich entscheidet, wie der weitere Weg des Informations10

Moore, Fred, Storage New Horizons, a.a.O., S. 12.

1.5 Die Informationswert-Aufbewahrungszeit-Matrix

35

Abb. 1.16. Die Informationswert-Aufbewahrungszeit-Matrix

lebenszyklus verläuft. Innerhalb der Verdichtungs- und Nutzungsphase haben die Informationen einen hohen Geschäftswert für das Unternehmen und vermutlich noch eine lange Aufbewahrungszeit. Mit der Nutzung der Daten unterliegen diese den Anforderungen an eine eventuell geforderte Langzeitarchivierung. Die Star-Informationen sind Informationen der Verdichtungs- und Nutzungsphase und werden gegen Ende der Nutzungsphase zu den Cash-Cow-Informationen, d. h. zu Informationen, die keiner weiteren Änderung mehr unterliegen und damit in der Prozessinfrastruktur keine weiteren Kosten mehr erzeugen, aber für das Tagesgeschäft des Unternehmens weiter genutzt werden, bis sie in die Bewahrungsphase gelangen. Diese Informationen am Ende ihrer Nutzungsphase und ihrer Bewahrungsphase sinken in ihrem Wert für das Unternehmen, haben jedoch durch die noch anstehende Archivierungsphase vermutlich noch eine längere „Rest“-Aufbewahrungszeit. Als Dogs bezeichnet man die Informationen, die gegen Ende der Archivierungsphase nur noch einen geringen Wert für das Unternehmen und eine vermutlich geringen „Rest“-Aufbewahrungszeit haben. Das Finden des richtigen Informationsportfolios ist Aufgabe des IT-Informationsmanagements. Der richtige IT-Strategien-Mix im Informationslebenszyklus ist der Weg zu diesem Ziel. Die Implementierung des Strategien-Mix, d. h. die richtige Dimensionierung des Zyklus, bestehend aus Erstellungs-, Verdichtungs-, Nutzungs-,Bewahrungs- und Archivierungsphase,im Sinne einer Aufbewahrungs-

36

1 Information – Treibstoff für Produktion und Dienstleistung

zeit-Matrix sowie deren geeignete IT-technische Realisierung, ist die zentrale Aufgabe des Information Lifecycle Management, wie in den folgenden Kapiteln unter Beachtung aller primären und sekundären Anforderungen beschrieben wird.

2 Information Lifecycle Management (ILM-) Modelle

ILM ist zuerst einmal konzeptionell unabhängig vom Geschäftsmodell. Trotzdem beeinflusst die Entscheidung zugunsten eines Information Lifecycle Management nachhaltig die Leitlinien für die unternehmerischen Entscheidungen und den Einsatz der Mittel über einen langen Zeitrahmen. Insbesondere vor dem Hintergrund der Langfristigkeit der ILM-Entscheidungen gilt es für das Management, die richtigen Antworten zu finden auf die zentralen Fragen: • Wie werden die Kundenbedürfnisse zukünftig aussehen? • Wie wird der Wettbewerb auf Veränderungen reagieren, wie Technologien sich entwickeln – wer kann darüber sichere Aussagen machen? • Was ist überhaupt möglich? In der Theorie beruhen weise Entscheidungen auf Wissen, Nachdenken und viel Zeit. In der Praxis jedoch sind Weisheit und Zeit ziemlich knappe Güter, weil Wissen oder Zeit zum Nachdenken fehlt. Der Grieche Perikles formulierte schon vor fast zweitausendfünfhundert Jahren: „Es kommt nicht darauf an, die Zukunft vorauszusagen, sondern auf sie vorbereitet zu sein.“11 Winston Churchill äußerte sich zum Thema Zukunftsvorhersage: „Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen.“12 Also stellt sich die Frage: Gibt es eine Methode, die zuverlässig und trotzdem einfach genug ist, um unter großem Zeitdruck die richtigen Prioritäten zu setzen? Es gibt eine solche Methode. In vielen Situationen besteht die Möglichkeit, vorhandene typische Strukturen und Informationen auszunutzen.Beobachtet man die Vorgänge in verschiedenen Unternehmen, so lassen sich vereinfacht folgende Bereiche mit Handlungsbedarf lokalisieren: • • • • • •

Festlegung der IT-Strategie Klärung der Anforderungs- bzw. Problembereiche Klärung der technischen Erfordernisse Interner Klärungsprozess von Angeboten und Begrifflichkeiten Evaluierung des Anbietermarktes Bewertungen unter Preis-/Leistungs-Gesichtspunkten

Denn es gilt: „Glück hat auf Dauer doch wohl meist nur der Tüchtige.“13 11 12 13

Perikles, Deutsche Nationalbibliothek, http//dispatch.opac.d-nb.de. Winston Churchill, Mark Twain, Karl Valentin, http://de.wikipedia.org/wiki/prognose. Moltke, http://de.wikiquote.org/wiki/Gl/C3/BCck.

38

2 Information Lifecycle Management (ILM-) Modelle

2.1 Herausforderung: Strategisches Handeln „Strategie ist eines jener Wörter, die wir gern auf eine bestimmte Weise definieren, jedoch auf eine andere Weise verwenden.“14 Es gibt sehr viele Definitionen der Strategie. Für den einen ist sie ein Plan, für den anderen ein Muster, für den Dritten eine Art List. Das Wort Strategie stammt aus dem Griechischen. Es wurzelt in „strategos“, was so viel heißt wie Feldherr, und „agein“, gleichbedeutend mit „führen“. Etymologisch wird es definiert als „Plan für das Vorgehen“. Vor diesem Hintergrund wundert es nicht, dass Strategie als Konzept zuerst in militärischem Zusammenhang auftauchte – lange vor den Griechen zum Beispiel in China. Wer kennt nicht die 36 Strategien zum Sieg.15 Aber schon viel früher – am Anfang der Evolution – gab es bereits ein wesentliches Merkmal der Strategie,den Wettbewerb. Dies führte den Harvard-Professor Wilson zu der Erkenntnis, dass die Wirtschaft „ein Zweig der Biologie im weitesten Sinn“ ist.16 Die Strategie lässt sich auch als Weg zum Ziel verstehen: • Sie gibt Richtungen und Handlungsbahnen vor. • Sie bestimmt die Leitlinien für unternehmerische Entscheidungen und den Einsatz der Mittel. Ganz unabhängig aber von einzelnen Definitionen sind drei Arten von Strategien zu unterscheiden, die „beabsichtigten“, die realisiert werden, die „beabsichtigten“, die nicht realisiert werden, sowie die„nicht beabsichtigten“, die umgesetzt werden. Warum diese Unterscheidung? Ganz einfach, weil die Praxis zeigt, dass realisierte, erfolgreiche Strategien nicht immer beabsichtigt waren. Und dass – im Gegenzug – beabsichtigte Strategien nicht immer umgesetzt werden. Am häufigsten taucht in der Praxis die „nicht beabsichtigte“ Strategie auf. Die meisten Unternehmer setzen nicht alles um, was sie sich ursprünglich vorgenommen haben, weichen aber auch nicht zu stark von der ursprünglichen Strategie ab. Diese Art von Strategie ist eine, die sich im Laufe der Zeit herausbildet (emergent strategy). Sie ist – allen Erfahrungen nach – die erfolgreichste. Leicht nachvollziehbar ist deshalb, dass sich in einem adaptiven Strategie-Typus beides trifft: • das kontrollierte Vorgehen und • die Offenheit für Lernerfahrungen, welche die Realität oft erfordert. Exakte Planung bis ins Detail kann es nicht geben – dies gilt insbesondere für ILM – und ist auch gar nicht erstrebenswert. Wer aber deshalb strategisches Vordenken ignoriert, kommt ebenso in Bedrängnis. Erfolgversprechend dagegen erweist sich der Weg der geplanten Evolution und Adaption. Er erstreckt sich im Spannungsfeld von klar gesetzten Zielen und noch zu gewinnenden Erfahrungen. Für diesen Umgang mit der Realität ist ein konzeptionelles Raster erforderlich. Ein Filter, mit dessen Hilfe die Ereignisse und Entwicklungen gedeutet, bewertet und rationalisiert werden. Auf eine Strategie bezogen heißt das ein Muster von Handlungen, 14 15 16

Mintzberg, http://de wikipedia.org/wiki/Henry Mintzberg. Sun Tsu, Sunzi, Die Kunst des Krieges, www.methode.de/bu/stb/tisunt1.htm. Wilson, http://en.wikipedia.org/wiki/Edward Osborne Wilson.

2.1 Herausforderung: Strategisches Handeln

39

die aufeinander abgestimmt sind – und zwar dauerhaft und konsistent. Dabei gilt der Grundsatz, je mehr Unsicherheiten das Umfeld aufweist, desto wichtiger wird ein System, dem Unwägbaren zu begegnen. Anders gesagt, je unberechenbarer die Ereignisse im Wettbewerbsumfeld, desto wichtiger wird strategische Planung. Strategien spielen daher immer dort eine Rolle, wo es um komplexe Wettbewerbsverhältnisse geht. Dies gilt nicht nur in Wirtschaft, Politik und Verteidigung, sondern auch beim Spiel. Welches Spiel liegt also der Strategie – als „Königsdisziplin“ des Managements – näher als Schach? Es gibt viele Parallelen: • Keine Strategie ohne Schachzüge. • Keine gewonnene Schachpartie ohne kluge Strategie. Schach stellt nicht nur in stilisierter Form alte Schlachtordnungen dar, sondern auch ein diffiziles Wettbewerbssystem. Die Konsequenz eines einzelnen Zuges ist nicht sofort erkennbar. Strategisch denken heißt, nach vorn zu schauen, Veränderungen in Markt und Wettbewerb zu antizipieren, Trends und Wachstumsfelder aufzuspüren.Dazu gehört insbesondere Mut.Eine – durchaus beabsichtigte – Folge davon sind strategische Entscheidungen, die Märkte bewegen können. Interessant ist auch, worauf der Erfolg von Schachcomputern beruht: • Mustererkennung und • Faustregeln. Zwei Fähigkeiten, die auch Bestandteile von Strategien im Wettbewerb sind. Dennoch gestalten sich diese ungleich komplizierter. Schließlich ist die Wirtschaft kein System, das sich auf 64 Feldern abspielt, sondern auf einem Terrain der ungezählten – und zum Teil unvorhersehbaren – Möglichkeiten. Dies gilt natürlich insbesondere für ILM, da hier die Entwicklung über mehrere Jahre antizipiert werden muss. In herkömmlichen IT-Umgebungen sind Ressourcen wie Server und Speichersysteme meist den einzelnen Anwendungen oder einem bestimmten Geschäftsprozess fest zugeordnet. Um Belastungsspitzen abzudecken, sind die einzelnen Systeme in der Regel für den durchschnittlichen Betrieb deutlich überdimensioniert. So laufen zum Beispiel Server meist mit nur einer durchschnittlichen Auslastung im unteren Prozentbereich. Falls dennoch ein System vorübergehend an seine Leistungsgrenzen stoßen sollte, können die zu diesem Zeitpunkt verfügbaren Ressourcen der anderen Komponenten nicht für diese Anwendung genutzt werden. Auch die Betriebsführung muss sich weiterentwickeln. Die Tendenz geht hier weg vom herkömmlichen Ressourcenmanagement hin zum Service- und Businessmanagement. Während das Ressourcenmanagement einen sicheren IT-Betrieb gewährleistet und IT-Services sicherstellt, steuert das Servicemanagement die IT-Prioritäten durch SLAs und verbessert deren Qualität durch den Einsatz von ITIL-basierten Best Practices. Das Businessmanagement integriert auf Basis einer Service Oriented Architecture (SOA) schließlich die IT vollständig mit den Geschäftsprozessen. So werden beispielsweise Abhängigkeiten zwischen Geschäftsprozessen und IT-Ressourcen abgebildet und bei Veränderungen in der IT die Auswirkungen auf das Geschäft analysiert.

40

2 Information Lifecycle Management (ILM-) Modelle

ILM-Lösungen bieten unbestreitbar eine Reihe an Nutzeneffekten. Damit diese zur Wirkung kommen, müssen allerdings sowohl die Rahmenbedingungen als auch die Vorstellungen ihres Einsatzes im Unternehmen stimmen. Die einfache Lösung ist oftmals die bessere. Dies gilt insbesondere für ILM. Konsolidierte und standardisierte Infrastrukturen erleichtern nicht nur die Virtualisierung. Unternehmen profitieren auch von einer einfacheren Administration. Anstatt mit zahlreichen unterschiedlichen Software-Tools die Insellösungen zu verwalten, können sie nun die gesamte IT unter einer Oberfläche administrieren. Das so genannte Unified Infrastructure Management führt dabei nicht nur die Verwaltung lediglich der Server oder nur der Speicherlösungen zusammen, sondern vereint beide in einer umfassenden Ansicht. Offene Schnittstellen erlauben darüber hinaus die Anbindung der Hardwareverwaltung an weiter reichende Managementlösungen. Die Schnittstellenproblematik sieht auf grafischen Darstellungen mit den gewachsenen Point-to-Point-Verbindungenzwischen allen vorhandenen Applikationen oftmals dramatisch aus. Hinzu kommen Berechnungsformeln, die allein auf der Anzahl der Applikationen beruhen. Nur in wenigen Fällen wird dabei der Hinweis gebracht, dass in der Praxis nur sehr selten jede Applikation mit allen anderen verbunden ist und auch nicht sein muss. Entsprechend lohnt sich in vielen Unternehmen ein genauer Blick auf die Schnittstellenlandschaft. In der IT-Strategie wird in vielen Unternehmen auf gewohnte Konzepte gesetzt. Hierzu gehören die kurzfristige Umsetzung von fachlichen Anforderungen, erprobte programmiertechnische Methoden, produktorientierte Entscheidungen und Absicherung durch die Entscheidung für so genannte Marktführer. Zu selten werden für die gesamte IT gültige Modelle für eine einheitliche Systemarchitektur erarbeitet und konsequent umgesetzt. Dort, wo es versucht wird, bleibt der Ansatz oftmals bereits an der Oberfläche stecken, so dass konkrete Realisierungen die ursprünglichen Absichten unterlaufen. Im Umfeld der Überlegungen zur Einführung von ILM gehört jedoch auch die grundsätzliche Erörterungen der IT-Infrastruktur,der zukunftsweisenden Systemarchitektur mit der entsprechenden Integrations- bzw. den Ablösungsplänen der vorhandenen Plattformen und Applikationen sowie den Richtlinien für zukünftige Anwendungsentwicklungen in Form einer allgemeingültigen IT-Strategie. Grundlage einer Bewertung technischer Erfordernisse bilden die klassischen Größen Performanceanforderungen, Transaktionsvolumen, Komplexität der Datenflüsse und Geschäftsprozesse sowie Betriebs- und Backup-Zeiten. Die Gründe für einzelne Problemstellungen können dabei sehr unterschiedlich sein und Maßnahmen sind individuell zu entscheiden. Dabei bilden technische Reaktionen allein ohne begleitende organisatorische Maßnahmen nicht immer einen nachhaltigen Lösungsansatz. Organisatorische Maßnahmen sind nicht auf Änderungen von Prozessen beschränkt, sondern können z. B. auch das Datenmanagement von Dateien (Downloads aus dem Internet) betreffen. Weiterhin spielen insbesondere in Auswahlverfahren für Systemkomponenten sowie kompletter Systeme architektonische Strategien eine wesentliche Rolle.

2.2 Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle

41

Je nach spezifischer Ausgangssituation lassen sich in Unternehmen regelmäßig die Bereiche Geschäftsprozesssteuerung, Datenflusssteuerung, Kommunikation und Schnittstellen herauskristallisieren. Häufig werden alle Bereiche als Anforderung in ein Projekt eingebracht. Viele IT-Projekte in Unternehmen scheitern. Schuld daran ist oft das Topmanagement. Weil die Führungsriege nicht die Verantwortung für die wichtigsten IT-Entscheidungen übernimmt, laufen die Vorhaben immer wieder ins Leere. Dies gilt insbesondere für ILM-Projekte mit den sich abzeichnenden langen Projektlaufzeiten, dem Einsatz der Mittel über einen langen Zeitraum und der Notwendigkeit, die Veränderungen im Markt und im Wettbewerb zu antizipieren, Trends und Wachstumsfelder aufzuspüren und mutig in eine Folge von strategischen Projektentscheidungen umzusetzen. Die besondere Schwierigkeit bei ILM-Projekten liegt in der relativ langen Laufzeit und der Notwendigkeit der Koordination verschiedener, quasiparalleler Projekte begründet.

2.2 Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle Tagtäglich entsteht in Unternehmen eine regelrechte Flut unterschiedlicher Daten und Inhalte. Informationen sind dabei zu einem strategischen Vermögen jedes Unternehmens geworden mit der Charakteristik, dass sie rasch zunehmen und ihr Wert sich im Laufe der Zeit verändert. Vor diesem Hintergrund bestehen beträchtliche Herausforderungen für das effektive Informations- und Speicher-Ressourcenmanagement. Vor allem E-Mails, aber auch Office-Dokumente und Anwendungsdaten erfordern immer größere Speicherkapazitäten. Gleichzeitig sollen die Unternehmen die Leistungsfähigkeit ihrer IT steigern und flexibel auf Marktveränderungen eingehen. Unternehmen sind deshalb gezwungen, eine flexible und ganzheitliche Betrachtung von ITInfrastruktur und der Verwaltung ihrer Daten zu entwickeln. Dies gilt insbesondere, da ILM selbst kein fertiges Produkt ist, sondern eine Infrastrukturlösung, die aus mehreren Komponenten besteht. Die BITKOM formulierte 2004 hierzu: „ILM ist kein Produkt, sondern eine Kombination aus Prozessen und Technologien. Ziel ist es, die richtige Information zur richtigen Zeit am richtigen Ort bei geringsten Kosten zu haben. Dies wird in einem permanenten Optimierungsprozess erreicht. Der Optimierungsprozess erhält seine Parameter zum einen durch externe Vorgaben (Wert der Informationen, Sicherheitsanforderungen, Service Level Agreements etc.) und zum anderen durch die vorhandene Speicherhierarchie mit den darunter liegenden Kostenstrukturen. Als Ergebnis des Optimierungsprozesses ergeben sich Entscheidungen, wo Informationsobjekte am besten zu speichern sind bzw. wie Backup-, Replikations-,

42

2 Information Lifecycle Management (ILM-) Modelle

Verdrängungs-, Verlagerungs- und Archivierungsfunktionen zu steuern sind. Für ein effizient arbeitendes ILM sind gewisse Vorleistungen erforderlich. Virtualisierung für den Online-, Nearline- und NAS-Bereich sind Beispiele. Aufgrund der Trennung der logischen Sicht von der physikalischen Sicht wird ILM in die Lage versetzt, Informationsobjekte aufgrund der Prozessentscheidungen optimal zu platzieren.“ 17 Ein ILM-Konzept ohne Einbeziehung der Bedürfnisse der Unternehmenssteuerung und der Geschäftsprozesse ist nicht vollständig. Die Umsetzung von ILMKonzepten in Unternehmen wird meist erst in der Zukunft erfolgen. Die meisten Unternehmen müssen im Vorfeld der ILM-Projekte erst die Voraussetzungen für die Umsetzung eines Information Lifecycle Management schaffen. Voraussetzung für die Einführung jedes ILM-Konzeptes ist eine offene IT-Struktur mit einer hohen Datengranularität. Entscheidungsträger erkennen zunehmend die erheblichen Einsparmöglichkeiten und strategischen Vorteile, die unternehmensweit zentralisierte IT-Leistungen und eine standardisierte IT-Infrastruktur mit sich bringen. Dieser Ansatz macht die vorhandene technologische Expertise unternehmensweit nutzbar, erlaubt weit reichende und kostengünstige Verträge mit Softwareanbietern und erleichtert globale Geschäftsprozesse. Gleichzeitig können Standardisierungen aber die Beweglichkeit einzelner Geschäftsbereiche beschneiden und die Fähigkeit des Unternehmens beschränken,flexibel auf unterschiedliche Kundensegmente einzugehen. Und sie können den Widerstand der Geschäftsbereichsleiter herausfordern. Ein einheitliches Bild des Kunden zu bekommen, macht eine einheitliche Technologiebasis notwendig, die eine elektronische Kommunikation zwischen den einzelnen Regional- oder Geschäftsbereichen erlaubt. Managementteams in jedem Unternehmen, ob zentralisiert oder dezentralisiert, müssen bei der Verteilung von IT-Ressourcen und -Fähigkeiten kontinuierlich die Balance zwischen Gesamtunternehmen und einzelner Geschäftseinheit finden. Die Technik der Informationsverarbeitung und -speicherung hat sich in den letzten Jahren stark verändert. Die Frage der richtigen Architektur war dabei eine der zentralen Fragen. Ein EDV-System, das nicht den Anforderungen entspricht und nicht sicher funktioniert, ist für den betrieblichen Alltag nutzlos. Das bedeutet nicht, dass jedes IT-System den höchsten technischen Standards entsprechen muss. Es ist Aufgabe des Topmanagements zu entscheiden, wie viel Geld es für welche Funktionen und Services ausgeben will. Einige Unternehmen kommen an absoluter Spitzentechnik nicht vorbei. Die Trader einer Bank diskutieren gar nicht erst darüber, wie viele Daten bei einem Systemabsturz verloren gehen dürfen; eine 100-prozentige Datensicherung ist für sie eine existenzielle Notwendigkeit. Die meisten Firmen können jedoch mit gewissen Ausfallzeiten oder gelegentlichen Geschwindigkeitseinbußen leben. Sie müssen den daraus resultierenden Problemen die Kosten für deren komplette Vermeidung gegenüberstellen. 17

www.bitcom.org.

2.2 Zusammenspiel zwischen Geschäftsprozess, Information Lifecycle und Data Lifecycle

43

Abb. 2.1. Die Beantwortung strategischer Fragestellungen unterliegt Veränderungen

Entscheidungen über die notwendige Leistungsfähigkeit der IT-Services müssen von hochrangigen Managern getroffen werden. Üblicherweise sind die Kosten für die höhere Leistungsfähigkeit in die Gesamtpreise der IT-Systeme eingerechnet und werden nicht extra ausgewiesen oder getrennt diskutiert. Die IT-Experten sollten den Führungskräften deshalb mit einer Auswahl von Leistungen und Preisen erläutern, wofür wie viel Geld ausgegeben wird. Die Führungskräfte müssen dann in Absprache mit den IT-Fachleuten entscheiden, welches der richtige Leistungsumfang ist und zu welchem Preis dieser beschafft wird. Eine solche Analyse kann Auswirkungen nicht nur auf einmalige IT-Investitionen, sondern auch auf die jährlichen Betriebskosten haben. Gerade die sind in Unternehmen häufig ein umstrittenes Thema. In vielen Fällen können die Fixkosten während der Systementwicklung durch niedrigere Vorgaben für Systemstabilität und Geschwindigkeit erheblich reduziert werden. Umgekehrt kann die Analyse auch zeigen, dass ein Unternehmen die Risiken von Ausfallzeiten unterschätzt hat und nicht ausreichend dagegen geschützt ist. Wie bei Zuverlässigkeit und Schnelligkeit gilt auch beim Thema Sicherheit, dass Unternehmen das gewünschte Ausmaß an Schutz mit ihren Vorstellungen über die Höhe der Investition abstimmen müssen. Höhere Sicherheit bedeutet nicht nur höhere Kosten, sondern auch eine geringere Nutzerfreundlichkeit. Dieses Abwägen ist die Aufgabe von Führungskräften. Erfolgreiche IT-Neuerungen brauchen manchmal auch die starke Unterstützung derer, die die Technik nutzen und von ihr profitieren sollen. Solange Manager keine Verantwortung für den Er-

44

2 Information Lifecycle Management (ILM-) Modelle

folg – und das Scheitern – von IT-Systemen übernehmen, werden diese Systeme vielleicht technisch elegant sein, sie werden aber keine realen Auswirkungen auf das Geschäft haben. Das IT-Management kann eine Unternehmensführung überfordern. Es ist daher für viele Manager verlockend, diese Aufgabe einfach an einen Dritten abzugeben. Tatsächlich gab es eine Zeit, in der Outsourcing Managern als einfaches Mittel gegen die Frustrationen erschien und viele Unternehmen begannen, sämtliche IT-Funktionen von externen großen IT-Dienstleistern erfüllen zu lassen. Dies senkte die Kosten, und das Unternehmen ging Schwierigkeiten aus dem Weg, die eine eigene IT-Abteilung hätte mit sich bringen können. Aber das Outsourcing führte oft zu Unzufriedenheit im Unternehmen, besonders wenn die unternehmerischen Bedürfnisse sich veränderten. Der IT-Service der Dienstleister mit ihren standardisierten Angeboten und detaillierten Verträgen ist meist nicht darauf angelegt,auf veränderte Anforderungen einzugehen.Auch auf Probleme scheinen die Serviceanbieter oft nur sehr langsam zu reagieren. Wenn z.B. bei der Verhandlung des Supports für die unternehmenskritischen Mainframes keine klar definierten Reaktionszeiten und maximale Ausfallzeiten definiert werden, dann kommt zwar der Anwender ins Schwitzen, nicht aber der Servicepartner, wie die Autoren erst in jüngster Vergangenheit feststellen mussten. Darüber hinaus erfordert die Zusammenarbeit mit einem Zulieferer erhebliche Zeit- und Geldinvestitionen, wodurch dieser fest in die strategischen Planungen und betrieblichen Abläufe eingebunden werden muss. Das Unternehmen wird besonders dann verwundbar, wenn der Dienstleister seine vertraglichen Zusagen nicht einhalten kann. Weitere Probleme entstehen – nicht weiter verwunderlich – weil Führungskräfte mit dem Outsourcing der IT-Funktionen auch die Verantwortung für wichtige Entscheidungen auslagerten, die sie eigentlich selbst treffen müssen. Bei vier der sechs wichtigsten IT-Entscheidungen steht damit die Information entweder als Produktionsfaktor oder als Produkt im Mittelpunkt. Da ILM selbst kein fertiges Produkt, sondern eine Infrastrukturlösung aus mehreren einzelnen Komponenten darstellt, ist zwingend vor der Einführung jedes ILM-Konzeptes die Durchführung einer strategischen IT-Infrastrukturplanung eine grundlegende Voraussetzung. Die Entscheidungsträger definieren im Rahmen der strategischen Infrastrukturplanung entscheidend die Wettbewerbsfähigkeit ihres Unternehmens.

2.3

Die Ziele der strategischen IT-Planung

Strategische Planung ist mehr als die intensive Lektüre einschlägiger Fachzeitschriften. Strategische Planung ist der informationsverarbeitende Prozess im Unternehmen zur Abstimmung von Anforderungen der Umwelt mit den Potenzialen des eigenen Unternehmens in der Absicht, durch Strategien den langfristigen Erfolg abzusichern. Es gibt wohl kaum ein Feld in der Betriebswirtschaftslehre und in der Informatik, auf dem Theorie und Praxis so Hand in Hand arbeiten wie

2.3 Die Ziele der strategischen IT-Planung

45

Abb. 2.2. Die Herausforderungen für den CIO bei der Strukturplanung

bei der strategischen Planung. Denn diese Aufgabe verlangt dem Manager sowohl fundierte analytische Fähigkeiten als auch tatkräftiges Unternehmertum ab. Die Tätigkeiten eines Unternehmens konzentrieren sich heute mehr und mehr auf das Beschaffen, Verarbeiten und Speichern von Informationen. Diese sind, neben den eigentlichen Kernkompetenzen, zum wichtigsten Standbein avanciert. Damit geht eine enorme Anhäufung von Daten einher, da sich alles schlicht und einfach in den Tiefen irgendwelcher Speicherplatten aufbewahren lässt. Das stellt Unternehmen vor die Herausforderung, in zukunftsgeeignete IT-Infrastrukturen zu investieren, die gleichzeitig signifikante Wettbewerbsvorteile schaffen. Der namhafte Experte Michael E. Porter formuliert zum Thema Wettbewerb: „Competitive advantage grows out of the value a firm is able to create for its buyers that exceeds the firm’s cost of creating it. Value is what buyers are willing to pay, and superior value stems from offering lower prices than competitors for equivalent benefits or providing unique benefits that more than offset a higher price. There are two basic types of competitive advantage: cost leadership and differentiation.“ 18

18

Porter, Michael E.: Competitive Advantages: Creating and Sustaining Superior Performance, NY, 1985, S 3.

46

2 Information Lifecycle Management (ILM-) Modelle

Ein zentraler Punkt jeder Strategie sind die Kosten. Die IT-Kosten besitzen eine spezifische Dynamik: „Each dollar spent on systems development generates, on average, a follow-on annual cost of 40 cents for maintenance of the system and 20 cents for operations. Only about 10 % of an Information Services group’s staff resources are available for developing new systems. Half or more are tied up in maintaining existing ones.“ 19 Die meisten Unternehmen kennen leider ihre IT-Kosten und ihre Kosteneinsparungspotenziale nicht, da diese nicht vollständig durch die betrieblichen Rechnungswesensysteme erfasst werden. „Accounting systems rarely track the real costs of IT, most of which are hidden. A useful rule of thumb is that the visible price of any IT investment is only 20–25 % of the full cost.“ 20 Ein wesentlicher Kostentreiber im Betrieb von IT-Infrastruktur ist die Heterogenität der Hardware mit einer Vielzahl unterschiedlicher Versionsstände und Prozessoren. Der Markt für IT-Plattformen ist deshalb in den letzten Jahren in Bewegung gekommen. Neben Windows und mehreren Linux-Varianten stehen Novell Open Enterprise Server als Netware-Nachfolger, Sun Solaris, IBM AIX oder HP-UX zur Wahl. Jedes dieser Angebote hat dabei das eine oder andere Feature, das jedoch bei der Auswahl nur eine singuläre Rolle spielen darf. Bei der Entscheidung für eine IT-Plattform sind die Antworten auf folgende Fragen von elementarer Bedeutung: • • • • •

Erzielt eine Open-Source-Plattform einen langfristigen Kostenvorteil? Welche Plattform bietet die sicherste Computerumgebung? Ist eine Interoperabilität gegeben? Welche Alternativen bieten sich bei der Umstellung oder Migration? Steht eine IT-Infrastruktur-Management-Umgebung zur Verfügung?

Insbesondere das zentrale Management der verteilten IT-Infrastruktur ist eine Anforderung im Hinblick auf einen sicheren und wirtschaftlichen Betrieb. An eine Lösung, die für die Überwachung auf Betriebssystem- und Applikationsebene eingesetzt wird, muss die folgende Anforderung gestellt werden: • Zentralisierte Lösung, d.h., von einer Konsole können sämtliche Systeme überwacht werden. • Zentrales Einsammeln der Event-Logs der Server und möglichst auch der Speichersysteme. • Regelbasierte Interpretation der Einträge, da sonst die Vielzahl der Events die Administratoren überfordert. Eine gute Basis für die Steigerung der Effizienz ihrer IT legen Firmen, wenn sie im ersten Schritt ihre Infrastruktur – von den Servern über die Speichersysteme bis 19 20

Blecher, Michael, Gartner Group: Component based Development: The next wave, 4/1999. Blecher, Michael, a.a.O.

2.3 Die Ziele der strategischen IT-Planung

47

Abb. 2.3. Kosteneinsparungspotenziale

hin zum Netzwerk – standardisieren und konsolidieren. Laut McKinsey lassen sich bereits durch die Standardisierung und Konsolidierung von Hardware und Diensten mindestens 20 Prozent der Kosten für den Betrieb und die Administration der IT-Umgebung einsparen. Konsolidierte und standardisierte Infrastrukturen erleichtern nicht nur die Virtualisierung. Unternehmen profitieren auch von einer einfacheren Administration. Anstatt mit zahlreichen unterschiedlichen SoftwareTools die Insellösungen zu verwalten, können sie nun die gesamte IT unter einer Oberfläche administrieren. Das so genannte Unified Infrastructure Management führt dabei nicht nur die Verwaltung lediglich der Server oder nur der Speicherlösungen zusammen, sondern vereint beide in einer umfassenden Ansicht. Offene Schnittstellen erlauben darüber hinaus die Anbindung der Hardwareverwaltung an weiter reichende Managementlösungen. Die Konsolidierung und Standardisierung ihrer Infrastrukturen eröffnet vielen Betrieben einen bislang nicht erreichbaren Grad an Virtualisierung und somit den leistungsfähigeren Betrieb ihrer IT. Generell geht der Blick der IT-Verantwortlichen weg von der isolierten Betrachtung der Infrastruktur hin zu einem Management der gesamten IT-gestützten Unternehmensabläufe. Die Konsolidierung der IT-Infrastruktur sowie die Virtualisierung der Dienste sind Projekte, die bereits heute umgesetzt werden können und gleichzeitig bei intelligenter Herangehensweise die Basis für eine Einführung eines effizienten und leistungsfähigen ILM-Konzeptes schaffen können. Das Zusammenführen von heterogenen Systemen und so genannten Insellösungen zu einer einheitlichen und

48

2 Information Lifecycle Management (ILM-) Modelle

Abb. 2.4. Kosteneinsparungspotenzial einzelner Maßnahmen21

vereinfachten Infrastruktur senkt jedoch nicht nur die Kosten, sondern sorgt zudem auch für eine höhere Ausfallsicherheit und senkt damit zusätzlich die Kosten des Betriebes. Der Einsatz von Komponenten, die auf Industriestandards basieren, gewährleistet darüber hinaus eine umfassende Skalierbarkeit. Ein weiterer Vorteil ist eine einheitliche und einfachere Verwaltung der gesamten Infrastruktur. Vor der Einführung eines ILM-Modells sollten daher alle wirtschaftlich sinnvollen Konsolidierungspotenziale ausgeschöpft werden.Konsolidierung inVerbindung mit Standardisierung dürfte die Schlüsseltechnologie sein, um sowohl eine sinnvolle, zusammenhängende Speicherhierarchie zu schaffen als auch die Anzahl der Speicherklassen in einem operativ handhabbaren Umfang zu halten. Praxisbeispiele für effektive Konsolidierungen sind unter Anderem im E-Mail-Bereich bekannt. In dezentralisierten ILM-Modellen ist der Aufwand für die Kommunikation und die Administration um ein Vielfaches höher. So lassen sich mit entsprechenden Produkten mehrere hundert E-Mail-Server auf wenige Server konzentrieren. Der Anschluss einer Verdrängungs- bzw. Archivierungsebene ist bei wenigen Servern wesentlich einfacher zu realisieren als bei einigen hundert möglicherweise weit verteilten Servern. Die Virtualisierung ist im Unix-Bereich eine schon seit Jahren bewährte Technologie, wie z.B. in IBM AIX. Connectrix brachte 1997 eine erste Version der Software Virtual PC für Apple Macintosh auf den Markt. Ein Highlight des Produk22

EMC2 , a.a.O.

2.3 Die Ziele der strategischen IT-Planung

49

Abb. 2.5. Einsparungspotenzial durch Konsolidierung22

tes war die Unterstützung von OS/2 als dem Basisbetriebssystem. VMware hat in 1999 mit VMware das erste Produkt auf den Markt gebracht, das auf Intel-WirtSystemen den Betrieb einer virtuellen Umgebung erlaubte. Aktuell wird häufig zwischen drei Ebenen der Virtualisierung unterschieden: • der Element-Virtualisierung, • der integrierten Virtualisierung und • der vollständigen Virtualisierung der IT (Complete IT-Utility). Dabei gilt die Faustregel: Je höher der Grad der Virtualisierung ist, desto mehr geschäftliche Vorteile ergeben sich für das Unternehmen. Das Element der Virtualisierung bezieht sich auf einzelne Komponenten wie Server oder Speichersysteme oder auf Gruppen gleicher Geräte. Mit Lösungen für eine integrierte Virtualisierung gehen Virtualisierungskonzepte über die reine Geräteebene hinaus und sind auf die Optimierung von ganzen IT-Infrastrukturen für Anwendungsumgebungen und Geschäftsprozesse abgestimmt. Die integrierte Virtualisierung befähigt zum Beispiel Unternehmen, Service Level Agreements (SLA) automatisch einzuhalten. Anbieter von Virtualisierungslösungen arbeiten bereits an der vollständigen IT-Virtualisierung (Complete IT-Utility). Im Rechenzentrum der nächsten Generation stehen dadurch alle heterogenen Ressourcen in Echtzeit zur Verfügung. Eine solche Infrastruktur zeichnet sich durch einen hohen 22

EMC; Marketing-Unterlage.

50

2 Information Lifecycle Management (ILM-) Modelle

Abb. 2.6. Virtualisierungsmodell

Servicegrad und maximale Flexibilität aus. Ressourcen werden als Service bezogen und je nach Verbrauch bezahlt. Aktuell müssen die meisten Unternehmen im Vorfeld der ILM-Projekte erst noch die Voraussetzungen für die Umsetzung eines Information Lifecycle Management schaffen.

2.4

Entwicklungstrends Speichernetzwerke

Als sich vor einigen Jahren die Unzufriedenheit der Anwender von Fileservern hauptsächlich in Bezug auf Stabilität, Verfügbarkeit und Skalierbarkeit häufte, kamen die ersten Ansätze von dedizierten Fileservern unter dem Namen „Network Attached Storage“ (NAS) auf den Markt. Zunächst wurden nur im Marktsegment für das NFS-Protokoll die entsprechenden Systeme entwickelt, die sich allein um die Kernaufgabe des Fileservice kümmern sollten. Alle zusätzlichen Dienste oder gar Anwendungen wurden von dieser Plattform verbannt, um insbesondere dem Ziel der Stabilität näher zu kommen, als dies mit den bis dato bekannten Systemen möglich war. Der damit entstandene Appliance-Gedanke, der bereits im Bereich der Netzwerkinfrastruktur mit dedizierten Routern erfolgreich umgesetzt worden war, wurde damit konsequent auch für den Fileservice weiter gedacht. Auch vor dem Hintergrund der späteren Kundenwünsche und der weiteren technischen Entwicklung ist dieser Urgedanke mehr oder weniger in den heutigen Produkten

2.4 Entwicklungstrends Speichernetzwerke

51

wieder zu finden. Dabei kann heute im Wesentlichen die Trennlinie bei folgenden Merkmalen gezogen werden: „All-in-One“-Lösungen: Hier werden sämtliche Funktionalitäten über eine einzige zentrale Komponente im Netz zugänglich gemacht. Sämtliche Anforderungen sind dabei über die gemeinsame Hard- und Software abzudecken. Integration von Fileservices und blockorientierten Zugriff mit Bearbeitung der verschiedenen Protokolle bis herunter zur Speicherverwaltung und Überwachung des Gesamtsystems müssen in solchen Lösungen abgedeckt werden. „Distributed“-Lösungen: In diesem Konzept wird die Fileserver-Funktionalität vom Speicher getrennt. Der NAS wird hier, genau wie andere offene Hosts (Unix, Linux,Windows etc.), an ein intelligentes Speichersubsystem angeschlossen. Funktional wird damit File- und Blockzugriff auf unterschiedliche Systeme verteilt, die damit auch für diese speziellen Aufgaben optimiert werden können. Beide Ansätze unterscheiden sich meist auch in der Art, in der Hochverfügbarkeit erreicht werden kann. Hier gibt es zum einen das Clusterverfahren, bei dem sich die Systemkomponenten untereinander über den jeweiligen Status austauschen müssen, oder den Einsatz von Standby-Komponenten, die den Ausfall von Hardware kompensieren können.Als wesentliches Eckdatum beim Einsatz von Clustern ist die Anzahl der Knoten zu nennen, die ein Cluster bilden können. Bei maximal zwei Knoten zeigt sich recht schnell die eingeschränkte Skalierbarkeit des Gesamtsystems. Notwendige Erweiterungen können dann nur mit weiteren Systemen, die als separat zu administrierende Einheiten eingebunden werden müssen, realisiert werden. Insbesondere dann, wenn auch räumliche Trennung erforderlich ist, geht das nur zu Lasten des lokalen Schutzes der Lösung.Ein Ausfall eines Clusterknotens hat immer eine Reduktion der Performance des Gesamtsystems zur Folge (gilt nur für einen Aktiv-Aktiv-Cluster. Die verbleibenden Knoten müssen die Aufgabe des ausgefallenen Knotens übernehmen). Das Standby-Verfahren kann aufgrund des n:1-Verfahrens auch eine größere Anzahl von NAS-Knoten absichern. Durch die Bildung von Failovergruppen kann flexibel auf die jeweils abzudeckenden SLA reagiert werden. Nach einem Failover steht diesem Verfahren aufgrund identischer Hardware die gleiche Leistungsfähigkeit des Gesamtsystems zur Verfügung wie vor dem Failover. Bei der Entscheidung für eines der vorgenannten Verfahren wird dann meist auch über das mögliche Administrationskonzept entschieden. Bei den Clustersystemen wird meist jeder Knoten separat administriert, oder aber es müssen bestimmte clusterrelevante Konfigurationen an allen beteiligten Knoten wiederholt werden. Nicht so beim Einsatz von Standby-Verfahren. Nach dem Stand der heutigen Technik werden hier mehrere Knoten in einem System zusammengefasst, die dann auch als eine Einheit zentral administriert werden können.Die Überwachung erfolgt dazu meist von einer dedizierten Einheit in der NAS-Lösung, die aus Hochverfügbarkeitsgründen selbstverständlich auch redundant ausgelegt werden kann. Neben dem zentralen Management kann von hier auch ein automatischer Service-

52

2 Information Lifecycle Management (ILM-) Modelle

ruf an den Hersteller erfolgen, womit der Austausch defekter Komponenten ohne aktive Unterstützung durch des Kunden veranlasst werden kann. Das Storage Area Network (SAN) basiert auf der Direktanbindung (Point-toPoint) zwischen Server und Speicher nach dem „Direct-Attached-Modell“, wobei ein separates Netzwerk aus Speicher-„Devices“ erstellt wird. Beim Netzwerk kann es sich um ein Fibre Channel (FC-) oder Gigabit-Ethernet-Netzwerk (iSCSI, FCIP, iFCP) handeln. Ein SAN kann Festplatten und Bandspeichergeräte umfassen und vielen Servern zur Verfügung gestellt werden. Sie übertragen Daten, ohne dass sich dies auf die Auslastung des Kommunikationsnetzwerks auswirkt,denn die zur Verfügung stehende Bandbreite wird von den einzelnen Komponenten nicht geteilt (d.h. geshared), sondern ist dediziert zugeordnet. Ein SAN ist damit für Netzwerkbenutzer transparent. Typische SAN-Anwendungen sind OLTP, Data Warehousing und ERP. Den Datenzugriff im SAN bezeichnet man als blockorientiert. Content Addressed Storage (CAS) basiert auf dem IP-Protokoll. Kern des CASKonzeptes ist die Arbeit auf Basis von Objekten mit festem Inhalt und nicht mit Datenblöcken oder Dateien. Die speziellen Anforderungen an CAS-Speicher liegen im Bereich der Langlebigkeit der Daten und der Sicherstellung deren Integrität. Storage Area Network (SAN-) Technologien bieten Vorteile für geschäftliche und technische Anwendungen, deren Transaktionen eine optimale Performance erfordern sowie eine große Anzahl von Usern und große Datenbanken integrieren. In einem SAN kann der Speicher auf einfache Weise mit höherer Übertragungsrate und Flexibilität gespiegelt werden. Fibre Channel (FC-) SAN decken große Entfernungen ab und ermöglichen die Adressierung von Millionen von Devices. Dadurch werden die Verwaltbarkeit und die Flexibilität der Geschäftsumgebung durch ein zentrales Management von hunderten Devices verbessert. Im Rahmen der Konsolidierung gewinnen Management und Sicherheit an Bedeutung. Auf SAN-Basis erstellte Software bietet Verbesserungen, die das Management von Datenmengen im Terabyte-Bereich ermöglichen. SAN-Infrastrukturen bieten flexibelste Speichermöglichkeiten, weit reichende Interoperabilität und umfassende Datenmigrations- und Verfügbarkeitsoptionen. Ein SAN bietet zusätzlich Volume-Replikationsmöglichkeiten, die insbesondere die Backup- und Disaster Recovery (DR-) Lösungen vereinfachen. Durch Konsolidierung, verbesserte Anwendungsperformance und gesteigerte Skalierbarkeit optimieren SAN-Lösungen die Gesamtkosten (TCO). Unnötiges Duplizieren und Synchronisieren von Datenbeständen wird vermieden. Durch eine SAN-Lösung wird ein Lastausgleich für Server- und Speichersysteme und eine optimale Performance mit besseren Reaktionszeiten für die Anwendungen erreicht. Intelligente Speichernetzwerke, wie Storage Area Networks (SAN), Network Attached Storage (NAS) und IP-Storage, erleichtern die operative Umsetzung der dynamischen ILM-Entscheidungen erheblich.In intelligenten Speichernetzwerken hat im Prinzip jeder Server auf jeden Speicherbereich Zugriff. Dies schafft z. B. die Voraussetzung, um bei einer Erstzuweisung die bestgeeignete Speicherklasse auszuwählen. ILM ist zuerst einmal konzeptionell unabhängig von der Frage, ob die ITKonfiguration in einem dezentralisierten oder zentralisierten Modell betrieben

2.4 Entwicklungstrends Speichernetzwerke

53

Abb. 2.7. Virtualisierung über die gesamte Infrastruktur

wird, solange Kommunikationspfade zu den dezentralen Standorten bestehen. Im dezentralisierten ILM-Modell ist aber der Aufwand für Kommunikation und Administration um ein Vielfaches höher. Vor der Einführung eines ILM müssen deshalb zuerst alle Konsolidierungspotenziale ausgeschöpft werden. Konsolidierung in Verbindung mit Virtualisierung dürfte die Schlüsseltechnologie sein, um zu einer unter wirtschaftlichen Gesichtspunkten vernünftigen, zusammenhängenden Speicherhierarchie zu gelangen und zum anderen die Anzahl der Speicherklassen in einem operativ handhabbaren Umfang zu halten.So lassen sich mit entsprechenden Produkten mehrere hundert E-Mail-Server auf wenige Server konzentrieren. Der Anschluss an die Speicherhierarchien nach einer Verdrängungs- bzw. Archivierungsebene ist bei wenigen Servern wesentlich einfacher zu realisieren als bei einer Vielzahl von meist auch räumlich weit verteilten Servern. Ein effektives ILM setzt einen einfachen und sicheren Zugriff auf Ressourcen voraus. Bei der Entscheidung, auf welchen Technologien Informationsobjekte abgelegt werden, sollten technische Attribute eine möglichst geringe Rolle spielen. Dies wird heute über Virtualisierung erreicht. Bei den Speichervirtualisierungslösungen ist zwischen Virtualisierung im Online-, Nearline- und NAS-Bereich zu unterscheiden. Der Online-Bereich unterscheidet zwischen Lösungen aus dem Server-, Netzwerk- und Speicherbereich. Bei den netzwerkbasierten Lösungen haben sich im Wesentlichen die In-Band-Lösungen etabliert. Diese Lösungen basieren auf Ap-

54

2 Information Lifecycle Management (ILM-) Modelle

pliances, die zwischen Server und Speichersystem platziert werden. In-Band-Lösungen fassen auch heterogene Speichersysteme zu einem Pool zusammen und präsentieren Teilbereiche als „Virtuelle Logical Unit Number (LUN)“. In vielen Unternehmen sind die Ergebnisse der Bemühungen zur Verbesserung der Effizienz entmutigend. Nicht einmal jede zehnte Firma verzeichnet eine Erfolgsquote von 90 Prozent23 . 39 Prozent der befragten 400 Prozessverantwortlichen in Mittelstands- und Großunternehmen gaben an, dass sie ihre Projektziele zur Prozessgestaltung nur zur Hälfte bis drei Viertel erreichen. Bei 28 Prozent der Firmen fallen die Ergebnisse noch schlechter aus. Als wesentliche Schwierigkeiten bei den Projekten nennen etwa zwei Drittel lange Realisierungszeiten und begrenzte personelle Ressourcen. In der Praxis erweisen sich zudem Akzeptanzschwierigkeiten seitens der Mitarbeiter als typische Hürden auf dem Weg zum Projekterfolg.Sie sind bei 62 Prozent die zentralen Gründe für die beschriebenen unbefriedigenden Ergebnisse. Eine mögliche Schlussfolgerung ist der Verzicht auf eine sehr stark IT-lastige Prozessgestaltung wie sie in ILM erforderlich ist. Eine zweite und sehr viel stärker auf Basis der betrieblichen Realität liegende Interpretation der Ergebnisse ist in der Schwäche heutiger Lösungen zu suchen. Die Hauptschwäche heutiger Lösungen liegt in der mangelnden Integrierbarkeit verschiedener Software. Ein Ziel muss es daher sein, den traditionellen und IT-lastigen Gedanken von Business Process Management (BPM) im Rahmen eines ILM-Konzeptes zu überwinden. Die Prozessunterstützung muss sich dabei insbesondere auf die End-to-End-Prozesse beziehen.

2.5

Strategische Einführungskonzepte für ILM

ILM ist kein Projekt, das eine schlampige Vorbereitung verträgt! Ein Beispiel für ein solch missratenes Projekt war die LKW-Maut. Toll Collect, ein Zusammenschluss aus Deutscher Telekom, DaimlerChrysler und dem französischen Autobahnbetreiber Cofiroute, wollte ein wirklich „innovatives System“ entwickeln. „Einfach, benutzerfreundlich, flexibel und weltweit einsetzbar“. Einfach? Flexibel? Innovativ? Die Realität sah sehr lange gründlich anders aus. Bei Toll Collect regierte monatelang das Chaos. Der Projektfortschritt hatte insbesondere lange unter dem Mangel zu leiden, dass keine klare Vorstellung über die Größe des Datenvolumens und deren Speicherung entwickelt wurde. Erst die Übernahme der Verantwortung durch das Management der Telekom und die Auswechselung des Managements bei Toll Collect brachte das Projekt letztlich auf die Erfolgsspur zurück. Komplexe Systeme erschweren die Verwaltung und Wartung der IT. Derzeit verwenden Unternehmen rund 70 Prozent ihrer IT-Budgets für die Pflege ihrer bestehenden IT-Infrastruktur. Das belegt eine Studie der Meta Group. Bis zum Jahr

23

Egip Software AG, www.egip.com.

2.5 Strategische Einführungskonzepte für ILM

55

Abb. 2.8. Der Storage Router in der Lösungsarchitektur

2006 soll dieser Anteil auf 80 Prozent steigen.24 Dadurch stehen immer weniger Mittel für Investitionen in neue Technologien zur Verfügung.Andererseits werden meist nur 20 bis 35 Prozent der verfügbaren Rechen- und Speicherkapazitäten tatsächlich genutzt. Kurze Time-to-Market-Zyklen,Fusionen,Übernahmen sowie Kostenreduktion erfordern in den Unternehmen eine neue Denkweise. Dabei spielt die Informationstechnologie (IT) eine zentrale Rolle. Nur mit IT-Strategien, die flexible und dennoch stabile Geschäftsprozesse erlauben, halten Unternehmen mit den Marktentwicklungen Schritt. Denn leistungsfähige IT ist in den vergangenen Jahren zum wichtigen, oftmals gar entscheidenden Wettbewerbsfaktor geworden.Von OnlineBanking über Logistikmanagement bis zur Just-in-time-Fertigung – kaum eine Innovation in der Unternehmensführung funktioniert ohne die Unterstützung durch moderne Hard- und Software. Neue Geschäftsprozesse wie die Verknüpfung der eigenen Warenwirtschaftssysteme mit denen von Zulieferer oder Kunden lassen sich mit Altsystemen – wenn überhaupt – nur mit großem Zeitaufwand einführen. Insbesondere die Einführung von ILM muss natürlich den beschriebenen Umstand berücksichtigen und darauf aufsetzen. Unverzichtbar ist dabei die Erarbeitung eines Einführungsmodells. Nachdem im Rahmen der strategischen IT-Infrastrukturplanung die Voraussetzungen für die Einführung von ILM geschaffen wurden, muss nun im Rahmen 24

Metagroup, a.a.O.

56

2 Information Lifecycle Management (ILM-) Modelle

der strategischen Einführungskonzepte noch die Schrittfolge festgelegt werden. Die SNIA-Organisation hat hierzu eine Roadmap definiert mit dem Ziel, die Einführung von ILM entlang eines logischen Weges zu lenken,der die„Best Practices“Erfahrungen der aktuellen Lösungen berücksichtigt. Die Roadmap hat das Ziel, eine sichere Basis herzustellen, und endet bei einem vollautomatisierten, multistandortbasierten Enterprise ILM. Hierzu wird die SNIA-Roadmap in 5 Phasen geteilt, von denen jede einen charakteristischen Schritt beschreibt.

2.5.1

Phase 1

Aus Sicht von SNIA, die die Autoren aufgrund ihrer einschlägigen Erfahrungen teilen, braucht ILM eine fundierte Basis. Die SNIA empfiehlt, zuerst die Speicherung und die Datendienstleistungen in einer SAN- oder NAS-Umgebung zu konsolidieren. Durch Reduktion der Vielfalt und die Standardisierung der Konfigurationen wird eine funktionale Architektur vorbereitet, auf der ILM-Dienstleistungen aufbauen können.

2.5.2

Phase 2

Das Ziel von Phase 2 ist es, die Speicherung und die Datendienstleistungen zu standardisieren, so dass es zu konsistenten, wiederholbaren und rationellen Prozessen kommt. Es fängt mit einer Datenklassifizierung an. Dabei wird gemäß den Anforderungen von existierenden und geplanten Datenzugriffen analysiert und dokumentiert. Die Daten sollen u.a. den Wert jener Auskunft für das jeweilige Geschäft dokumentieren. Dieser Wert kann in einem weiteren Schritt dazu genutzt werden, zu bestimmen, welchen wirtschaftlichen Schaden die Nichtverfügbarkeit von Daten oder gar der Anwendung für den Geschäftsprozess und das Unternehmen hat. Es kann fremde Werte wie Risiko und den mit dem Verlust der Daten verbundenen Imageschaden einschließen. Der Wert der Daten führt dann zur Definition von Dienstleistungszielen (SLOs), deren Nivellierung, Verfügbarkeit, Betriebsrückgewinnung, Katastrophenrückgewinnung, Sicherheit und mehr. Indem die Anwendungen und Daten mit standardisierten Konfigurationen verbunden und die gewünschten SLOs erreicht wurden, kann eine Bewertung zwischen der Dienstleistung und dem für die Erbringung der Dienstleistung notwendigen Aufwand ermittelt werden, der Kosten-Leistungs-Angemessenheitskoeffizient.

2.5.3

Phase 3

Diese Phase führt den Begriff von „Stacks“ ein. Ein Lösungsstack beschreibt eine Gruppe von gleichartigen Daten und Dienstleistungen, die Instrumente geworden sind, die zusammen in Verbindung mit ILM den Support von Anwendungen und ihre wertvolle Auskunft sichern. Ein Lösungsstack ist eine vollständige (oder beinahe vollständige) ILM-Umgebung für eine dezidierte Anwendung. So basiert im Stack ein SLO für einen Anwendungsfall auf der Beschreibung der ersten aktiven Speicherung, der Wiederherstellung und dem Katastrophenfallschutz sowie dem

2.6 Strategische ILM-Prozessmodelle

57

Archivierungsaufbewahrungsort. Dies ist der erste Schritt für ein automatisiertes ILM.

2.5.4

Phase 4

Für die ILM-Automation wird die Einführung einer neuen Klasse von Managementwerkzeugen benötigt. ILM wird hier zuerst in Form einer homogenen Insel betrieben. Industrieerfahrung zeigt, dass es weit leichter ist, zuerst ein Instrument einer einzelnen Applikation zuzuordnen. Dabei wird eine schrittweise Durchführung korrespondierend mit der Lösung der Fragen im Hinblick auf die benötigten Daten und Auskünfte plus dem Aufbau des Netzes, der Services und der Speicherinfrastruktur erreicht werden können. Insbesondere der Abgleich mit den benötigten Serviceniveaus ist aus wirtschaftlicher Sicht ein zwingendes Vorgehen. Der Nachweis der Nützlichkeit der Datenverarbeitung, Netzdienstleistungen und Informationsservices-Dienstleistungen in Verbindung mit einem nivellierten Management von Industriegruppen wie DMTF, OASE, IETF, GGF, EGA, ITSMF, ITIL und mehr schaffen für die Unternehmen echten Mehrwert.

2.5.5

Phase 5

In Phase 5 wird erstmalig die Interoperabilität erreicht. Interoperabilität bedeutet, dass Produkte ihre Möglichkeiten definieren und die Instrumente bereitstellen für die angebotenen Servicedienstleistungen. Dabei kann ein Service auch durch andere ersetzt werden, so dass Servicedienstleistungen auf sehr unterschiedlichen Wegen erbracht werden können. Interoperabilität ist die friedliche Koexistenz zwischen den Services und kein Wettbewerb um Ressourcen, so dass z.B. die Datenverwaltung die Erzeugung von informationsbasierten Produktservices nicht stört. Interbetriebsfähigkeit ist das Ergebnis einer Beschreibung und Ausgestaltung, die Schnittstellen so zu definieren, dass es zu keinem konkurrierenden Zugriff auf Informationen kommt. Für ILM bedeutet dies, die Fähigkeit zu entwickeln, das bestehende Komplexitätsproblem bei der Datenzentralisierung bei gleichzeitiger substanzieller TCO-Reduzierung zu lösen,indem auf Geschäftsanforderungen und auf einem durch SLA definierten Niveau geplant und gearbeitet wird. ILM ist damit das perfekte Instrument für die Automatisierung der zentralen Informationsverwaltung und -speicherung.

2.6

Strategische ILM-Prozessmodelle

Zwar ist ILM kein fertiges Produkt, sondern eine Kombination von Prozessen, trotzdem muss das Ziel der Prozesse zumindest in Umrissen definiert werden. Auch hier hat sich noch kein klarer Standard etabliert.

58

2 Information Lifecycle Management (ILM-) Modelle

2.6.1

ILM als Prozessmodell

Eine Möglichkeit zur besseren Abstimmung von IT und Unternehmensgeschäft liefert das „Strategic-Business-IT Alignment Model“ (SAM). Dieses Modell bestimmt das Zusammenspiel zwischen Geschäftsstrategie, -strukturen und -prozessen sowie der IT-Strategie und der Ausgestaltung im Detail innerhalb von zwei Dimensionen: einerseits innerhalb der „funktionalen Integration“ und andererseits im Rahmen des „strategischen Fits“. Das SAM-Modell verdeutlicht, dass alle Größen einander eng bedingen und Änderungen in den einzelnen Bereichen auch die anderen Abteilungen beeinflussen. Die Information Technology Infrastructure Library (ITIL-) Methode setzt auf dem SAM-Modell auf. In einem Kreislauf aus Konzeption, Realisierung und permanentem Check-up wird die Ausrichtung der IT am Unternehmensgeschäft überprüft und notfalls korrigiert. ITIL liefert eine umfassende Sammlung von Standards in den Bereichen Aufgaben, Prozesse sowie Kennzahlen der IT insgesamt und zeigt deren Anwendung anhand von praktischen Beispielen. Gerade die Ausrichtung der IT am Unternehmenszweck und der Geschäftsentwicklung ist ein zentraler Aspekt dieser Methode. Das Besondere ist die freie Verfügbarkeit und der freie Zugang zu diesem Werkzeug. Analog zum Kreisprozess der Ausrichtung erfolgt die Behandlung der Information. ILM besteht im Kern aus dem Dokumenten Management System (DMS) und aus dem so genannten Enterprise Content Management (ECM). ECM umfasst gemäß der Definition des Branchenverbandes AIIM die Technologien zu Erfassung, Verwaltung, Speicherung, Bewahrung und Bereitstellung von Dokumenten und Content zur Unterstützung von organisatorischen Prozessen.25 ECM schließt dabei sowohl Produkte als auch Lösungen und Strategien ein und umfasst Technologien wie Business Process Management (BPM), Collaboration, Dokumentenmanagement,Input- und Output-Management,Record Management, Storage und elektronische Archivierung sowie Web Content Management (WCM) und Workflow.

2.6.2

ILM als Modell mit dem Fokus Adaptive Enterprise

Damit Unternehmen möglichst großen wirtschaftlichen Nutzen aus den IT-Investitionen ziehen und einen schnellen Return-on-IT (RoIT) erzielen, sollten sie aber auf innovative Technologien setzen. Diese sorgen dafür, dass Ressourcen flexibel dort bereitstehen, wo sie tatsächlich benötigt werden – und zwar in dem Umfang, der für die aktuelle Aufgabe notwendig ist. So verfügt das Unternehmen über eine IT-Infrastruktur, die sich den Geschäftsprozessen anpasst, eine so genannte adaptive Infrastruktur. Bei konsequenter Umsetzung wandelt sich das Unternehmen zum „Adaptive Enterprise“, das in Echtzeit auf Marktbedingungen reagiert. Erreicht wird dies durch die Technologie des Utility Computing. Es handelt sich hierbei um ein verbrauchsorientiertes Modell. Die Anwender erhalten die Rechen- und Speicherleistung, die sie tatsächlich benötigen, aus einem großen zentralen Pool. Auf diese Weise werden die vorhandenen Systeme optimal ausge25

AIIM, The Enterprise Content Management Association, www.aiim.org.

2.6 Strategische ILM-Prozessmodelle

59

Abb. 2.9. ILM als Prozessmodell Enterprise Content Management (ECM)

lastet. Grundvoraussetzung für dieses Modell ist ein intelligentes, automatisiertes Management der IT. Es gewährleistet, dass für Geschäftsprozesse immer die richtigen IT-Services zur Verfügung stehen. Eine ideale IT-Infrastruktur, die sämtliche Kapazitäten in einem großen virtuellen Pool vorhält, der zentral verwaltet wird und je nach Bedarf verteilt, • • • • •

ist einfach, ist modular, integriert heterogene IT-Landschaften, nutzt standardisierte Prozesse und berücksichtigt die spezifischen ILM-Anforderungen.

Bei der Auswahl neuer Systeme wird berücksichtigt, dass sie leicht zu beschaffen, zu betreiben und zu warten sind. Modulare Bausteine erlauben Änderungen einzelner Geschäftsprozesse, ohne dass die gesamte IT beeinflusst wird, und erhöhen dadurch die Reaktionsgeschwindigkeit. Die Integration schafft eine einheitliche Systemwelt, die künstliche Barrieren zwischen den Systemen abbaut und so Kapazitäten unternehmensweit nutzbar macht.Standards lassen sich für Arbeitsabläufe, Technologien und Anwendungen festlegen.Das erleichtert unter anderem auch das Management der IT. Die enge Vernetzung von Geschäftsprozessen mit ILM und der IT muss auf einer Architektur basieren, die aus einer Lösung für die Ressourcen-Virtualisierung und einer Plattform für das Systemmanagement besteht. Eine wichtige Komponente dabei ist die Systemmanagementsoftware. Ausgereifte Systemmanagementsoftware wie beispielsweise Microsoft MOM oder HP OpenView ist modular auf-

60

2 Information Lifecycle Management (ILM-) Modelle

gebaut. Sie kombiniert vorhandene Elemente zum erforderlichen Service, der sich nach dem Bedarf der entsprechenden Abteilung richtet. Außerdem überwacht sie die Performance und plant den weiteren Bedarf. Diese adaptive Managementplattform vereint die verfügbaren Ressourcen im Rechenzentrum. So lassen sie sich effizienter nutzen und verwalten. Mit der Hilfe einer ausgefeilten IT-Strategie,die auf einer flexiblen Managementplattform aufsetzt, können Unternehmen dann ihre Investitionen gemäß den Geschäftszielen ausrichten und gleichzeitig den Nutzen ihrer IT für das Geschäft messen.

2.7

Schlüsselfaktor Klassifizierungskonzepte

Das Management von unstrukturierten Daten ist aktuell eines der größeren unaufgeklärten Probleme der Speichertechnologien.Noch sind vermutlich ca.80 Prozent der gespeicherten Daten unstrukturiert und entziehen sich so einem ökonomischen ILM-Prozess. Die zentrale Herausforderung der prozesskonformen Bereitstellung besteht jedoch für strukturierte und unstrukturierte Daten. Zwar wurde das ILM-Konzept von den Speicherherstellern entwickelt, die Malaise der fehlenden Strukturierung hat zur Konsequenz, dass aktuell noch die Hauptprotagonisten die Beratungshäuser sind.„Es dauert Stunden über Stunden, um im Assessments eine Datenklassifizierung herauszufinden und festzustellen, wo es bei den ILM-Projekten letztendlich hingeht“.26 So bieten inzwischen viele Hersteller vorgelagerte Beratung an, ehe ILM implementiert wird.„Wir erarbeiten mit dem Kunden einen Soll-Ist-Vergleich und bewerten diese Daten kundenspezifisch nach einem bestimmten Schema“, so ein Business Development Manager für ILM-Systeme von Sun Microsystems.27 Auch StorageTek bestätigt, dass man sich „mit den Unternehmensberatern verbrüdern“ muss: „Wenn ein Storage-Anbieter wie wir, der für seine Hardware bekannt ist, sagt, wir machen Geschäftsprozessanalysen, dann ist das sicherlich etwas unglaubwürdig.“28 Alle aktuellen Lösungskonzepte für die Datenklassifizierung basieren auf: • „tiered“ Storage Es bezeichnet ein mehrstufiges Speichernetzwerk. Jede Ebene bildet spezifische Serviceziele ab, so dass Daten entsprechend ihren Anforderungengespeichert werden können. • Virtualisierung Es trennt die logische von der physikalischen Sicht auf die Infrastruktur.So können die Daten im Hintergrund verschoben werden,ohne den Zugriff der Anwendungen zu beeinträchtigen. Auf der Basis der vorgestellten ILM-Modelle erfolgt die notwendige Klassifizierung der Daten. Die Klassifizierung ist dabei ein zentraler Eckstein für den Erfolg des 26 27 28

Netapp; Pressemitteilung, www.netapp.com. SUN, Pressemitteilung, www.sun.com. StorageTek, Pressemitteilung, www.storagetek.com.

2.7 Schlüsselfaktor Klassifizierungskonzepte

61

ILM-Modells. Eine allgemeine Klassifizierung von Daten wird üblicherweise in Form einer Einordnung in eine drei- bis fünfstufige Gruppe bzw. Skala vollzogen. Dabei kann z.B. in Abhängigkeit der Branche unterschieden werden zwischen: • Critical Data: Daten, die für die wichtigen Geschäftsprozesse benötigt werden und deren Verlust zu einer operativen Katastrophe führen kann (die Unternehmensleistung kann nicht mehr erbracht werden), sowie Daten, die aus rechtlichen Gründen aufbewahrt werden müssen. • Business Performance Data: Daten, die für die Steuerung und die Planung eines Unternehmens relevant sind und deren Verlust zu einer unternehmerischen Katastrophe führen kann. • Essential Data: Daten, die für das Tagesgeschäft verwendet werden und damit Teil des Business-Know-hows eines Unternehmens sind. • Sensible Data: Daten,die für das Tagesgeschäft verwendet werden,die jedoch entweder schnell wiederhergestellt oder durch alternative Daten ersetzt werden können. • Non-Critical Data: Daten, die mit geringen Kosten wiederhergestellt werden können oder aber Duplikate bestehender Daten. Die Kernaufgabe besteht darin die Geschäftsprozess-Anforderungen auf die verschiedenen Speicherklassen im Rahmen eines „Tiered“-Speichermodells umzurechnen. Ziel ist, • den Speicher, dem „Business“ entsprechend (Demand), mit niedrigen Kosten und hoher Qualität (Zeit, Funktion) bereitzustellen, sowie • die Trennung der Schichten Anforderung und Lieferung. Der Prozess der Klassifizierung assoziiert Dateien mit Metadaten und/oder Inhalten wie zum Beispiel Kategoriethema, Nutzername, Entstehungsdatum, Änderungsdatum, Inhalt und andere Kriterien. Somit kann ein Mitarbeiter nach verschiedenen Parametern suchen, um die Informationen zurückzuholen oder sie entsprechend ihrem Wert zu verwalten. Eine Klassifizierung identifiziert auch Gemeinsamkeiten in Dokumenten, was ungewollten Redundanzen vorbeugt. Das Clustering gruppiert Dateien nach Wortähnlichkeiten oder miteinander verbundenen Informationen.In einer Taxonomie sind die Informationen in logische Hierarchien strukturiert, die die Daten in spezifische Klassen einteilen. Das jeweilige Unternehmen bestimmt diese Hierarchien nach seinen eigenen Anforderungen, beispielsweise einer Einteilung nach Abteilungen oder nach Applikationen.

62

2 Information Lifecycle Management (ILM-) Modelle

2.8

Schlüsselfaktor IT-Sicherheit

Nicht zuletzt zeigt die Analyse der IT-Sicherheitsvorfälle erschreckende Ergebnisse. 50 Prozent der Top-10-Datendiebstähle in Bezug auf Datenmanagement betreffen Backup-Medien. Die durchschnittliche Anzahl der Datensätze beträgt dabei über 430.000 und liegt damit fast 200 Prozent über den anderen Medien. Innerhalb des letzten Jahres waren über 50. Mio. Datensätze betroffen.29 Die heute noch vorherrschende geringe Wertschätzung der eigenen Daten dokumentieren die beschriebenen Beispiele. Auch in Deutschland wird der Wert der Information häufig verkannt. Auch hier soll ein Beispiel aus dem Bereich Banken dies verdeutlichen. Eine Bank erstellt wöchentlich ein Backup, ohne dieses auch regelmäßig auf seine Eignung zu überprüfen. Die Sicherung wird regelmäßig von einer Sicherheitsfirma abgeholt und in deren Aufbewahrungsräumen deponiert. Wer den aktuell stark ramponierten Ruf dieser Branche im Hinterkopf hat, der wundert sich, dass das Backup weder verschlüsselt wird, noch werden Vorkehrungen getroffen, zumindest das unbemerkte Lesen und Kopieren der Daten zu verhindern oder durch Versiegelung erkennbar zu machen. Auch beim Rücklauf der Bände nach Ablauf der Aufbewahrungsfrist findet keine Kontrolle statt, ob die Bänder im Extremfall sogar von Dritten manipuliert wurden oder gar überhaupt nutzbar wären. In einem Unternehmensnetzwerk übernimmt den Schutz vor einem Eindringling von außen eine Firewall und das „Eindringling-Warnsystem“ ist die Aufgabe des Intrusion Detection Systems (IDS). Ist dies heute der Stand in vielen Unternehmen, Behörden und anderen Organisationen im Zusammenhang mit der Netzwerk- und Datensicherheit? Eine Firewall gegen Einbruch ist vielleicht installiert,jedoch häufig wegen unzureichender Administration und Überprüfung meist löchrig wie der bekannte Schweizer Käse. Die Sicherheitssoftware Firewall kann das Problem eines Datenmissbrauchs oder Datendiebstahls nicht wirklich lösen; sie zeigt nur, wie schwach und verletzbar Computersysteme und -netze sind. Auch ein gut geschütztes Netz ist Angriffen ausgesetzt. Angriffe von innen, entweder durch infizierte PCs oder Notebooks oder gar böswillige Mitarbeiter, laufen zudem nicht über die Firewall und können von ihr demzufolge auch nicht verhindert werden. Ein Intrusion Detection System (IDS) hat hier die Aufgabe, die Administratoren bei der Erkennung von Angriffen zu unterstützen. Ein solches IDS ist in den wenigsten Fällen vorhanden. Die Daten liegen meist ungeschützt auf den Servern und Arbeitsplatzrechnern der Mitarbeiter. Hierdurch gefährdet ein Unternehmen nicht nur potenziell die Sicherheit seiner digitalen Daten, welche in unserer zunehmend digitalisierten Welt für jedes Unternehmen zum wichtigsten und wertvollsten Gut geworden sind, sondern es verstößt hierdurch häufig auch potenziell gegen gesetzliche Auflagen bezüglich des Datenschutzes. Optimaler Schutz und ständige Verfügbarkeit entscheiden oftmals über den Fortbestand des Unternehmens. Diese Tatsache spiegelt sich mittlerweile in den immer komplexer werdenden gesetzlichen Anforderungen gegenüber den Betrieben wider, die für den Schutz ihrer Daten Sicherheitskonzepte entwickeln und 29

Messeausgabe DMS - Köln 2006.

2.8 Schlüsselfaktor IT-Sicherheit

63

umsetzen müssen. Hackerangriffe auf Speichersysteme können teuer werden – und die Behebung des Schadens kostet zudem viel Zeit.Vermeiden kann man solche Probleme, wenn man Speicher im Netzwerk vernünftig sichert. Dabei stellen nicht nur Einbrüche von außen ein Risiko dar. Gefahr für Ihre Daten entstehen sowohl durch Missbrauch von außerhalb als auch von innerhalb des Unternehmens. Studien belegen, dass die meisten Unternehmen autorisierte, nichtautorisierte und ehemalige Mitarbeiter als Hauptverdächtige für das Begehen von Informationsverbrechen betrachten. Insbesondere mit den Veränderungen bei den Speichermedien und deren Vernetzung hat die Frage nach der IT-Sicherheit eine neue Facette erhalten. Der Trend zu immer sichereren Netzen ist das Ergebnis einer Reihe von gesetzlichen und regulativen Verordnungen. So stammt beispielsweise die Richtlinie Basel II aus der Finanzwelt und betrifft bei der Kreditbeschaffung nahezu alle Unternehmen. Diese müssen nämlich zur Erzielung eines guten Ratings und für die Erlangung günstigerer Kredite gegenüber den Banken nachweisen,dass sie unter anderem ein funktionierendes operatives Risikomanagement besitzen. Dazu gehört neben der schnellen Wiederherstellung der IT im Katastrophenfall auch die Robustheit gegen Sicherheitsverletzungen von innen und außen sowie die Sicherung und Sicherheit von Unternehmensdaten. Entsprechend hoch ist für Unternehmen die Bedeutung der Speichersicherheit einzuschätzen. Sicherheit im SAN- und NAS-Umfeld mit dezentraler Datenhaltung und offenem Zugriff unterscheidet sich nicht grundsätzlich von den Sicherheitstechnologien in anderen Netzen. Jahrzehntelange Erfahrungen aus dem LAN- und WAN-Bereich konnten hier einfließen, und so setzt die Speicherindustrie zunehmend auf die gleichen Sicherheitsprotokolle wie IP Layer Security (IPsec), Secure Sockets Layer (SSL), Transport Layer Security (TLS), Secure Shell (SSH) und Public Key Infrastructure (PKI). Ergänzt werden diese Standards noch durch das Fibre-Channel-spezifische Security Protokoll (FC-SP), welches vom ANSI/T11.3Standardisierungsgremium im Juni 2004 verabschiedet wurde. In dem Maße, wie Unternehmen die Datenspeicher vernetzen, nimmt die Notwendigkeit deutlich weiter zu, Speichermedien, Speichernetze und Backups gegen Missbrauch zu schützen. Moderne SAN- und NAS-Speichernetze sowohl auf Basis von Fibre Channel (FC) und iSCSI verfügen lediglich über unvollständige Sicherheitsmechanismen und entsprechen nur selten der unternehmensweiten IT-Security-Policy. In FC-SANs werden Verfahren wie das Zoning und Logical Unit Number (LUN-) Masking eingesetzt, um funktionale und sicherheitsrelevante Anforderungen zu erfüllen. Für iSCSI-SANs kommt das bekannte IPsec zur Anwendung. Es beinhaltet unter anderem die Authentifizierung der Originalverbindungen und die Verschlüsselung von Daten während der Übertragung. Aus Sicht des amerikanischen Instituts der Wirtschaftsprüfer (AICPA) reicht es nicht aus, eine sichere Speicherarchitektur sozusagen „alone“ zu entwerfen.„Die Mehrheit von Sicherheitsvorfällen hat innerbetriebliche Gründe.30“ Laut Munroe (Chief Operating Officer Interliant) nützen IT-Sicherheitsarchitekturen nicht viel, 30

CISA, www.isaca.org/cisa.

64

2 Information Lifecycle Management (ILM-) Modelle

wenn ein Kennwortproblem existiert oder wenn das Personal nicht trainiert wurde, Verfahrensfestlegungen zu folgen. Seine Empfehlung lautet: „Führe routinemäßige Sicherstellungen von deinem Betriebssystem, Programmen, Anwendungen und allen Dateien durch. Ohne Datensicherung erholen sich die meisten Geschäfte niemals völlig von Datumsverlust.Vergewissere dich dessen, dass das Personal fähig ist, performante Sicherungen durchzuführen.31“ ISO 17799 fordert, für jedes der identifizierten Risiken eine Risikobehandlungsentscheidung zu treffen. Die Wahlmöglichkeiten schließen ein: • Angemessene Kontrollen anzuwenden, um die Risiken zu reduzieren • Wissentliche und objektive Risiken zu akzeptieren • Risiken zu vermeiden, keine Aktionen zu erlauben, die die Risiken verursachen würden • Die sich verbindenden Risiken auf andere Parteien zu übertragen, z.B. Versicherer oder Lieferanten Speichersicherheit könnte man definieren als ein Sammelsurium an Sicherheitsschlössern und Einstellungen, die verhindern sollen, dass unautorisierte Benutzer zu den Ressourcen vordringen und im Gegenzug berechtigte User über gesicherte Kommunikationskanäle Zugriff auf die gespeicherten Daten haben. Im Grunde fallen die gleichen Begriffe wie im klassischen IT-Sicherheitssektor. Die Eckpfeiler der Speicher-IT-Sicherheit sind: • • • • • • •

Authentifizierung Autorisierung (Zugriffskontrolle) Accounting/Auditing Reporting über das Nutzerverhalten Datenintegrität (Compliance, Einhaltung von Regeln) Vertraulichkeit Verschlüsselung

Die Authentifizierung prüft, ob es sich um einen bekannten und zugelassenen Administrator oder Anwender handelt. Hier greifen Technologien wie Passwortschutz, Zertifikate oder biometrische Überprüfungen. Autorisierung geht noch einen Schritt weiter. Neben der Überprüfung der gültigen Berechtigung werden auf Objektebene verschiedene Rechte vergeben. So darf etwa ein Administrator die Zonen des Switches umkonfigurieren, während ein anderer nur bestimmte Performance-Reports drucken kann. Accounting und Auditing zeichnen alle Managementaktivitäten historisch auf und werten sie aus.Dies dient vor allem dem lückenlosen Nachweis aller Zugriffe auf die Speicherkomponenten im SAN und ist in vielen Industriezweigen heute zu einer wichtigen Sicherheits- und ComplianceAnforderung geworden. Reporting stellt die aufgezeichneten Aktivitäten gemäß den jeweiligen spezifischen Anforderungen zusammen und macht sie für die ITSicherheitsadministratoren erst lesbar. Datenintegrität bedeutet den Nachweis, dass Daten unverfälscht übertragen und abgespeichert werden. Dies hat relativ 31

AICPA, www.aicpa.org.

2.9 Schlüsselfaktor Qualitätssicherung

65

wenig mit dem stets identischen CRC-Prüfverfahren auf Netzebene zu tun, welches lediglich die fehlerfreie Datenkommunikation sicherstellt. Hier dagegen wird die Sicherheit mittels eines sicheren Hash-Algorithmus wie MD5 nach dem Austausch von privaten und öffentlichen Sicherheitsschlüsseln gewährleistet.Vertraulichkeit wird durch diverse Verschlüsselungsverfahren wie DES, Triple-DES, AES oder Blowfish garantiert. Nur Sender und Empfänger, die im Besitz der Privateund Public-Keys sind, können die übertragenen Daten entschlüsseln und verstehen. Neben der Sicherheit der Informationsübertragung stellt sich zunehmend die Forderung, spezifische Information generell nur verschlüsselt zu speichern und insbesondere nur verschlüsselt im Backup-Modus zu behandeln. Von den weltweit ca. 10 TB Backup werden bereits 10 Prozent, d.h. ca. 1 TB Daten verschlüsselt gesichert.32 Trotz der Gemeinsamkeit mit den klassischen IT-Sicherheitsansätzen, gibt es doch Unterschiede in der grundsätzlichen Philosophie. Sicherheit war und ist immer geprägt von Abschottung. Speicher hat als zentrales Ziel die Erfüllung der Grundanforderungder Verfügbarkeit der Daten für alle Nutzer. Die neuen Gesetze, allen voran die Compliance-Regeln, zwingen die Unternehmen auf der einen Seite, ihre Daten über viele Jahre unverändert aufzubewahren, auf der anderen Seite fordern gesetzliche Bestimmungen, dass auch ältere Daten mit der aktuellen IT lesbar sind. Ist dieses nicht gewährleistet, so drohen auch hier Strafen.Wie eng das Verhältnis werden kann, haben Veritas und Symantec durch ihre Fusion gezeigt.

2.9

Schlüsselfaktor Qualitätssicherung

Wir, die beiden Autoren, haben in einem gemeinsamen Projekt innerhalb von 2,5 Jahren in Summe 92 ältere Speichersysteme durch 9 neue Speichersysteme desselben Herstellers ersetzt und zusammen mehr als 250 TB (Netto-) Daten migriert. Jede ungeplante Produktionsunterbrechung hätte pro Tag eine Konventionalstrafe von mehreren Millionen Euro bedeutet und jeder Datenverlust („Data loss“) leicht einen Schaden in Höhe eines zweistelligen Millionen Euro Betrages verursacht. Trotz verschiedener Online-Mikro-Code-Upgrades, Plattenausfällen während schwieriger Operationen und der üblichen projektimmanenten Stressfaktoren wurde das Projekt ohne jede ungeplante Produktionsunterbrechung und ohne jeden Datenverlust durchgeführt. Wir haben dies erreicht, weil jede noch so kleine Aktion vor deren Durchführung schriftlich in Form einzelner Schritte geplant, detailliert dokumentiert und von den entsprechenden Systemexperten verifiziert worden war. Es gab keine spontanen Aktivitäten.Während der Laufzeit des Projektes gab es gleichwohl am obigen RZ-Standort mehrere ungeplante Produktionsunterbrechungen,deren Auswirkungen immer dann besonders groß war,wenn die jeweils betroffenen Mitarbeiter nicht auf detaillierte Beschreibungen zurückgreifen konnten, sondern spontan improvisieren mussten, so unsere Beobachtungen. Das gesamte Migrationsprojekt war, da es ohne eine ungeplante Produktionsunterbre32

Messeausgabe DMS-Köln 2006, a.a.O.

66

2 Information Lifecycle Management (ILM-) Modelle

chung und ohne jeden Datenverlust durchgeführt wurde, sowohl aus technischer als auch aus wirtschaftlicher Sicht ein Gewinn für den Auftraggeber. Das Qualitätsmanagement (QM) im Rahmen der Qualitätssicherung (QS) übernimmt die Aufgabe der Optimierung von Arbeitsabläufen im Rahmen der Geschäftsprozesse unter der Berücksichtigung von materiellen und zeitlichen Kontingenten bei der Erbringung der Dienstleistungen. Hierbei sind von Belang etwa die Optimierung von Kommunikationsstrukturen, professionelle Lösungsstrategien sowie die Motivation der Belegschaft. Im Vordergrund des Qualitätsmanagements stehen die Standardisierungen bestimmter Handlungs- und Arbeitsprozesse, Normen für Produkte oder Leistungen, Dokumentationen, Ausstattung und Gestaltung von Arbeitsräumen. Qualitätsmanagement beschreibt somit einen systematischen Weg, um sicherzustellen, dass alle Aktivitäten den Anforderungen entsprechen und wie geplant stattfinden. Das Bewusstsein für Qualitätssicherung, für Risikomanagement und, wie bereits beschrieben, für IT-Sicherheit ist leider meist nicht sehr stark im Bereich der IT entwickelt. Aber durch das immer stärkere Gewicht der IT innerhalb der unternehmenskritischen Geschäftsprozesse und der möglichen Haftungsrisiken trotz der Einhaltung von Normen wächst das Risiko, dass auch Fehler in der Leistungserbringung des Ist-Service erhebliche wirtschaftliche Auswirkungen haben. Ein wichtiger Punkt insbesondere innerhalb jedes ILM-Konzeptes ist deshalb die kontinuierliche Qualitätssicherung (QS) in Verbindung mit einem entsprechenden Qualitäts- und Risikomanagement.

2.10

Schlüsselfaktor Risikomanagement

Als traurige Beispiele für IT-Projekte,die aus dem Ruder liefen,sorgten Toll Collect oder das Internetportal der Bundesagentur für Arbeit für unrühmliche Schlagzeilen. Das sind aber keine Einzelfälle. Eine Studie der Standish Group belegt, dass lediglich 28 Prozent der IT-Projekte im vorgegebenen Kosten- und Zeitrahmen beendet werden.33 Dadurch können schnell Schäden in Millionenhöhe entstehen. Um dem entgegenzuwirken, beschäftigt sich das IT-Risikomanagement mit der Steuerung und Überwachung solcher Bedrohungen. Ein Innovationsprojekt wie ILM bewegt sich in einem Spannungsfeld zwischen Gefahren und Chancen. Gefahren gefährden den Projekterfolg, Chancen ermöglichen ihn. Zur Erreichung der notwendigen Qualität müssen Abweichungen von den festgelegten oder vorausgesetzten Erfordernissen vermieden werden. Fehlervermeidung in einem ILMProjekt erfolgt durch das Management des Fehlerrisikos. Die Nichterfüllung der Anforderungen ist ein Fehler und damit eine Gefahr für den Projekterfolg. Zur Erreichung des Projekterfolgs müssen daher die Risiken berücksichtigt und behandelt werden, d.h. ein Risikomanagement ist notwendig. Qualitätssicherung und Risikomanagement sind eng verbunden. Damit ist das Risikomanagement ein Teil des Qualitätsmanagements. Gleichzeitig ist die Qualitätssicherung aber auch 33

Standish Group, www.standishgroup.com.

2.11 ILM-Projektmanagement:Anforderungen an die Projektorganisation und -Struktur

67

eine Methode der Risikominderung. Qualitätssicherung in Verbindung mit dem Risikomanagement ist ein Schlüsselfaktor in jedem ILM-Konzept. Obwohl die Aufgabe des Risikomanagements und die damit verbundene Risikostrategiebildung im Problembewusstsein deutscher IT-Führungskräfte fest verankert sind, wird die Absicherung von Wirtschaftlichkeits- und Effizienzzielen durch das Risikomanagement in der Praxis stark vernachlässigt. Eine Studie von Krecmar brachte zutage, dass die Bewältigung von Projektrisiken und strategischen Bedrohungen eher selten zum Aufgabenbereich des IT-Risikomanagements gezählt werden. Die Studie stellte unter Beweis, dass es deutliche Verbesserungspotenziale im Bereich der Risikoberichterstattung gibt.Besonderer Handlungsbedarf besteht laut der Studie von Krecmar bei der ökonomischen Bewertung von Risiken und der damit verbundenen Möglichkeit, Chancen und Risiken sinnvoll gegeneinander abzuwägen. In einem wertorientierten Unternehmensmodell muss sich die Aufgabe des IT-Risikomanagements daher von einem reinen Sicherheitsmanagement hin zu einer betriebswirtschaftlichen Gestaltungs- und Optimierungsfunktion entwickeln. Die Innovation ILM muss als Investition ohne Erfolgsgarantie angesehen werden, die gleichermaßen Chancen wie Risiken beinhaltet. Zum spezifischen Innovationsrisiko, d.h. die Innovation leistet keinen Beitrag zum betrieblichen Erfolg, treten bei ILM-Projekten die allgemeinen Projektrisiken, die aufgrund des innovativen Projektcharakters erhöht sind durch: • • • •

Kostenrisiken, Ressourcenrisiko, Zeitrisiko und technisches Risiko.

Das Risikomanagement eines innovativen ILM-Projektes muss im Gegensatz zum allgemeinen Risikomanagement nicht nur die bekannten Risiken behandeln, sondern zusätzlich die unbekannten und neuartigen Risiken identifizieren und handhaben. Im Wesentlichen besteht das Ziel darin die Flexibilität zu erhalten, Handlungsmöglichkeiten zu eröffnen und Transparenz im Sinne eines Frühwarnsystems zu schaffen.

2.11

ILM-Projektmanagement: Anforderungen an die Projektorganisation und -Struktur

Wie im Buch „Grundlagen und Modelle Information Lifecycle Management“ beschrieben, muss bei sechs Entscheidungen das Management selbst die Führungsverantwortung übernehmen, wenn es ein IT-Desaster vermeiden und – noch wichtiger – echten Nutzen aus ihren IT-Investitionen ziehen will. Keine dieser Entscheidungen sollte alleine von IT-Experten getroffen werden – denn das ist nicht ihr Job. Die zentrale Frage lautet, besteht ein „Fit“ zwischen der Unternehmensstrategie, der hieraus abgeleiteten IT-Servicestrategie und ILM sowie der Frage, ist die eigene Unternehmens-IT „fit“ für ein ILM-Projekt. Ein ILM-Projekt ist ein Lösungs-

68

2 Information Lifecycle Management (ILM-) Modelle

ansatz, dem eine sachlich und zeitlich begrenzte Aufgabe zugewiesen wird, die durch das Zusammenwirken unterschiedlicher Funktionsbereiche gelöst werden soll. Hieraus wird deutlich, dass es sich bei Projekten um Aufgabenstellungen von besonderer Größe und Komplexität handelt. Die Terminierung von Anfang (Projektfreigabe) und Ende (Projektabnahme) ergibt sich vielfach aus der Auslösung eines Projektes. Der zeitliche Rahmen eines ILM-Projektes kann sich von der Projektidentifizierung über die Projektfreigabe bis zur Projektabnahme über mehrere Jahre erstrecken. Sie setzt mit der Freigabe des Projektes ein. Sie sollten nach dem Studium der beschriebenen Anforderungen und Risiken nicht zu der Erkenntnis gelangen, dass ILM für ihr Unternehmen zu anspruchsvoll oder zu komplex ist,da ihnen sowohl die Know-how-Basis in der Unternehmens-IT als nicht ausreichend erscheint als auch die Risiken zu hoch. Für uns ist es wichtig, dass Sie die Erkenntnis aus der Lektüre der beiden Kapitel mitnehmen, dass ILM weder eine Laisser-faire-Vorbereitungnoch eine Nonchalance-Durchführung erlaubt.

3 Information Lifecycle Management – Projektorganisation und -struktur

Aufsetzend auf den langjährigen Erfahrungen bei der erfolgreichen Durchführung einschlägiger, größerer Projekte in den Branchen Banken, Energieversorger, Handel und Telekommunikation in Zusammenarbeit mit den führenden Anbietern von SAN-, NAS- und Speicherlösungen einschließlich deren Management beschreiben wir die Einführung eines geschäftsorientierten Informations-Managements und des Information Lifecycle Management. Aus rechtlichen Gründen und um auch kritische Sachverhalte objektiv darstellen zu können, erfolgt die Beschreibung auf Basis eines fiktiven Unternehmens. Dieser Teil des Buches erläutert das Vorgehen, die Planung, die Realisierung und die Projektkontrolle des Projektes KONCOM/IT durch die WeDo-IT – ITProjektmanagement anhand der neutralisierten und anonymisierten Daten dreier tatsächlich durchgeführten Projekte. Hierzu beschreiben und begründen wir zunächst den Projekt- und Projektmanagement-Ansatz zur Implementierung von Informationsmanagement und Information Lifecycle Management.Wir zeigen auf, dass die Komplexität der Aufgabe zwingend eine Herauslösung des Themas aus dem Tagesgeschäft erfordert und zudem einer spezifischen Projektorganisation bedarf.

3.1

Projektkurzbeschreibung

Die„EurAmFi AG“34 ist ein international tätiger Energieversorger mit Hauptsitz in Deutschland und mehreren Tochtergesellschaften im europäischen Ausland sowie zwei Tochtergesellschaften in den Vereinigten Staaten von Amerika. Das Hauptgeschäft der EurAmFi AG ist der Handel mit Primärenergien, also Strom, Gas und (Heiz-) Öl für deren Transport sie ein international weit verzweigtes Leitungsnetz betreibt. Hier werden an drei Übergabepunkten Öl und Erdgas aus Russland, dem Brent-Vorkommen in der Nordsee sowie den Lagerstätten im Golf von Mexiko übernommen und an die jeweiligen Kunden weitergeleitet. Die EurAmFi AG ist 34

Das hier beschriebene Projekt ist eine Zusammenführung dreier real durchgeführter ILM-Projekte. Aus Gründen des Kundenschutzes wurden die in diesen Projekten verwendeten Daten anonymisiert. Die fiktive Gesellschaft EurAmFi AG wurde eingeführt, um die Relevanz eines international orientierten Vorgehens schon im Name zu verdeutlichen.

70

3 Information Lifecycle Management – Projektorganisation und -struktur

zusätzlich primärer Stromlieferant für mehr als 5 Millionen Haushalte in Deutschland, Frankreich und den USA. Wie eine Vielzahl von Energieversorgern besitzt die EurAmFi AG eine TK-Tochtergesellschaft (EurATel GmbH), die mehr als 4 Millionen Privat- und Firmenkunden mit Produkten der Festnetz- und Mobiltelefonie sowie mit Internetzugang versorgt. Die EurAmFi AG beabsichtigt, im Rahmen einer anstehenden Speicherkonsolidierung ein Drei-Ebenen-Modell ihrer kompletten Produktions-IT-Speicherinfrastruktur zu implementieren,um den unterschiedlichen Anforderungen an die Datenverarbeitung und Datenhaltung von Informationen über den Verlauf ihres Lebenszyklus gerecht zu werden. Das Projekt „KONCOM/IT – Konsolidierung und Compliance der IT der EurAmFi AG“ soll die 92 existierenden Speichersysteme älterer Bauart auf High-Performance-Systeme mit zugehöriger SAN-, NAS- oder iSCSI-Infrastruktur konsolidieren. Dies erfolgt mit modularen Komponenten, die neu beschafft werden. Außerdem soll sichergestellt werden, dass nach einer Datenklassifizierung der Produktivdaten sämtlicher Anwendungen der EurAmFi AG in drei Klassen (Datenklasse 1 – Hochproduktivdaten, Datenklasse 2 – NearlineDaten und Datenklasse 3 – Archive-Daten) diese Klassen auf unterschiedlichen Speicherplattformen betrieben werden sollen. Daten der Datenklasse 1 sollen auf hochverfügbaren Speichermedien abgelegt werden. Diese sollen zur Sicherstellung der K-Fall Fähigkeit als Komponenten auf beide RZ-Standorte Hauptverwaltung (RZ 1) und Technikzentrum (RZ 2) verteilt werden. Daten der Datenklasse 2 sollen durch ein geeignetes Verfahren lokal abgesichert werden. Ein K-Fall-Szenario ist für diese Daten nicht vorgesehen. Die Daten der Datenklasse 3 sollen auf einem Archivierungssystem unter Einsatz der Archivierungssoftware IXOS abgelegt werden. Im Rahmen eines Vorläuferprojektes von KONCOM/IT wurden ebenfalls die existierenden Serversysteme unterschiedlicher Hersteller (IBM-AIX, SUN-Solaris, FSC-Solaris, FSC-W2K3, FSC-Linux) auf 384 moderne Systeme konsolidiert. Die Migration der Anwendungen und Services dieser Server auf die neuen Serverplattformen soll möglichst ohne Unterbrechung des Betriebes stattfinden. Dieser Refresh der EurAmFi-Umgebung mit sämtlichen Services sowie mit sämtlichen Produktiv-, PreLife-, Test-Instanzen erfordert die Migration auf die HighPerformance-Systeme sowie die Anpassung der datenverarbeitungstechnischen Prozesse in der neuen Umgebung, die von der EurAmFi AG betrieben wird. Bei den Services handelt es sich um die produktiven Kernapplikationen des Handels- und Abrechnungssystems der EurAmFi AG, geliefert von SAP, energieversorgerspezifische Anwendungen, basierend auf GIS-Systemen, sowie die komplette IT-Anwendungslandschaft der EurATel GmbH, inclusive einem zugekauften Rating- und Billing-System sowie einem CRM-System von Siebel. Die folgenden Informationen sind die Anforderungen, die die EurAmFi AG an den externen Dienstleister „WeDo-IT – IT-Projektmanagement“35 gerichtet hat, der im Namen 35

Wie die EurAmFi AG und die EurATel GmbH ist auch das WeDo-IT-Projektmanagement ein fiktives Unternehmen. Tatsächlich haben die beiden Autoren die drei Projekte, die hier zum ebenfalls fiktiven KONCOM/IT zusammengefasst wurden, als Projektleiter im Na-

3.2 Anforderungen an das Projektmanagement

71

und Auftrag der EurAmFi AG das Pflichtenheft und die Projektausschreibung erstellen und die Implementierung von KONCOM/IT durch die ausgewählten Lieferanten planen und steuern wird. Die erste Phase des Projektes stellt die Prozess- und Informations-Ist-Aufnahme dar, auf deren Grundlage ausschließlich die geschäftszentrierten IT-Prozesse definiert werden. Danach wird in Form eines Assessments eine geschäftszentrierte und Policy-basierte Infrastrukturanpassung an den Wert der Informationen durchgeführt. Hier erfolgt die Klassifikation der Daten und Anwendungen nach klassischen Geschäftsregeln sowie die Beschreibung der Implementierung von Policies anhand von Informationsmanagement Tools. Diese dienen ebenfalls dem Management der Speicherinfrastruktur. Außerdem werden wir hier eine Klassifizierung von Speicherressourcen zur Anpassung an Datenklassen zur Repräsentation der Informationswerte vornehmen. Darauf aufbauend werden klassische Anforderungen an die „tiered“ Speicherinfrastruktur (Hardware und Software) abgeleitet, definiert und beschrieben. Hier werden wir einen kurzen Überblick über die in diesem Umfeld aktuell gängige Infrastruktur geben, bevor wir auf dieser Basis, die ILM-Entscheidungsmatrix erstellen. Hier werden sämtliche aus unserer Sicht relevanten Parameter/Anforderungen an IM-/ILM-fähige Hard- und Softwaresysteme beschrieben und mit einer gemäß unseren einschlägigen Erfahrungswerten aussagekräftigen Gewichtung versehen. Für die Projektphase Ausschreibung und Herstellerauswahl zeigen wir, wie die Ausschreibungsunterlagen zu erstellen sind. Ferner enthält dieser Abschnitt ein technisch detailliertes Pflichtenheft, das zur Ausschreibung an die in Frage kommenden Hersteller versandt werden muss. Des Weiteren verfolgen wir in diesem Buch die Projektphase Implementierung der Geschäftsprozesse und „tiered“-Speicherinfrastruktur sowie die Projektphase Migration (Daten- und Servermigration) sowie das kontinuierliche Qualitätsmanagement im Projekt und über das Projekt hinaus.

3.2 3.2.1

Anforderungen an das Projektmanagement Allgemeine Anforderungen an das Projektmanagement

Speichermigrationsprojekte als auch ILM-Projekte insbesondere in Verbindung mit der Optimierung der Geschäftsprozesse sind in der Regel komplex.Die Leitung von Projekten ist deshalb eine Aufgabe geworden, für die der jeweilige Manager ein umfangreiches Portefeuille von Fertigkeiten benötigt. Nur durch ein wirkungsvolles Management können anspruchsvolle Projekte sicher termin-, kosten- und qualitätsgerecht zum Ziel geführt werden. Der Projekterfolg hängt dabei entscheidend vom Projektmanagement ab.

men und Auftrag unterschiedlicher Dienstleistungsunternehmen erbracht, die ebenfalls aus Kundenschutzgründen nicht genannt werden sollen.

72

3 Information Lifecycle Management – Projektorganisation und -struktur

Daher stellt die WeDo-IT während des gesamten KONCOM/IT-Projektes ein professionelles Projektmanagement zur Verfügung. Dabei werden die vorhandenen und dem Projekt zugeteilten Projektmanagement-Teams der EurAmFi AG auch in den späteren Projektphasen die der Lieferanten – in die Projektmanagement-Struktur von KONCOM/IT eingebunden. Für das Projekt KONCOM/IT erstellen die Mitarbeiter der WeDo-IT ein fundiertes Konzept. Die fundierte und realistische Projektplanung ist dabei die Basis für eine funktionierende Projektsteuerung. Sie wird wie eine Landkarte verwendet, die es erlaubt, das Abweichen vom richtigen Weg möglichst frühzeitig festzustellen. Je mehr Zeit der Projektleiter bei der Projektsteuerung darauf verwendet,notwendige Maßnahmen zu treffen und gemeinsam mit seinem Projektteam umzusetzen, desto höher ist die Qualität der einzelnen Steuerungsmaßnahmen. Die WeDo-IT stellt ein auf die Aufgabenstellung KONCOM/IT optimiertes Vorgehen als Dienstleistung zur Verfügung. Dabei nutzt sie ein umfangreiches Fach-Know-how, das von unabhängigen Dritten bereits vielfach zertifiziert wurde. Die Komplexität der Planung und der Steuerung der Durchführung des beschriebenen Projektes erfordert es, aus einem Portfolio von unterschiedlichen Projektmanagementansätzen den für die jeweiligen Anforderungen geeigneten Lösungsbaustein zu nutzen und diese zu einem harmonischen Ganzen zu kombinieren.

3.2.2

Anforderungen an ein V-Modell und V-Modell-XT basiertes Projektmanagement

DasV-Modell und die WeiterentwicklungV-Modell-XT ist eine umfassende Sammlung von Wissen über die „Best Practices“ der Softwareentwicklung. Das Vorgehensmodell ist ein Prozessmodell, mit dessen Hilfe Projekte gemäß der Norm ISO 9001 abgewickelt werden können und ist sowohl im militärischen Bereich als auch für den gesamten Bereich der Bundesverwaltung verbindlich. Es wird von sehr vielen Industriefirmen und auch von der aus staatlichen kommunalen Energieversorgern hervorgegangenen EurAmFi AG als Hausstandard zur Softwareentwicklung verwendet. Im V-Modell wird das Projektmanagement in Form eines Prozesses beschrieben. Dies geschieht durch die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen),die bei der IT-Systemerstellung und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen. Neben den vorgegebenen Aktivitäten und Produkten enthält das V-Modell auch Informationen über den Projektablauf. Im V-Modell wird geregelt, welche Ausgangsprodukte von einer Aktivität erzeugt werden und welche nachfolgenden Aktivitäten diese Produkte als Eingänge benötigen. Das Vorgehensmodell beschreibt so die Aktivitäten (Tätigkeiten) und Produkte (Ergebnisse), die während der Entwicklung von Software durchzuführen bzw. zu erstellen sind. Der Einsatz des V-Modells eröffnet die Chance zum maschinellen Workflow-Management. Aus dem inhaltlichen Produktfluss lässt sich eine zeitliche Abfolge der Aktivitä-

3.2 Anforderungen an das Projektmanagement

73

ten ableiten. Diese Eigenschaft des V-Modells ist der Schlüssel zur maschinellen Steuerung von IT-Projekten im Sinne eines Workflows. Die Mitarbeiter der WeDo-IT erstellen die Grundlagen und überwachen die Ausführung gemäß dem V-Modell. Bei Bedarf erstellt die WeDo-IT die V-Modellkonforme Dokumentenstruktur und legt Struktur und Dokumente in einem Versionsmanagementsystem ab. Die WeDo-IT erstellt sowohl ein detailliertes Pflichtenheft als auch die Ausschreibungsunterlagen für das KONCOM/IT-Projekt und überprüft die gesamte V-Modell-konforme Umsetzung. Die WeDo-IT bietet ein auf die spezifische Aufgabenstellung der KONCOM/IT optimiertes Projektmanagement als Dienstleistung an, basierend auf ihrem Fach-Know-how, das auch von unabhängigen Dritten bereits zertifiziert wurde.

3.2.3

Anforderungen an ein der Gesellschaft für Projektmanagement (GPM) konformes ProjektmanagementModell

Philosophie des GPM-basierten Projektmanagements ist es, das Umfeld bereits zu Beginn des Projektes einzubeziehen. Dadurch können Erwartungen und Hindernisse frühzeitig erkannt werden. In diesem Sinne ist die Umfeldanalyse ein Frühwarnsystem, das in der Projektarbeit eingesetzt sicherer und leichter zum Erfolg führt. Eine strukturierte Checkliste soll dazu dienen, je nach Projektsituation die relevanten Einflussfaktoren • • • •

möglichst vollständig zu erkennen, in ihren Auswirkungen zu analysieren, in ihrer Wichtigkeit bewertbar zu machen und um schließlich während des Projektes geeignete Maßnahmen zu initiieren.

Ziel der Umfeldanalyse ist es, dem Projektteam die Möglichkeit zu geben, bereits im Vorfeld des Projektes zu agieren, statt auf äußere Zwänge zu reagieren. Darüber hinaus hilft die Ausarbeitung, die Auswirkungen aus dem Umfeld auf den Projektverlauf inhaltlich, sachlich, zeitlich und psychologisch zu berücksichtigen. Weiterhin können auch die Folgewirkungen des Projektes, wenn es Veränderungen des Umfeldes erzeugt, durch Vergleich des derzeitigen Zustands sofort und in Zukunft erkannt werden. Ziel ist es, mit Hilfe der Umfeldanalyse • • • • •

das Umfeld mit seinen Einflussfaktoren lückenlos frühzeitig zu erkennen eine Früherkennung von Problemfeldern zu ermöglichen die Beurteilung der Konsequenzen auf die Projektdurchführung zu erreichen mögliche Strategien des Umfeldes voraus zu sehen Maßnahmen zur Förderung des Projekts frühzeitig zu ergreifen, damit das Projekt am besten gefördert wird.

Die Umfeldanalyse ist im GPM-basierten KONCOM/IT-Projektmanagement ein integraler Teil aller Aktivitäten von der Projektplanung über den Projektstart bis zum Projektende.

74

3 Information Lifecycle Management – Projektorganisation und -struktur

3.2.4

Anforderungen an das Projektmanagement basierend auf “Henley Projectmanagement Course“

Projektmanagement, basierend auf dem Henley Project Management Course, ist sehr stark strategisch ausgerichtet. Henley basiertes Projektmanagement zielt auf die Kernfähigkeit, durch Projekte definierte Geschäftsziele zu erreichen, die nicht von routinemäßigen oder sich wiederholenden Methoden erreicht werden können. Diese Kernfähigkeit ist eine besondere Fähigkeit für jede Organisation. Henleybasiertes Projektmanagement ist deshalb z. B. ein Schlüsselfaktor im IT-Projektmanagement von IBM. IBM betrachtet das Henley-Projektmanagement als einen Schlüsselteil der Strategie der IBM begabte Manager im Betrieb zu halten.Jede IBM Abteilung muss ihre Manager durch das Programm qualifizieren. Die Gesellschaft hat ein Konsortium von europäischen Geschäftsschulen beauftragt, auf Basis des Henley Project Management Course ein IT-Projektmanagementprogramm zu entwickeln. Auf dieses wird bereits aktuell über das Internet von IBM zugegriffen. Die WeDo-IT soll sich an einem Henley-basierten Projektmanagement mit dem Ziel orientieren, eine unternehmensspezifische Weiterentwicklung der Projektmitarbeiter der EurAmFi AG in Richtung des Aufbaus definierter Kernfähigkeiten sicherzustellen. Der auftragsspezifische Grundsatz lautet dabei: • analysiere die Projektsituation (= Diagnose) und • beseitige das so erkannte Problem (= Therapie).

3.2.5

Anforderungen an das Projektmanagement basierend auf “PRINCE2“

Das im Rahmen des ITILv1-Projektes entwickelte innovative IT-Projektmanagement-Framework PRINCE2 (PRrojects IN Controlled Environments) ist die standardmäßige Methode für Projektmanagement im Bereich Aufbau und Betrieb von Infrastruktur. PRINCE2 ist eine Projektführungsmethode, die es ermöglicht, eine breite Vielfalt von Disziplinen innerhalb eines Projekts mit ihren benötigten Aktivitäten zu integrieren. Der spezifische Geschäftsvorfall bestimmt die Ausrichtung von PRINCE2. Dieser wird vom Projektmanagement vom Anfang bis zum erfolgreichen Ende bearbeitet. Das PRINCE2-Framework geht davon aus, dass ein erfolgreiches Projektmanagement aus den Komponenten Organisation, Planung und Controlling besteht, wobei einschlägige Rollen definiert werden, die je nach Projektstand für einzelne Prozesse verantwortlich sind. Die einzelnen Prozesse in PRINCE2, mit denen alle Kernaufgaben eines Projekts abgedeckt werden, sind • • • • • •

SU (Vorbereiten eines Projektes), IP (Initiieren des Projekts), CS (Steuern einer Projektphase), MP (Managen der Produktlieferung) , SB (Managen von Projektphasenübergängen), CP (Abschließen eines Projekts),

3.2 Anforderungen an das Projektmanagement

75

• DP (Lenken eines Projektes, sowie • PL (Planen). PRINCE2 ist eine generisch, leicht anpassbare (tailorable) und einfach durchführbare Projektführungsmethode. die nicht alle Aspekte des Projektmanagements abdeckt. Der Ansatz soll dabei helfen, Risiko zu bewältigen und die Qualität zu kontrollieren, die innerhalb eines Projekts entstehen. Ein PRINCE2-Projekt hat die folgenden Merkmale: • ein endlicher und definierter Lebenszyklus • definierte und messbare Geschäftserzeugnisse • eine entsprechende Gruppe von Aktivitäten, um die Geschäftserzeugnisse zu erreichen • eine definierte Menge von Hilfsmitteln • eine Organisationsstruktur mit definierter Verantwortung, um das Projekt zu bewältigen Die in PRINCE2 fehlenden Aspekte wie Führerschaft, Projektmanagementwerkzeuge und -verfahren werden gut von anderen existierenden Methoden abgedeckt und wurden deswegen in PRINCE2 nicht bearbeitet, um die Integration in bestehende Managementkonzepte zu fördern.

3.2.6

Anforderungen an das Projektmanagement hinsichtlich des IT-Grundschutzes

Eine adäquate Absicherung der unternehmensinternen IT-Infrastruktur muss heute mehr denn je oberste Priorität haben, nicht nur um die Geschäftstätigkeit im eigenen Unternehmen zu gewährleisten, sondern auch um die störungsfreie Abwicklung mit Kunden und Dienstleistern zu garantieren. Zur Unterstützung der Unternehmen im Hinblick auf die effiziente Erarbeitung und Umsetzung von ITSicherheitskonzepten wurde durch das BSI das IT-Grundschutzhandbuch zusammengestellt und Standard-Sicherheitsmaßnahmen für typische IT-Systeme empfohlen. In diesem Kriterienwerk sind – für alle relevanten Bereiche von der Infrastruktur bis hin zur Organisationsstruktur – die Bausteine zur Implementierung der Standard-Sicherheitsmaßnahmen definiert. Ziel ist es, durch organisatorische, personelle,infrastrukturelle und technische Sicherheitsmaßnahmen ein StandardSicherheitsniveau für IT-Systeme aufzubauen, das auch für den äußert sensiblen Bereich der Kundendatenhaltung weiter ausbaufähig ist. Das Projektmanagement der WeDo-IT im Projekt KONCOM/IT muss auch für den Bereich ISO 17799 und den IT-Grundschutz gemäß BSI die Beschreibung der operativen Umsetzung der spezifischen Maßnahmen sowie der einschlägigen Herstellervorgaben liefern für die Bausteine: • • • •

übergeordnete Komponenten Infrastruktur vernetzte Systeme und Server Datenübertragungseinrichtungen

76

3 Information Lifecycle Management – Projektorganisation und -struktur

sowie zusätzlich im Rahmen des Projektes für die eigens entwickelten Bausteine • Speicherung • SAN • NAS jeweils entsprechend der jeweiligen Gefährdungslage und den daraus abgeleiteten spezifischen Einzelmaßnahmen und Aktivitäten.

3.2.7

Anforderung an das Projektmanagement hinsichtlich ISO 20000 konformer Optimierung der ServiceGeschäftsprozesse

ISO 20000, der weltweite Standard für IT-Services, beschreibt den Wandel von der technisch orientierten IT-Abteilung zum kundenorientierten Dienstleister. ISO 20000 in Verbindung mit ITIL beinhaltet eine umfassende fachliche Dokumentation zur Planung, Erbringung und Unterstützung von IT-Serviceleistungen. An der Entwicklung von ITIL waren IT-Dienstleister, Mitarbeiter aus Rechenzentren, Lieferanten, Beratungsspezialisten und Ausbilder beteiligt. Unter anderem deshalb bieten ISO 20000 und ITILv3 die Grundlage zur Verbesserung einer an die Geschäftsprozesse angepassten IT-Infrastruktur. Die zusätzliche Erfahrung eines versierten externen Beraters kann dabei helfen, aus den festgefahrenen Strukturen auszubrechen. ISO 20000 und ITILv3 beschreiben ein systematisches, professionelles Vorgehen für das Management von IT- Dienstleistungen. Das entwickelte Servicekonzept stellt nachdrücklich die Bedeutung der wirtschaftlichen Erfüllung der Unternehmensanforderungen in den Mittelpunkt und erzielt die folgenden Vorteile: • Unterstützung der Geschäftsprozesse • Definition von Funktionen, Rollen und Verantwortlichkeiten im Service Bereich • weniger Aufwand bei der Entwicklung von Prozessen, Prozeduren und Arbeitsanweisungen • höhere Kundenzufriedenheit durch bessere und messbare Verfügbarkeit und Performance ISO 20000 und ITILv3-Projekte stehen damit für höhere Produktivität und Effizienz. In 90 Prozent aller Fälle lassen sich binnen 24 Monaten Einsparungen zwischen 15 bis 30 Prozent erzielen,ohne dass die Unternehmen an Effizienz einbüßen, so die Analyseergebnisse der Computerwoche, die durch die EurAmFi-eigenen Projekterfahrungen bestätigt werden. Die im Projekt KONCOM/IT zu erreichende Optimierung der Geschäftsprozesse zur Senkung der Total Cost of Ownership (TCO) bei der Speicherung von Informationen muss seitens der WeDo-IT durch Anwendung der ITILv3 Best Practices eingehalten werden. Die mangelnde Kosteneffizienz der einzelnen Dienstleistungen ist häufig das Kernproblem bei der Optimierung von Geschäftsprozessen. Durch den Total Cost of Ownership (TCO-)

3.2 Anforderungen an das Projektmanagement

77

Ansatz wird eine sinnvolle Grundlage für die Leistungsverrechnung geschaffen. Im TCO-Ansatz werden zusätzlich zu den Kostenmodellen • Plankostenrechnung und • Prozesskostenrechnung auch der Nutzen der einzelnen IT-Services ermittelt und den Kosten gegenübergestellt. Ziel der TCO-basierten Kosten- und Leistungsverrechnung ist es, die tatsächlich entstandenen Kosten transparent aufzuzeigen und dem Kunden so nur die tatsächlich erbrachte Leistung in Rechnung zu stellen. So kann kontinuierlich die Effizienz des Einsatzes der IT-Infrastruktur sichergestellt werden.Die WeDo-IT kann aufgrund Ihrer Erfahrungen bei verschiedenen IT-Kostenanalyse-Projekten aufzeigen, dass durch die erhöhte Transparenz bereits signifikante Kosteneinsparungen realisierbar sind. Der ITILv3-konforme Basisprozess ist als Regelkreis konzipiert mit der Anforderung der effizienten Erstellung des IT-Services als Eingangsgröße, der Regelstrecke IT-Services und den Stellgrößen • IT-Operationsplanung • Kostenanalyse • Kostenverrechnung mit dem Ziel, eine kosteneffektive Bereitstellung des vereinbarten IT-ServicesLevels zu erreichen. Die Ergebnisse des ITIL-v3 konformen Kostenmanagements beeinflusst wiederum direkt die ITIL-Basis-Prozesse • • • •

Service Design Service Operations Service Transitions Service Level Management (SLM)

3.2.8 Weitere Projektmanagement-Dienstleistungen Im Streben nach Verbesserung der IT-Services sowie nach Effizienz und Qualität werden von der WeDo-IT weitere erprobte Vorgehensweisen gefordert. Im Vordergrund des Maturity Capability Model (CMM-) Ansatzes steht die kontinuierliche Prozessverbesserung. Ziel des Certified Information System Auditor (CISA-) Ansatzes ist die Sicherstellung der Revisionstauglichkeit. 3.2.8.1 CMM und CISA Das Software Engineering Institute (SEI) in den USA hat zur Verbesserung der Softwareentwicklungsprozesse das Capability Maturity Model (CMM) entwickelt. Die WeDo-IT soll diesen Methodenansatz,adaptiert auf die spezifischen deutschen Rahmenbedingungen, sowohl bei der Einführung neuer Software im Rahmen des KONCOM/IT-Projektes, als auch in den Bereichen Personal-, Gruppenprozessund Risk-Management effektiv unterstützen. Das Certified Information System Auditor (CISA-) Programm der ISACA ist der De-facto-Standard im Bereich der Archivierung, des Managements und der Sicherheit der eingesetzten IT-Prozesse.

78

3 Information Lifecycle Management – Projektorganisation und -struktur

Die WeDo-IT soll mit einem CISA-Audit die revisionsgerechte Durchführung aller IT-Aktivitäten der EurAmFi AG sicherstellen. 3.2.8.2 Projekt-Exit-Management Ein weiterer nicht zu unterschätzender Aspekt eines Projektmanagements, das die bisherigen Anforderungen erfüllt, liegt darin schlechte Projekte frühzeitig zu erkennen und sie dann auch zu stoppen. Den meisten Unternehmen fehlt diese Fähigkeit, bei ihnen enden solche Projekte erst, wenn das Scheitern offensichtlich ist. Durch den Exit-Champion der WeDo-IT wird die EurAmFi darin unterstützt, schlechte Projekte rechtzeitig zu stoppen,ohne dass damit ihre eigenen Mitarbeiter nachhaltig demotiviert werden.

3.3

Anwendung des Projektmanagements in den beteiligten Unternehmungen

Sowohl die WeDo-IT als auch die EurAmFi AG haben das Projektmanagement in ihre Unternehmensphilosophie und ihre Unternehmensprojekte integriert. Beide Unternehmen haben bereits vor Jahren erkannt, dass der gestiegenen Komplexität und dem Innovationszwang innerhalb der IT-Branche nur mit Hilfe des Projektmanagements Rechnung getragen werden kann. Die WeDo-IT hat Projektmanagement in ihr Prozesswerk PIWU (Potenziale in Werte umsetzen) integriert. Dies erfolgte nach der Maßgabe: „Der Projektmanagement-Einsatz in Unternehmen muss geplant werden und stufenweise erfolgen, um dauerhaft erfolgreich zu sein. Er bedarf des Aufbaus eigener PM-Kompetenzen durch systematische Schulung und Projektbegleitung, wobei externe Unterstützung den Einführungsprozess stabilisiert.“36 Seit mehreren Jahren bildet die WeDo-IT ihre Projektmanager in Zertifizierungslehrgängen der GPM/IPMA (in Deutschland), des PMI (in den USA) sowie nach PRINCE2 und PMI (im Vereinigten Königreich) aus. Dienstleistungsangebote der WeDo-IT enthalten diesbezüglich den Hinweis auf die Projektorientierung der WeDo-IT Services. Bereits im Projektangebot wird das Projektmanagement als eigenständige Leistung charakterisiert.Projektmanagement für KONCOM/IT wurde wie folgt eingegrenzt: „KONCOM/IT betrifft extrem kritische Geschäftsprozesse. Das Projekt KONCOM/IT ist zugleich extrem zeitkritisch. Die Planung und die Leitung eines derart kritischer Projektes ist deshalb eine Aufgabe, für die der jeweilige Projektmanager ein umfangreiches Portfolio von Fähigkeiten und Fertigkeiten 36

Rößler, Steffen, Risch, Wolfram: Projektmanagement-Einführung, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S. 119.

3.3 Anwendung des Projektmanagements in den beteiligten Unternehmungen

79

benötigt. Nur durch ein wirkungsvolles Projektmanagement können die anspruchsvollen Ziele sicher termin-, kosten- und qualitätsgerecht erreicht werden. Der Projekterfolg hängt dabei entscheidend vom Projektmanagement ab. Die WeDo-IT setzt deshalb während des gesamten Projektes ein professionelles Projektmanagement ein. Unsere erfahrenen und einschlägig zertifizierten Mitarbeiter erstellen dazu ein fundiertes Konzept.“37 Dabei wird auf das Projektmanagement als die Basis für eine funktionierende Projektsteuerung hingewiesen. Sie wird wie eine Landkarte verwendet, die es erlaubt, das Abweichen vom richtigen Weg möglichst frühzeitig festzustellen. Je mehr Zeit der Projektleiter bei der Projektsteuerung darauf verwendet, notwendige Maßnahmen zu treffen und gemeinsam mit seinem Projektteam umzusetzen, desto höher ist die Qualität der einzelnen Steuerungsmaßnahmen. Die WeDo-IT stellt daher eine auf die spezifischen Anforderungen des jeweiligen Kunden optimierte Projektplanungs- und -controlling-Dienstleistung zur Verfügung. Dabei nutzt sie ihr umfangreiches Fach-Know-how im Bereich IT-Infrastruktur,insbesondere Storage, Speichermanagement, Storage Area Networks (SAN) und Network Attached Storage (NAS) sowie der spezifischen Abläufe innerhalb der Kundenstandorte. Der PIWU-Prozess von WeDo-IT orientiert sich am PM-Kanon der GPM. Das V-Modell bildet die Basis für die Durchführung des WeDo-IT Projektmanagements. Im V-Modell wird das Projektmanagement in Form eines Prozesses beschrieben. Dies geschieht durch die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der Realisierung und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen. Neben den vorgegebenen Aktivitäten und Produkten enthält das V-Modell auch Informationen über den Projektablauf. Im V-Modell wird geregelt, welche Ausgangsprodukte von einer Aktivität erzeugt werden und welche nachfolgenden Aktivitäten diese Produkte als Eingänge benötigen.Aus dem inhaltlichen Produktfluss lässt sich eine zeitliche Abfolge der Aktivitäten ableiten. Diese Eigenschaft des V-Modells ist der Schlüssel zur Steuerung von Projekten im Sinne eines Workflows. Die WeDo-IT-Projektmanager erstellen die Grundlagen und überwachen die Ausführung gemäß V-Modell. Sie erstellen ein detailliertes Pflichtenheft und überprüfen dessen V-Modell konforme Umsetzung. Die bisherigen Erfahrungen der WeDo-IT bestätigen eindeutig, dass ein Projekt der Größenordnung von KONCOM/IT aufgrund seiner Komplexität nur mit Verfahren des Projektmanagements erfolgreich durchführbar ist. Die Komplexität erschließt sich schon allein aus dem Umfang und Anzahl der involvierten Server sowie dem Operations Research (OR-) Problem mit der Aufgabenstellung, eine optimale Reihenfolge der Servermigrationen bei den beteiligten Servern unter Gewährleistung minimaler Ausfallzeiten, den Applikationsdowntimes, für die beteiligten Applikationsinstanzen zu finden und zu koordinie37

Thome, Günter, Sollbach, Wolfgang: SOW Statement of Work, KONCOM/IT, Abschnitt Projektmanagement, 2003, S. 13 f.

80

3 Information Lifecycle Management – Projektorganisation und -struktur

ren, die Daten zu klassifizieren, zu verteilen und den Anwendungen Lebenszyklusphasen gemäß den Zugriff auf die jeweiligen Daten zu ermöglichen. Im Rahmen des Projektmanagement-Dienstleistungsangebotes für das Projekt KONCOM/IT erfolgte die Planung und Steuerung sämtlicher Dienstleistungsaktivitäten von WeDo-IT bei der Erbringung der Leistungen für das Projekt. Die EurAmFi AG hat bereits im Rahmen früherer Projekte mit der WeDo-IT die positiven Auswirkungen des fundierten WeDo-IT-Projektmanagements auf die Erreichung sämtlicher Ziele (in time, in scope and in budget) kennen gelernt. Das Projektmanagements für das Projekt KONCOM/IT umfasst: • Abstimmung der Einzelaktivitäten mit der EurAmFi AG • Zeitliche Planung und Koordinierung der Tätigkeiten unter der Berücksichtigung der Rahmenbedingungen • Kostenplanung und -controlling • Kapazitätsplanung und -controlling • Risikoanalyse und Risikomanagement • Projektfortschrittskontrolle • Projektbegleitendes Projektcontrolling • Einsatzplanung und Koordination der Ressourcen der beteiligten Unternehmen • Koordinierung und Überwachung der Arbeiten durch die beteiligten Unternehmen • Sicherstellung der Qualität • Sicherstellen des Informationsflusses • Planung und Koordination von Projektmeetings • Abstimmung von Projektänderungen durch Leistungsänderungsantrag (falls erforderlich) • Erstellung des gemeinsamen Projektleitfadens • Steuerung von Eskalationsprozessen (nach Projektleitfaden) • Reporting und Review der Einzelaktivitäten Die EurAmFi AG hat als zentralen Ansprechpartner für den WeDo-IT- Projektmanager einen Projektmanager für das Projekt KONCOM/IT benannt. Auch die EurAmFi AG verfährt im Projektmanagements gemäß dem PMKanon der GPM. Auch sie bildet ihre Projektmanager zur Zertifizierung durch die PM-Zert aus. So arbeiten bei KONCOM/IT zwei Unternehmen mit gleichem Durchdringungsgrad und gleicher Philosophie hinsichtlich des Projektmanagements zusammen, was den notwendigen Abstimmungsaufwand auf das absolut notwendige Maß reduziert. Falls diese Voraussetzung bei den beteiligten Partnern nicht gegeben ist, sind hier zusätzliche Aktivitäten einzuplanen.

3.4 Aktivitäten der Startphase

3.4 3.4.1

81

Aktivitäten der Startphase Erstellung des Projektleitfadens/Projektmanagementplans

3.4.1.1 Zielsetzung Das Ziel des Projektleitfadens ist es, die wesentlichen organisatorischen Rahmenbedingungen für die Laufzeit des Projektes zu etablieren und die Zuständigkeiten der beteiligten Akteure festzulegen. Dies beinhaltet: • • • •

eine Übersicht über die Projektorganisation die Darstellung der Aufgaben, Zuständigkeiten und Kompetenzen die Einführung von Methoden, Berichtswesen und Kommunikation die Darstellung der Eskalationspfade im Falle dringender Projektentscheidungen • eine Übersicht über die Projektmitglieder und ihre Funktionen 3.4.1.2 Geltungsbereich Die Geltung dieses Projektleitfadens beginnt mit der Unterzeichnung des Angebotes durch die EurAmFi AG und endet mit dem Abschluss des Projektes. 3.4.1.3 Projektgremien Im Folgenden werden die für die Projektorganisation relevanten Gremien kurz aufgeführt und ihre Rollen und Verantwortlichkeiten beschrieben. 3.4.1.3.1 Entscheidungsgremium Das Entscheidungsgremium dient als letzte Entscheidungs- und Schlichtungsinstanz im Falle von Eskalationen oder wesentlichen Projektentscheidungen, die von den ausführenden Projektmitgliedern nicht getroffen werden können (etwa weil sie nicht mit den entsprechenden Weisungsbefugnissen ausgestattet sind oder weil zusätzliche Gelder bewilligt werden müssen).Das Entscheidungsgremium ist nicht aktiv in den operativen Projektverlauf eingebunden, jedoch wird bei Bedarf der Lenkungsausschuss hinzugezogen.

Tabelle 3.1. Das KONCOM/IT-Entscheidungsgremium EurAmFi AG*

WeDo-IT*

Stefano di Ludovico, Vorstand Technik

Jörn Elsenbeck, Geschäftsführer

Ludger Eisenard, CIO

Gerd Ebenstreich, Business Line Manager Telco

* Namen frei gewählt, Ähnlichkeiten mit natürlichen und juristischen Personen sind nicht beabsichtigt und rein zufällig.

82

3 Information Lifecycle Management – Projektorganisation und -struktur

3.4.1.3.2 Lenkungsausschuss Der Lenkungsausschuss ist das zentrale Steuerungsgremium des Projektes. Er überwacht den Projektfortschritt und die Einhaltung der vereinbarten Meilensteine. Er dient als Anlaufstelle bei Problemen, die nicht auf operativer Ebene gelöst werden können, oder bei wesentlichen Abweichungen von den vereinbarten Projektgrößen (Qualität, Termine, Kosten). Der Lenkungsausschuss wird regelmäßig über den Projektverlauf unterrichtet (siehe Berichtswesen) oder kann auf seine Initiative hin Berichte über den aktuellen Projektstand durch die Projektmanager einfordern. 3.4.1.3.3 Projektmanagement-Team Das mit der Durchführung des Projektes betraute Projektmanagement-Team ist für die Planung, Koordination und Steuerung der Projektaktivitäten verantwortlich. In dieser Funktion stimmen die Mitglieder den unterschiedlichen Aufwand der beteiligten Organisationen (EurAmFi AG, WeDo-IT) ab und planen die Einsätze der für die jeweilige Projektphase notwendigen Mitarbeiter. Der Projektverlauf und die Einhaltung der vereinbarten Meilensteine werden überwacht; bei Planabweichungen werden Gegenmaßnahmen innerhalb des Gremiums vereinbart und an den Lenkungsausschuss kommuniziert. Das Projektmanagement-Team erstellt in regelmäßigen Abständen Statusberichte über den aktuellen Projektverlauf. Tabelle 3.2. Der KONCOM/IT Lenkungsausschuss EurAmFi AG*

WeDo-IT**

Kenneth McLallan, Projektleiter EurAmFi KONCOM/IT

Wolfgang Sollbach, Projektmanager KONCOM/IT

Dimitar Abramson, Information Technology Manager EurATel GmbH Ludger Eisenard, CIO

Dr. Günter Thome, Projektmanager und Program Manager WeDo-IT Gerd Ebenstreich, Business Line Manager Telco

* Namen frei gewählt, Ähnlichkeiten mit natürlichen und juristischen Personen sind nicht beabsichtigt und rein zufällig. ** Namen teilweise frei gewählt, Ähnlichkeiten mit natürlichen und juristischen Personen sind nicht beabsichtigt und rein zufällig. Die beiden Autoren haben dieses virtuelle Projekt natürlich nicht in den beschriebenen Rollen geleitet sondern die Projekte, die zu diesem virtuellen Projekt „KONCOM/IT“ kondensiert wurden, wurden in jeweils wechselnden Projekt- und Programmmanagementrollenbetreut.

3.4.1.4 Besprechungen Für die Dauer des Projektes werden folgende Besprechungszyklen vereinbart: 1. Der Lenkungsausschuss trifft sich nur, wenn Probleme und Eskalationen auftreten, die den Projektverlauf gefährden, (siehe Eskalationsbehandlung 3.4.1.5), um über den bisherigen Projektverlauf unterrichtet zu werden und die Planung für die anstehenden Projektphasen abzustimmen. Aufgetretene Probleme werden diskutiert und Lösungen erarbeitet. Der Lenkungsausschuss wird jedoch

3.4 Aktivitäten der Startphase

83

Tabelle 3.3. Das KONCOM/IT-Projektmanagement-Team EurAmFi AG*

WeDo-IT**

Kenneth McLallan, Projektleiter EurAmFi KONCOM/IT

Wolfgang Sollbach, Projektmanager KONCOM/IT Dr. Günter Thome, Projektcontroller KONCOM/IT

* Namen frei gewählt, Ähnlichkeiten mit natürlichen und juristischen Personen sind nicht beabsichtigt und rein zufällig. ** Die beiden Autoren haben dieses virtuelle Projekt natürlich nicht in den beschriebenen Rollen geleitet sondern die Projekte, die zu diesem virtuellen Projekt „KONCOM/IT“ kondensiert wurden, in jeweils wechselnden Projektund Programmmanagementrollenbetreut.

wöchentlich mit einem Statusprotokoll über den aktuellen Projektstand informiert. Aus dem Statusprotokoll soll erkennbar sein, in welchem Zustand sich das Gesamtprojekt, die Teilprojekte sowie einzelne Aktivitäten befinden. 2. Das Projektmanagement trifft sich wöchentlich. Diese Besprechungen sollten während der eigentlichen Implementationsphase in deutlich kürzeren Intervallen stattfinden. Gegenstand dieser Besprechungen ist die operative Planung und Durchführung des Projektes.Die Teilnehmer sind die Mitglieder des Projektmanagements (3.4.1.3.3) und gegebenenfalls die mit der Durchführung betrauten Fachspezialisten der beteiligten Organisationen (EurAmFi AG, WeDo-IT). 3. Mit Unterzeichnung des Vertrages durch EurAmFi AG und WeDo-IT und dem Abschluss der Planungsarbeiten findet einmalig das Projekt-Kick-off statt. Gegenstand des Kick-offs ist die Freigabe der bisher erarbeiteten Planung (etwa dem Gesamtprojektplan, der Projektorganisation, die jeweiligen Aufgaben, die Zuständigkeiten und letztlich die Entscheidungskompetenzen etc.).Die Teilnehmer des Kick-off-Meetings sind die Mitglieder des Projektteams. Die hier vereinbarten Terminzyklen können darüber hinaus in Abstimmung mit den jeweiligen Teilnehmern dem Projektverlauf angepasst werden. 3.4.1.5 Eskalationsbehandlung Sollten während des Projektes Probleme oder Eskalationen auftreten, wird zunächst versucht, eine Lösung auf operativer Ebene durch die Projektmanager zu finden (Eskalationstufe 1). Sollten die aufgetretenen Probleme durch die Projektmanager nicht gelöst werden können (etwa weil es sich dabei um Budgetentscheidungen handelt), werden sie an den Lenkungsausschuss verwiesen (Eskalationsstufe 2).Die letzte Eskalationsebene im Falle von gravierenden Problemen,die trotz mehrfacher Versuche nicht gelöst werden können, ist das Entscheidungsgremium (Eskalationsstufe 3). 3.4.1.6 Gesamtprojektplan Für den Verlauf des Projektes wird mit MS Project 2003 ein Gesamtprojektplan erstellt, in dem die einzelnen Phasen zusammen mit ihren Meilensteinen und Verantwortlichkeiten beschrieben werden. Der erste Entwurf des Projektplanes wird

84

3 Information Lifecycle Management – Projektorganisation und -struktur

durch die Projektleiter der Firmen EurAmFi AG und WeDo-IT erstellt. Der so erarbeitete Projektplan gilt als produktiv, sobald er im Projekt-Kick-off-Meeting abgenommen wird. Er ist damit für den weiteren Projektverlauf die verbindliche Planungsgrundlage. Änderungen beziehen sich fortan immer auf den Gesamtprojektplan und werden zentral von beiden Projektleitern verwaltet, federführend vom Projektleiter der WeDo-IT. 3.4.1.6.1 Verwaltung des Masterplanes Da in KONCOM/IT mehrere Organisationen eingebunden sind (EurAmFi AG, WeDo-IT) und keine einheitliche Projektmanagement-Plattform existiert, ist es notwendig, den Gesamtprojektplan zentral zu verwalten, um Mehraufwände und Inkonsistenten zu vermeiden. Um die damit verbundenen administrativen Aufwände möglichst gering zu halten, übernimmt der Projektmanager der WeDo-IT die Ownership des Masterplanes. Änderungen des Masterplanes werden an die EurAmFi-Projektleitung kommuniziert und von ihr zur internen Verwendung gepflegt. Die neue Version des Projektplanes wird dann den Projektbeteiligten im Adobe PDF-Format zur Verfügung gestellt. 3.4.1.6.2 Teilabnahme von Projektmeilensteinen Der Projektplan ist in einzelne Phasen untergliedert, die durch einen klar definierten Meilenstein abgeschlossen werden. Nach Abschluss eines Meilensteines wird das Ergebnis durch die Projektleiter abgenommen und protokolliert. Die gegebenenfalls für die Abnahme notwendigen Dokumente und Ergebnisse werden dem Projektleitergremium rechtzeitig (2 Tage vorher) zur Verfügung gestellt.

3.4.1.7 Berichtswesen Mit dem eigentlichen Beginn des Projektes (Annahme des Angebotes, Kick-offMeeting) werden regelmäßige Statusberichte erstellt, die den aktuellen Projektverlauf zusammenfassen und bewerten. In diesen Statusberichten wird über folgende Punkte informiert: • • • • • •

Beschreibung der laufenden Aktivitäten aktueller Projektstand gegebenenfalls Abweichungen und Probleme Risiken und Maßnahmen zu ihrer Behebung Termine Verantwortlichkeiten

Um den daraus resultierenden administrativen Aufwand möglichst gering zu halten, ist es sinnvoll, die Erstellung der Statusberichte mit der Pflege des Masterprojektplanes zu koppeln. Dies gehört damit zu den Aufgaben des WeDo-IT Projektmanagers, der darin von dem WeDo-IT-Projektcontroller unterstützt wird. Die Statusberichte gehen mit Projektbeginn wöchentlich an den folgenden Verteiler:

3.4 Aktivitäten der Startphase

85

Tabelle 3.4. Der Verteiler für KONCOM/IT-Statusberichte To* ···

[email protected]; [email protected];

[email protected]; [email protected];

[email protected]; [email protected]; [email protected]; [email protected];

[email protected]; [email protected]; [email protected]; [email protected];

[email protected] CC ···

[email protected]; [email protected]

[email protected];

* Namen frei gewählt, Ähnlichkeiten mit natürlichen und juristischen Personen sind nicht beabsichtigt und rein zufällig.

3.4.1.8 Änderungsmanagement Die in dem unterzeichneten Angebot vereinbarten Leistungen und Services bilden den Rahmen für alle Projektaktivitäten. Diese werden in einem gemeinsam von beiden Projektleitern erstellten Statement-of-Work (SOW) dokumentiert. Sollten sich während des Projektes Änderungen an dem Leistungsportfolio ergeben, werden diese als schriftliche Change Request (CR) dokumentiert und zur Entscheidung an die jeweiligen Projektgremien übergeben. 3.4.1.8.1 Projektänderungsantrag Jede Änderung dieser Projektbeschreibung (SOW), unabhängig von der jeweiligen Auswirkung, wird über einen Projektänderungsantrag, der von der EurAmFi AG beauftragt werden muss, mit folgendem Inhalt abgewickelt: • gewünschte Änderung mit genauer Beschreibung • Notwendigkeit der Änderung (Auswirkung bei Nichtdurchführung) • Auswirkungen (auf bereits verabschiedete Arbeitsergebnisse) Der Antragsteller muss seinen Änderungswunsch so genau spezifizieren, dass die EurAmFi AG und/oder die WeDo-IT den Antrag auf der Grundlage der verabschiedeten Projektergebnisse prüfen kann. 3.4.1.8.2 Projektänderungsprüfung EurAmFi AG/WeDo-IT werden die gewünschte Änderung auf der Basis vorhandener und verabschiedeter Projektdokumente sorgfältig analysieren und dem Projektmanagementteam von KONCOM/IT als Entscheidungsgrundlage folgende Informationen zur Verfügung stellen: • Analyseergebnisse (Abhängigkeiten) • Realisierungsvorschlag mit einer Kurzbeschreibung der möglichen Durchführung • Auswirkungen auf Kosten und Termine

86

3 Information Lifecycle Management – Projektorganisation und -struktur

3.4.1.8.3 Projektänderungsauftrag Mit der Unterschrift beider Vertragspartner auf dem Projektänderungsantrag und/oder einem begleitenden Nachtragsangebot, gilt die Änderung als beauftragt. 3.4.1.8.4 Umsetzung der Projektänderung Im Falle der Durchführung der Änderung wird das Änderungsformular Basis für die Änderung oder Ergänzung des aktuellen Projektplanes. 3.4.1.9 Definition der Projektziele 3.4.1.9.1 Der Projektauftrag Zum Zeitpunkt des Projektstarts werden bei der EurAmFi AG in den drei Standorten/Rechenzentren • Hauptverwaltung (RZ 1) • Technikzentrum (RZ 2) • Notfallrechenzentrum (RZ 3) 92 Speichersysteme älterer Bauart betrieben. Die Zielsetzung für KONCOM/IT ist gemäß dem Projektauftrag, zur Reduzierung der TCO die voraussehbaren Wartungskosten zu reduzieren und gleichzeitig zur Ausnutzung der technologischen Weiterentwicklung diese Systeme auf neue „tiered“-Speichersysteme zu konsolidieren, die den unterschiedlichen Wertigkeiten der gespeicherten Daten in ihrem Lebenszyklus gerecht werden. Dabei sollen die Daten in drei Datenklassen (Hochproduktivdaten, Nearline-Daten, Archivdaten) untergliedert und dementsprechend auf die neue Infrastruktur migriert werden. Der Projektauftrag der EurAmFi AG an das Projektteam und die WeDo-IT lautet „Durchführung der Migration der Anwendungen und falls erforderlich der Server-Cluster auf die konsolidierte Speicherumgebung ohne Einschränkung des 7 Tage pro Woche und 24 Stunden pro Tag laufenden Produktionsbetriebes.“ Dieser Projektauftrag wurde in Detaillierungsgesprächen durch folgende Zielsetzungen erweitert. Unter betriebswirtschaftlichen Gesichtspunkten soll mit dem Projekt KONCOM/IT: • • • • • • •

Kostenreduzierung für den laufenden Betrieb Vereinfachung der betrieblichen Prozesse Normierung der Geschäftsprozesse an den Standorten/Rechenzentren Einbettung der Standorte/Rechenzentren in eine unternehmensweite Strategie Ausschöpfung des Potenzials für die Automatisierung von Prozessen lebenszykluskonforme Datenspeicherung Einhaltung der Compliance der Datenhaltung zur relevanten Gesetzes- und Verordnungslage im internationalen Markt der EurAmFi AG

mit Berücksichtigung der Einmalkosten für eine schnelle Aufnahme des Betriebs der Zielumgebung erreicht werden. Für die Überführung in die konsolidierte„tiered“ Ziel-Speicherumgebung sind folgende Anforderungen für die Kategorien an Speichersystemen gegeben:

3.4 Aktivitäten der Startphase

87

Abb. 3.1. Der Projektänderungsantrag

• Überführung der Host Connectivity von SCSI in eine switched SAN-Umgebung und • Migration und Anbindung von 384 Servern und Clusterservern einschließlich den auf diesen betriebenen Applikationsinstanzen. Dieses Zielbündel erfüllt nicht die Anforderung der Quantifizierbarkeit/Operationalität.38 Die Operationalisierung der Ziele folgt im Vorgang zur Projekt-Kickoff-Veranstaltung. 3.4.1.9.2 Wesentliche Randbedingungen für die Realisierung des Projektes Als projektbestimmende Anforderung ist definiert, dass die Migration und Konsolidierung mit minimalen geplanten Applikationsauszeiten sowie ohne jede un38

Grau, Nino: Projektziele, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S. 155.

88

3 Information Lifecycle Management – Projektorganisation und -struktur

geplante Applikationsauszeit und insbesondere ohne Datenverlust („data loss“) erreicht werden muss. 3.4.1.9.3 Projektziele Der Zielfindungsprozess ist Bestandteil der dreitägigen Projekt-Kick-off-Veranstaltung.Der Projektmanager der EurAmFi AG,der Projektmanager seitens WeDoIT und der Projektsponsor der EurAmFi AG operationalisieren vor Beginn der Kick-Off-Veranstaltung die im Projektauftrag vorgegebenen Ziele aus dem Vertragswerk zu einem Projektziel, das als Einziges vor Beginn der Kick-off Veranstaltung vorgegeben wird. Als Projektziel für KONCOM/IT wurde definiert: „Erstellung des Pflichtenheftes und der Ausschreibungsunterlagen, Durchführung der Ausschreibung, Lieferantenauswahl sowie Planung und Durchführung der Konsolidierung und Migration von 640 Anwendungen und 384 Server und Clusterserver sowie 92 Speichersystemen älterer Bauart auf neue Speichersysteme in einer „Disaster Recovery“ Umgebung in 2 Standorten. Einsparung von 11,2 Millionen Euro Wartungskosten über 4 Jahre. Einführung von SAN-Anschlusstechnik und zentralisierte Speicherverwaltung sowie Gewährleistung der Compliance durch lebenszykluskonforme Speicherung auf hochverfügbaren Speichersystemen mit K-Fall-Schutz für Daten der Datenklasse 1 (Hochproduktivdaten), auf hochverfügbaren Speichersystemen ohne K-Fall-Schutz für Daten der Datenklasse 2 (Nearline-Daten) und hochverfügbaren Archivsystemen für Daten der Datenklasse 3 (Archivdaten).“ Das Projektziel kann wiederum in die drei Teilziele Zeit, Kosten und Qualität untergliedert werden: 3.4.1.9.3.1 Kostenziele • Einsparung von 11,2 Millionen Euro Wartungskosten über eine Laufzeit von 4 Jahren • Die Projektmanagementkosten seitens WeDo-IT dürfen 1.2 Millionen Euro nicht übersteigen39 Unterziele • Termingerechte Rückführung der Altsysteme zu jedem Monatsende • Einsatz kostengünstigen Onsite-Personals • Keine Freigabe neuer Kapazitäten auf den abzulösenden Altsystemen 3.4.1.9.3.2 Leistungsziele • Konsolidierung von 384 Server und Clusterserver sowie 640 Anwendungen von 92 Altspeichersystemen auf neue Speichertechnologie • Aufbau einer K-Fall Umgebung für die Server und Clusterserver-Anwendungen der Datenklasse 1 39

Internes Unterziel der WeDo-IT.

3.4 Aktivitäten der Startphase

89

• Aufbau Umgebung ohne K-Fall-Schutz für die Server- und Clusterserver-Anwendungen der Datenklasse 2 • Aufbau einer Archivierungsumgebung für die Server- und Clusterserver-Anwendungen der Datenklasse 3 • Einführung der SAN-Anschlusstechnik • Zentralisierung der Speicherverwaltung • Gewährleistung der Compliance über den Informations Lebenszyklus • Erstellung des Pflichtenheftes und der Ausschreibungsunterlagen • Durchführung der Ausschreibung und Lieferantenauswahl Unterziele • Erstellung allgemeingültiger Migrationsstrategien und Konzepte • Aufbau eines Qualitätssicherungssystems für den Übergang der Betriebsverantwortung auf Mitarbeiter der EurAmFi AG • Erstellung allgemeingültiger Konfigurationsrichtlinien für automatisierte Prozesse für die Migrationen der Daten im Lebenszyklus • Sicherstellung der aktuellen Performancewerte auf der Neuumgebung • Sicherstellung der Dokumentation der Kapazitätszuweisungen • Sicherstellung des unterbrechungsfreien Anwendungsbetriebs auf der Neuumgebung 3.4.1.9.3.3 Terminziele • Projektende zur Realisierung der Kosteneinsparungen ist der 30.09.200x. Unterziele • Berücksichtigung der Frozen-Time der EurATel im Weihnachtsgeschäft • Berücksichtigung der Frozen-Time der EurATel im Ostergeschäft Das Projektziel wurde vor Projektstart vorgegeben. Die Unterziele wurden in dem dreitägigen Projekt-Kick-off-Meeting in zwei unterschiedlichen Gruppen festgelegt. Die eine der beiden Gruppen definierte die Ziele über das intuitive Verfahren Methode 635 40. Die zweite Gruppe definierte die Ziele diskursiv über ein Analogieverfahren, bei dem ausgehend von komplexen Projekten aus der Vergangenheit die Ziele für das Projekt KONCOM/IT analog abgeleitet wurden. In der Gesamtrunde wurde dann der Konsens über die wesentlichen Unterziele erreicht. Mit dieser komplexen Art der Zielfindung, wie der zunächst als zeitlich und aufgrund der zusammengezogenen Ressourcen als überdimensioniert erscheinen40

Die Methode 635 ist als Kreativitätstechnik eine Weiterentwicklung der BrainstormingTechnik, bei der die Ergebnisse nicht mündlich geäußert und vom Moderator auf einem Medium notiert werden. Bei der Methode 635 schreiben 6 Gruppenmitglieder jeweils 3 Ideen auf ein Blatt Papier. Diese Papiere werden in einer vorgegebenen Reihenfolge genau 5-mal weitergegeben, wobei die Mitglieder jeweils wieder 3 Ideen notieren oder bereits auf dem Notizblatt stehende verfeinern. Vgl. dazu Bergfeld, Heinz; Kreativitätstechniken, aus: GPM/RKW Lehrgang Projektmanagement, PMF III - Wissensspeicher CD, Serie 1501/2000, 2000, S. 813ff.

90

3 Information Lifecycle Management – Projektorganisation und -struktur

den Kick-off-Veranstaltung, sollten seitens der Projektleitung vor allem zwei Ziele erreicht werden. Die als wesentlich erkannten EurAmFi AG/EurATel GmbH-internen Stakeholder sollten in das Projekt integriert werden und durch die Arbeit in unterschiedlichen Gruppen und den nachgelagerten Konsensrunden sollte aktiv Teambildung betrieben werden.

3.4.2

Die Projektumfeldanalyse

Aufgrund der ökonomischen Bedeutung des Projektes wurde bereits mit Start des Projektes eine Projektumfeldanalyse durchgeführt, welche die Schlüsselpersonen und -Organisationen der an dem Projekt beteiligten und der von dem Projekt betroffenen Personen und Organisationen identifizieren sollte. Außerdem sollte durch die Projektumfeldanalyse sichergestellt werden, dass mit geeigneten Maßnahmen diese Key-Player in das Projekt so integriert werden, dass von ihnen der Projekterfolg aktiv mitgetragen wird. Zur Identifikation der projektkritischen Stakeholder wurde eine Betroffenheitsanalyse durchgeführt. Als wesentliche interne Stakeholder wurden erkannt: • Stefano di Ludovico, als Technikvorstand Sponsor des Projektes • Ludger Eisenard, als CIO der EurAmFi AG verantwortlich für das Kostensenkungsziel und für den reibungslosen Betrieb der Umgebung • Dimitar Abramson, als Information Technology Manager der EurATel GmbH betroffen von den Migrationen, da sämtliche kaufmännischen Anwendungen der EurATel GmbH aus Konzerninteresse auf den Systemen laufen, die für die EurAmFi AG von der EurAmFi Business Services GmbH betrieben werden41 • Thomas Goppel, Leiter Produktion der EurAmFi Business Services GmbH42 • Mitarbeiter der Produktionssteuerung der EurAmFi Business Services GmbH43 • Mitarbeiter des Kapazitätsmanagements der EurAmFi Business Services GmbH • Mitarbeiter des Delivery Management der EurAmFi Business Services GmbH Als die wesentlichen EurAmFi-externen Stakeholder wurden identifiziert: 41

42

43

Die EurATel GmbH betreibt für den Netzbetrieb in eigener Regie ein Rechenzentrum mit ausgelagertem K-Fall-Rechenzentrum. Die Trennung der kaufmännischen Anwendungen von diesen netztechnischen Anwendungen ist der EurATel GmbH ein Dorn im Auge, da ihre kaufmännischen Anwendungen von betriebsbedingten Ausfallzeiten der Gesamt-IT der EurAmFi AG, die von der EurAmFi Business Services GmbH betrieben wird, ebenfalls betroffen sind. Aufgrund einer konzerngetriebenen Entscheidung des EurAmFi-Technikvorstands di Ludovico kann die EurATel GmbH ihre Anwendungen nicht unter ihrem eigenen Dach betreiben. Namen frei gewählt, Ähnlichkeiten mit natürlichen und juristischen Personen sind nicht beabsichtigt und rein zufällig. Die EurAmFi Business Services GmbH ist eine 100 %ige Tochtergesellschaft der EurAmFi AG. Sie ist der Outsourcing-Partner der EurAmFi AG für den Betrieb der kompletten Anwendungsumgebung der EurAmFi.

3.4 Aktivitäten der Startphase

91

• der Kunde OS-CARBON (Kohlefaser Produkttechnologien) • das BSI • die ISACA Ferner wurde für diese Stakeholder analysiert, wie deren objektive (bekannten) und subjektive (vermuteten) Ziele im Vergleich zu den Projektzielen zu bewerten sind. Dabei wurden potenzielle Konflikte seitens der EurAmFi-internen Stakeholder bei den Mitarbeitern des Kapazitätsmanagements und der Produktionssteuerung der EurAmFi Business Services GmbH dahingehend identifiziert, dass die wesentlichen Aktivitäten aus dem Projekt KONCOM/IT neben dem „Tagesgeschäft“ zusätzlich anfallen, so dass auf diese Mitarbeiter stark erhöhte Anforderungen zukamen. Das Delivery Management der EurAmFi Business Services GmbH stellte ebenfalls ein erhöhtes Konfliktpotenzial dar, da bei der Initiierung des Projektes reine Kostenaspekte betrachtet, die Einhaltung der SLAs gegenüber den Kunden der EurAmFi Business Services GmbH dagegen in keiner Weise beachtet worden waren. Dies betrifftvor allem den Kunden OS-CARBON, dessen Anwendungen aufgrund der Hochverfügbarkeitsanforderungen auf den neuen Plattformen betrieben werden sollen, der jedoch nicht das geringste Eigeninteresse an dem Technologiewechsel zeigte, da die EurAmFi Business Services GmbH die abgeschlossenen Service Level Agreements (SLA) auf der aktuellen Plattform stets eingehalten hat. Synergien waren bei dem Leiter der Produktion der EurAmFi Business Services GmbH zu erwarten, da er bei Erfolg des KONCOM/IT-Projektes eine deutliche Arbeitsentlastung seiner Mitarbeiter erwartet. Durch die Einführung automatisierter Prozesse und die Reduktion der zu betreuenden Systeme erwartet er den Rückgang von Störfällen, ein leichteres Monitoring der Umgebung sowie eine bessere Erfüllung der von der EurAmFi Business Services GmbH eingegangenen SLAs. Synergien waren ebenfalls bei dem CIO der EurAmFi AG zu erwarten, da bei Erfolg dieses Projektes die Kosteneinsparungen bis in den Vorstand der EurAmFi AG sichtbar gemacht und dem CIO der EurAmFi AG zugerechnet werden konnten. Seitens der EurAmFi-externen Stakeholder konnte das Konfliktpotenzial für das Projekt als relativ gering betrachtet werden, solange die SLAs eingehalten werden konnten. Ein nicht zu unterschätzendes Konfliktpotential bestand jedoch darin, dass von diesen externen Stakeholdern erwartet wurde, dass sie an der angestrebten Kostenreduktion in Form günstigerer SLAs beteiligt werden wollten. Die externen Stakeholder BSI, ISACA und IDW stellten kein Konfliktpotenzial dar. Konflikte konnten hier nur erwartet werden, wenn das Leistungsziel Compliance nicht erreicht werden konnte. Ein Konflikt-/Einfluss-Diagramm für das Stakeholder-Management wurde deshalb nicht erstellt. Sehr wohl wurde jedoch das Stakeholder-Management als Bestandteil des Risikomanagements dahingehend betrieben, dass eine Beeinflussung und Steuerung der Stakeholder durch geeignete Maßnahmen durchgeführt wurde. Dabei wurden die Maßnahmen für alle als projektkritisch erkannte Stakeholder ergriffen, da diese alle steuerbar waren.

92

3 Information Lifecycle Management – Projektorganisation und -struktur

Die Stakeholder Kapazitätsmanagement und Produktionssteuerung der EurAmFi Business Services GmbH wurden zu Beteiligten des Projektes gemacht, indem diese beiden Teams zu gleichberechtigten Teilprojekten des Projektes KONCOM/IT erklärt und in die Planungs-, Steuerungs- und Entscheidungsprozesse des Projektes integriert wurden. Das Delivery Management der EurAmFi Business Services GmbH wurde in die wöchentlichen Statusmeetings des Projektes integriert. Ferner wurde frühzeitig in der Projektplanung sichergestellt, dass dem Delivery Management nicht nur die Erfüllung der existierenden SLAs garantiert wurden sondern zusätzliche Leistungen für die Ausgestaltung der SLAs mit dem Kunden angeboten werden konnten. Dies wurde seitens des Projektmanagement-Teams der EurAmFi AG und der WeDo-IT durch gezielte Marketingmaßnahmen auch bei den Kunden der EurAmFi Business Services GmbH unterstützt. Damit konnte auch erreicht werden, dass für diese externen Stakeholder die Projektziele zu Stakeholderzielen wurden. Neben der Stakeholderanalyse wurden, wie bei Platz gefordert, zum Projektstart die Konsequenzen aus der Unsicherheit des Projektes gezogen: • „Erhöhen des Aufwandes zu Beginn des Projektes (Startphase), um möglichst viel Unsicherheit abbauen zu können.“44 Diese Konsequenz wurde in KONCOM/IT gelebt. Die in der Stakeholderanalyse ermittelten Betroffenen/Beteiligten wurden in den Projekt-Kick-off-Workshop integriert. Dieser Workshop stellte mit einer Dauer von 3 Tagen bereits alle bisher in der Zusammenarbeit von WeDo-IT und EurAmFi AG veranstalteten Meetings in den Schatten. Hier wurden zur Vermeidung des„Whiscy-Syndroms“45 die Zieldefinition, die Projektstrukturierung, der rudimentäre Phasenplan und das generelle Vorgehen im Team erarbeitet. Jedes Teilprojekt war mit seinem Teilprojektleiter und mindestens 2 Fach-Mitarbeitern vertreten. Außerdem wurde bei Projektstart in enger Abstimmung mit den Teammitgliedern die fachliche Weiterbildung der Teammitglieder geplant. Hierzu wurden die Mitarbeiter befragt, welche Trainingsmaßnahmen aus ihrer Sicht für die Erfüllung ihrer Projektaufgaben notwendig waren. Diese wurden danach gemeinsam mit dem jeweiligen Mitarbeiter und mit dessen Manager abgestimmt und in die Wege geleitet. Nach dem Kick-off-Workshop wurde mit der Teilaufgabe„Strukturen und Prozesse“ vor dem Start der eigentlichen Aktivitäten die Prozessstruktur definiert sowie die für die Migrationen notwendigen strukturellen Arbeiten durchgeführt. 44 45

Platz, Jochen: Projektstart, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S. 1055. „Man will möglichst bald mit der Realisierung beginnen und will auch Ergebnisse sehen. Das heißt: Die Definitionsphase wird oft viel zu schnell abgeschlossen. In den USA wird diese Haltung auch als Whisky-Syndrom bezeichnet. Das ist eine Abkürzung für die ungeduldige Frage Why isn’t Sam Coding yet?“ Schelle, Heinz, a.a.O., S. 83. Anmerkung: Aufgrund des direkten Zitats wurde hier auch die fehlerhafte Markierung der akronymbildenden Zeichen übernommen. Die Hervorhebung sollte korrekterweise folgenderweise aussehen: Why isn’t Sam coding yet. (Die Autoren).

3.5 Aktivitäten über die komplette Projektlaufzeit

93

Hier sind insbesondere die Definition und Beschreibung der Migrationsverfahren, der Rückfalllösungen, der Backup- und Restore-Verfahren sowie der Konfigurationsrichtlinien zu nennen. Diese grundlegenden Arbeiten wurden nach einer Bearbeitungsdauer von 3 Monaten nicht nur Grundlage für die KONCOM/IT, sondern auch Standards für sämtliche weiteren IT-Projekte der EurAmFi AG, womit für diese erhebliche Synergieeffekte erreicht werden konnten.

3.5 Aktivitäten über die komplette Projektlaufzeit 3.5.1

Die Risikoanalyse

Die Projektrisiken wurden im Kick-off-Workshop vom Team in Gruppen von jeweils 6 Teammitgliedern erarbeitet und im Plenum kondensiert und strukturiert. Die Abbildungen 3.2 bis 3.6 zeigen die erkannten Risiken auf. Neben den Risiken, die aufgrund der Interessenlage des Projektumfeldes für das Projekt existierten (Betroffene, Beteiligte), waren technische und organisatorische Risiken zu betrachten. Von den Betroffenen OS-CARBON und EurATel gehen, wie bereits in der Umfeldanalyse beschrieben, klare Risiken für das Projekt KONCOM/IT aus. Die OSCARBON ist der klassische Betroffene des Projektes. Sie hat primär durch das Projekt keinerlei Nutzen. Ihre von der EurAmFi Business Services GmbH betrie-

Abb. 3.2. Die Risiken von KONCOM/IT

94

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.3. Risiken durch Betroffene des Projektes KONCOM/IT

bene Anwendungsumgebung läuft stabil, die SLAs wurden bisher stets eingehalten. Die durch die Migrationsaktivitäten von KONCOM/IT für die OS-CARBON bestehenden Ausfallrisiken werden nicht durch Interessen der OS-CARBON am Projekt gedeckt. Die EurATel GmbH als Konzerntochter ist auch Betroffene des Projektes, da ihre Anwendungen ebenfalls den technischen und organisatorischen Risiken von KONCOM/IT unterliegen. Diesen wird durch die Einbeziehung der EurATel GmbH in die Projektorganisation und die Entscheidungsgremien des Projektes begegnet. Dennoch ist die EurATel GmbH aus Projektsicht mit großer Vorsicht zu behandeln, da das Projekt ihren eigenen Bestrebungen widerspricht. Die EurATel möchte sämtliche Anwendungen aus dem Betrieb durch die EurAmFi Business Services GmbH herauslösen und selbst betreiben und wird lediglich durch die Konzernentscheidung zu KONCOM/IT daran gehindert, diese Interessen offen zu postulieren. Die Risiken, die den Beteiligten des Projektes zugeschrieben werden können, sind klassische Kommunikations-, Ressourcen- und Interessenskonfliktrisiken. So sind im KONCOM/IT-Projekt allein 11 Lieferanten zu koordinieren, die im EurAmFi-Konzern im Wettbewerb zueinander stehen. So sind die Lieferanten EMC2, Hitachi Data Systems (HDS), Sun, StorageTek, IBM und Hewlett Packard (HP) Unternehmen, die für die Speichersystemkonsolidierung und die ILM-Archivierungs- und „tiered“ Speicherlösung eine komplette Produktpalette anbieten können. LSI-Logic hat hier noch eine besondere Stellung,da sie sowohl als

3.5 Aktivitäten über die komplette Projektlaufzeit

Abb. 3.4. Risiken durch Beteiligte des Projektes KONCOM/IT

95

96

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.5. Technische Risiken des Projektes KONCOM/IT

Abb. 3.6. Organisatorische Risiken des Projektes KONCOM/IT

3.5 Aktivitäten über die komplette Projektlaufzeit

97

Direktanbieter für die Zielumgebung auftreten kann als auch als Komponentenlieferant für die übrigen Hersteller in Frage kommt. Die Softwarelieferanten SAP, Microsoft und Oracle stehen mit ihren Produkten im EurAmFi-Konzern zwar nicht in direkter Konkurrenz zueinander, müssen jedoch teilweise für Systemmigrationen zeitgleich ins Boot geholt werden, was Ressourcen- und Kommunikationsrisiken birgt. Die Risiken der beteiligten Teams der EurAmFi Business Services GmbH sind klare Ressourcenrisiken. Aufgrund der Größenordnung des Projektes müssen aus jedem Team des Bereiches Produktion der EurAmFi Business Services je zwei Mitarbeiter zur Projektunterstützung abgestellt werden. Dies betrifft die Teams Produktionssteuerung mit insgesamt 10 Mitarbeitern, Backup/Archivierung mit 5 Mitarbeitern, Datenbanken mit 8 Mitarbeitern, Application Support mit 8 Mitarbeitern, Storage mit 6 Mitarbeitern und Kapazitätsmanagement mit 3 Mitarbeitern. Das Delivery Management muss mit seinen Delivery Managern für die EurAmFi AG, die EurATel GmbH und die OS-CARBON im Projekt vertreten sein. Das Controlling der EurAmFi AG, die Rechtsabteilung der EurAmFi AG sowie die EurATel GmbH bergen Koordinationsrisiken, da diese jeweils rechtzeitig in das Projekt eingebunden werden müssen, jedoch klar formulierter Arbeitspakete mit wenig flexiblen Fertigstellungsterminen bedürfen. Insgesamt wird das Projekt KONCOM/IT in einer klassischen Matrixorganisation neben dem Tagesgeschäft betrieben. Dies bedeutet, Projektressourcen werden aus dem Tagesgeschäft freigestellt, solange dieses und damit die Linienorganisation nicht die Mitarbeiter benötigt. Dies stellt zumindest bei den Mitarbeitern der EurAmFi Business Services GmbH ein hohes Risiko dar, da diese bei Produktionsstillständen stets aus dem Projekt genommen werden können und Neugeschäft gegenüber dem Projekt priorisiert werden kann. KONCOM/IT birgt eine Vielzahl technischer Risiken. Die 640 Anwendungen nutzen bisher insgesamt 92 Speichersysteme älterer Bauart. Vom geplanten/ungeplanten Ausfall eines Speichersystems konnten somit durchschnittlich 7 Anwendungen betroffen sein. Die Konsolidierung wird auf deutlich weniger Speichersysteme neuerer Bauart stattfinden. Erste Planungen gehen von 16 Speichersystemen für alle 3 Datenklassen aus. Dies bedeutet, dass zukünftig durchschnittlich 40 Anwendungen von einem Ausfall nur eines Speichersystems betroffen sein können. Mit der steigenden Zahl von Anwendungen steigt auch der Koordinationsaufwand, gemeinsame Ausfallzeiten für die betroffenen Anwendungen zu finden. Ein weiteres Risiko stellt – bei der kurzen terminlichen Gestaltung von KONCOM/IT – die Dauer der Hardwarebeschaffung dar. Hier muss über die Schritte Erstellung des Pflichtenheftes, Erstellung der Ausschreibungsunterlagen inklusive Entscheidungsmatrix, Durchführung der Ausschreibung, Bewertung der Angebote, Vertragsverhandlung bis hin zur Lieferantenbeauftragung in kurzer Frist der technische Rahmen für KONCOM/IT gesetzt und fixiert werden. KONCOM/IT muss zumindest für die Zeit bis zur endgültigen Ablösung der Altsysteme die Infrastruktur verfügbar haben, die Neusysteme parallel zu den Altsystemen zu betreiben. In den vorgesehenen Rechenzentren muss Strom- und

98

3 Information Lifecycle Management – Projektorganisation und -struktur

Notstromversorgung, Kühlleistung, Abwärmeleistung etc. für diese Neusysteme bereitgestellt werden können. Um eine zielgerichtete performanceoptimierte Migration auf die Neusysteme vorbereiten und die dafür erforderlichen Konfigurationsvorgaben erarbeiten zu können, werden verlässliche Performancedaten der Altumgebung benötigt. Diese wurden noch niemals in Gänze erfasst. Aufgrund der Inhomogenität der Altumgebung mit Speichersystemen unterschiedlicher Hersteller erscheint auch die Vergleichbarkeit als potenzielles Risiko. Für die Durchführung der Migration wird vor allem die Gefährdung der Verfügbarkeit der Applikationen während der Migration als Risiko gesehen. Um eine möglichst geringe Wahrscheinlichkeit der Nichtverfügbarkeit der Applikationen zu realisieren, kann über Springersysteme migriert werden. Dieses Migrationsverfahren ist jedoch sehr aufwendig, mit hohem Personaleinsatz verbunden, fehleranfällig und sehr QS-intensiv. Letztendlich wird die Komplexität der Compliance-Anforderungen als technisches Risiko von KONCOM/IT erkannt. Hier geht es um die vollständige Erfassung sämtlicher Vorschriften des nationalen Rechts (hier des Deutschen-) sowie des EUund des US-amerikanischen Rechtes. Die gemäß der Compliance-Anforderungen vorzunehmende Datenklassifizierung wird ebenfalls als Risiko betrachtet, da die Daten evtl. nicht immer datenklassengerecht gespeichert werden können. Dies muss jedoch der Projektverlauf ergeben. Die letzte Risikokategorie stellen die organisatorischen Risiken für das Projekt KONCOM/IT dar. Zu dem frühen Zeitpunkt der ersten Risikoanalyse (ProjektKick-off) waren allein aus dem Projektmanagement diverse, schwerwiegende Risiken zu benennen. So führte die für den Umfang des Projektes relativ kurze Projektlaufzeit dazu, dass von den Betroffenen und den Beteiligten weitere Risiken zusätzlich zu den bereits dargestellten technischen Risiken des Projektes genannt wurden. Der zum Zeitpunkt des Kick-off-Meetings unbekannte Ressourcenbedarf, der fehlende Meilensteinplan, die mangelnde Transparenz der Konsolidierung und der Abstimmungsbedarf zwischen sämtlichen beteiligten Einheiten, vor allem der chronisch überlasteten Produktionseinheiten der EurAmFi Business Services GmbH stellten Risiken dar. Die relativ geringen Erfahrung der EurAmFi AG bezüglich der durchzuführenden Konsolidierungsmaßnahmen dieser Größenordnung war ein Risikofaktor für die Migration (einzelner) Applikationen. Organisatorisches Risiko wurde ebenfalls im Problem der Ausfallzeitenoptimierung der betroffenen Anwendungen inklusive der Einbindung der Kunden EurATel und OSCARBON gesehen. Das Commitment sämtlicher Mitarbeiter aller beteiligten Organisationen musste kritisch hinterfragt werden, zumal KONCOM/IT – wie bereits erwähnt – auch mit den übrigen Projekten und dem Tagesgeschäft der beteiligten Unternehmen und Unternehmenseinheiten in Konkurrenz trat. Diese Risiken wurden vom Projektmanagement bewertet. Anschließend wurden Gegenmaßnahmen definiert und anhand der sich abzeichnenden Kosten entschieden, welchen Risiken mit welchen Gegenmaßnahmen begegnet wird. Das Ergebnis der Analyse wurde mit dem Projektteam abgestimmt.

3.5 Aktivitäten über die komplette Projektlaufzeit

99

Abb. 3.7. Risikobewertung KONCOM/IT – Organisatorische Risiken

Im Projektfortschritt wurden diese Risiken und die Wirksamkeit der Gegenmaßnahmen permanent überwacht. Diese Risikocheckliste wurde für weitere Projekte der EurAmFi AG fortgeschrieben.46 Die im Rahmen von KONCOM/IT erkannten Risikopotenziale von Migrationsprojekten sind in die Betrachtung sämtlicher weiterer Migrationsprojekte in den Häusern EurAmFi AG, EurAmFi Business Services GmbH und EurATel GmbH eingeflossen. Hier konnten vor allem bei der Behandlung des Risikos „Ressour46

Rohrschneider, Uwe: aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.1091.

100

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.8. Risikobewertung Technische Risiken durch KONCOM/IT

cenprobleme aller Organisationseinheiten“ innerhalb der Multiprojektorganisation in der projektübergreifenden Einsatzmittelplanung zwischen sämtlichen beteiligten Unternehmungen und Organisationseinheiten durch ein umfassendes Ressourcen- und Kapazitätsmanagement Synergien erzielt werden, die allen Projekten nutzten.

3.5.2

Projektstrukturierung

Der im Folgenden vorgestellte Projektstrukturplan beschreibt die Projektstruktur von KONCOM/IT. Sämtliche Teilaufgaben enthalten die Arbeitspakete • • • •

Planung Konzeption/Design Implementierung/Test Abschlussarbeiten

3.5 Aktivitäten über die komplette Projektlaufzeit

101

Abb. 3.9. Projektstrukturplan KONCOM/IT

Unter Berücksichtigung der Arbeitspakete handelt es sich bei dem Projektstrukturplan von KONCOM/IT um einen gemischtorientierten PSP, nach Schelle um eine Kombination von Objekt- und Funktionsgliederung.47

3.5.3

Projektorganisation KONCOM/IT

Die Projektorganisation von KONCOM/IT war eine Matrixorganisation mit Mitarbeitern aus 15 beteiligten Unternehmen und 35 Organisationseinheiten der beteiligten Unternehmen: Gesamtprojektleitung im Kollegialprinzip: Kenneth McLallan (EurAmFi AG) mit dem Schwerpunkt Schnittstelle zu internen Prozessen des Auftraggebers, wie zum Beispiel Beschaffung von Hardware Wolfgang Sollbach (WeDo-IT) mit dem Schwerpunkt Anwendungsdesignleitung Hardware und QS Günter Thome (WeDo-IT) mit dem Schwerpunkt Anwendungsdesignleitung Software und Security Teilprojekt Kapazitätsmanagement: Teilprojektleiter Eoin Graham (EurAmFi Business Services), 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team 47

Schelle, Heinz: Projekte zum Erfolg führen, 4. Auflage, München, 2004, S. 123.

102

3 Information Lifecycle Management – Projektorganisation und -struktur

Kapazitätsmanagement, 1 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Application Support, 1 Teilprojekt-Mitarbeiter EurATel. Teilprojekt SAN: Teilprojektleiter Bernd Kania (EurAmFi Business Services), 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Speicher, 2 Mitarbeiter derWeDo-IT,1 Mitarbeiter EurAmFi Business Services Team Backup/Archivierung für Backup/Restore, 1 Teilprojekt-Mitarbeiter EurATel. Teilprojekt Infrastruktur: Teilprojektleiter Greta Islasdottir (EurAmFi AG), 4 Teilprojekt-Mitarbeiter der EurAmFi AG, 2 Teilprojekt-Mitarbeiter der EurAmFi Business Services,1 Teilprojekt-Mitarbeiter EurATel,je 1 Mitarbeiter aus den Unternehmen EMC2 , Hitachi Data Systems, IBM, LSI-Logic, Netzwerker, StorageTek, Hewlett Packard, Sun Microsystems und Netzwerker. Teilprojekt Servermigration: Teilprojektleiter Thea Rhesa-Stahl (EurAmFi Business Services), 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Datenbanken, 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Application Support, 1 Mitarbeiter EurAmFi Business Services Team Backup/Archivierung, 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Storage, 5 TeilprojektMitarbeiter der WeDo-IT, 1 Teilprojekt-Mitarbeiter EurATel. Teilprojekt Produktionssteuerung: Teilprojektleiter Karl Klein (EurAmFi Business Services), 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Produktionssteuerung, 2 Teilprojekt-Mitarbeiter EurAmFi Business Services Team Application Support. Teilprojekt Storage: Teilprojektleiter Katja Griebel (WeDo-IT), 21 TeilprojektMitarbeiter aus Vertrieb, CSL, NWS-Practise, OSS-Practise, Customer Service. Teilprojekt Administration: Teilprojektleiter Günter Thome (WeDo-IT), 5 Teilprojekt-Mitarbeiter der WeDo-IT für Projektcontrolling, Projektoffice, 2 Mitarbeiter Rechtsabteilung EurAmFi AG, 2 Mitarbeiter Controlling EurAmFi AG, 1 Mitarbeiter Controlling EurATel, 1 Mitarbeiter Controlling EurAmFi Business Services. Projektlenkungsausschuss: paritätisch besetzt aus EurAmFi und WeDo-IT. Grafisch lässt sich die Projektorganisation von KONCOM/IT wie in folgender Abbildung darstellen. Innerhalb der Konzernorganisation lässt sich KONCOM/IT wie folgt beschreiben: Auftraggeber für KONCOM/IT war Ludger Eisenard, Chief Information Officer der EurAmFi AG. Dieser war zum damaligen Zeitpunkt dem Technikvorstand der EurAmFi AG Stefano di Ludovico unterstellt. Der Projektlenkungsausschuss für KONCOM/IT, an den beide Kollegialprojektleiter berichten, war paritätisch besetzt aus Mitarbeitern und Geschäftsführung der EurAmFi AG (Ludger Eisenard, Kenneth McLallan) und EurATel (Dimitar Abramson) sowie Mitarbeitern und Vertriebsleitung der WeDo-IT (Herren Ebenstreich, Thome und Sollbach).

3.5 Aktivitäten über die komplette Projektlaufzeit

103

Abb. 3.10. Die Projektorganisation von KONCOM/IT

3.5.4

Phasenmodell und Meilensteine

Das Projekt wurde von Anbeginn mit Microsoft Project 2003 geplant. Ein explizites Phasenmodell wurde nicht erstellt. Von der Projektlogik her wurde KONCOM/IT analog einem Investitionsprojekt aus der IT-Branche in den Phasen • • • •

Planung Design Implementierung Test/Abnahme

geführt. Da seitens der EurAmFi AG eine Phasenmodellierung nicht gefordert wurde, sondern lediglich eine Gruppierung von Tasks in einer Hierarchie, und die Phasenübergänge nur durch Erreichen von Meilenstein-Tasks erfolgen sollte, wurde auch hier kein Phasenmodell des Projektes KONCOM/IT erstellt. Die Meilensteine waren hingegen allein schon aufgrund der Anforderungen an die Konzernbilanzierung der Services der EurAmFi Business Services GmbH nach der EarnedValue Methode (EVM) bereits in dem Statement-of-Work in groben Zügen definiert, das dem Vertrag zugrunde liegt. Danach wird der Earned Value oder der Fertigstellungswert zu einem bestimmten Zeitpunkt (mindestens zum Quartalsende) aus dem Produkt des Ist-Fortschrittsgrades (Fertigstellungsgrad gemäß

Abb. 3.11. Deliverables-Liste (grau unterlegte Positionen sind abgeschlossen)

104 3 Information Lifecycle Management – Projektorganisation und -struktur

3.5 Aktivitäten über die komplette Projektlaufzeit

105

DIN 69901)48 und den geplanten Gesamtkosten ermittelt. Die Betrachtungseinheit für die Konzernbilanzierung ist das „Deliverable“, das je nach Präzisierung des Statement-of-Work entweder das Gesamtprojekt, ein Teilprojekt oder ein Arbeitspaket sein kann. Eine detailliertere Spezifikation erfolgt in der monatlich anzupassenden Deliverables-Liste, die nach meilensteinorientierter Ermittlung des Fertigstellungsgrades aufgebaut ist. Die Abbildung 3.11 zeigt exemplarisch eine Deliverables-Liste für das Projekt KONCOM/IT.

3.5.5

Ablauf- und Terminplanung

Im Rahmen von KONCOM/IT wurde ausgehend von der Projektstrukturierung die Ablauf- und Terminplanung von Beginn an mit MS-Project 2003 durchgeführt. Dies bedeutet, dass auf eine Ablaufplanung mit Hilfe eines Netzplanes verzichtet wurde. Die Ablaufplanung erfolgte in enger Abstimmung mit dem Projektteam. Hier wurde im Rahmen von so genannten Experten-Panels eine Detaillierung der Arbeitspakete des Projektstrukturplanes in einzelne Vorgänge, die Reihenfolge der Abarbeitung der Vorgänge sowie die Abschätzung der erforderlichen Dauer der Vorgänge vorgenommen. Dazu wurden jeweils drei Experten der jeweiligen Fachrichtung unabhängig voneinander befragt. Die Schätzwerte der Experten wurden in einer Panel-Runde präsentiert. Waren deutliche Abweichungen zwischen den einzelnen Schätzwerten festzustellen, so wurden die Experten um eine Präzisierung ihrer Schätzungen gebeten. Dabei konnte erkannt werden, ob die Differenzen aufgrund differierender Auffassungen bzgl. des fachlichen Inhalts der Vorgänge auftraten, was zu einer Aufsplittung von „Sammelvorgängen“ führte. Nach der Panel-Diskussion wurden die Experten um eine nochmalige Schätzung in einer Schätzklausur gebeten.Die dabei erzielten Werte wurden zur Bildung des arithmetischen Mittels herangezogen, das dann als Vorgangsdauer verwendet wurde. Die im Rahmen von KONCOM/IT erkannten Risikopotenziale von Migrationsprojekten sind in die Betrachtung sämtlicher weiterer Migrationsprojekte in den Häusern EurAmFi AG, EurAmFi Business Services GmbH und EurATel GmbH eingeflossen. Hier konnten vor allem bei der Behandlung des Risikos „Ressourcenprobleme aller Organisationseinheiten“ innerhalb der Multiprojektorganisation in der projektübergreifenden Einsatzmittelplanung zwischen sämtlichen beteiligten Unternehmungen und Organisationseinheiten durch ein umfassendes Ressourcen- und Kapazitätsmanagement Synergien erzielt werden, die allen Projekten zugute kamen. Diese aufwendige Methodik zur Ermittlung des Ablaufs und der Vorgangsdauern wurde im Rahmen der Teilaufgaben Projektmanagement und Strukturen und Prozesse durchgeführt. Dieser Aufwand wurde betrieben, da aufgrund der Komplexität des Migrationsvorhabens erhebliche Unsicherheit herrschte, die aufgrund dieses Vorgehens reduziert werden konnte. Die Problematik der Verwendung von MS-Project 2003 lag im Wesentlichen darin, dass die Terminplanung anhand der Gantt-Balkenpläne die Abhängigkeiten 48

Motzel, Erhard: Leistungsbewertung und Projektfortschritt, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S. 690ff.

106

3 Information Lifecycle Management – Projektorganisation und -struktur

zwischen Vorgängen nur schwer erkennbar macht. Dies war jedoch aufgrund der intensiven Einbeziehung der Fachleute ein überschaubares Risiko49. Zur einfacheren Kontrolle der Termineinhaltung wurden Meilensteine definiert, die im Fortgang des Projektes via Meilensteintrendanalyse zur Terminkontrolle verwendet wurden. Auf den Projektplan werden wir in Kapitel 4.1 des Buches noch detailliert eingehen, so dass er hier noch nicht dargestellt wird.

3.5.6

Einsatzmittelplanung

Das EurAmFi-Projektmanagement-Modell bietet nur eingeschränkte Unterstützung zur Einsatzmittelplanung. So wird hier lediglich die Prozesskette dargestellt, wie und wo benötigte Ressourcen beantragt werden können, und wie die Eskalationspfade begangen werden sollen, wenn die Ressourcenzuweisung nicht zeitgerecht erfolgt.Wie der Ressourcen-/Einsatzmittel-Bedarf ermittelt werden soll wird vom EurAmFi-Prozesswerk nicht dargestellt. Dies führt dazu, dass die im Rahmen von Matrixorganisationen immer knappe Ressource Personal seitens des Projektund Teammanagements qualifikationsorientiert den Projekten zugeordnet wird. Hierzu sollte im Hause der EurAmFi AG und aller ihrer Tochtergesellschaften bereits im Jahre 2003 der Microsoft Project Server 2003 eingeführt werden, der diese Aufgabe DV-gestützt durch Einbeziehung einer Qualifikationsdatenbank und mitarbeiterbezogener Kalender unterstützen sollte. Die Einführung verzögerte sich jedoch bis nach dem erfolgreichen Abschluss des Projektes KONCOM/IT aufgrund diverser Irritationen bzgl. der Pflicht zur Information des Betriebsrats und/oder der Unsicherheit sowohl von Mitarbeitern als auch Management, die sich „eigener Kreativität“ durch automatisierte Unterstützung der Einsatzmittelplanung beraubt sahen. Dies führt dazu, dass sich Projektmanager, die sich wie das Projektmanagementteam des KONCOM/ITProjektes in der Situation des Multiprojektmanagements befinden, eigene Werkzeuge zur Einsatzmittel-Bestandsbestimmung und Einsatzmittelplanung schaffen. Der detaillierte Einsatzmittelbedarf wurde anhand der durch die Terminplanung vorgegebenen Ausführungstermine bestimmt (frühest mögliche und spätest zulässige Anfangs- und Endtermine)50 und für die parallel laufenden Projekte qualifikations-/rollenorientiert in der bereits für die Abrechnungsforecasts verwendete Deliverables Liste dargestellt. Dieser Bedarf wurde zur besseren Visualisierung für die Managementkommunikation personalisiert in eine Tabelle als „Planungssoll“ kalendertaggenau kumuliert. Abbildung 3.5.7 zeigt dieses Vorgehen exemplarisch ohne direkten Mitarbeiterbezug. Um bei Zuteilung der Ressourcen sicherzustellen, dass Mitarbeiterplandaten (Urlaub, Training etc.) berücksichtigt werden, wird dieses Planungssoll der Mitarbeiterplanung gegenübergestellt. Die Differenz zwischen Mitarbeiterplanung und Planungssoll ergibt eine Netto-Unterdeckung, die mit Ressourcen der gleichen Qualifikation abgedeckt werden muss. Diese Netto-Unterdeckung erfährt 49 50

Schelle, Heinz, a.a.O., S. 144. Müller-Ettrich, Roswitha: Einsatzmittelmanagement, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S. 586 f.

3.5 Aktivitäten über die komplette Projektlaufzeit

107

noch durch „nicht planbare“ Reduktionen der Ressourcenverfügbarkeit (Krankheit,Umpriorisierungen durch Linienmanagement etc.) eine Steigerung.Aufgrund von Erfahrungen aus vergangenen Projekten kann hier frühzeitig für Ersatz gesorgt werden. Dieses Vorgehen wurde für die Einsatzmittelplanung auf die Mitarbeiter aller der in KONCOM/IT tätigen Unternehmen/Organisationseinheiten übertragen und angewendet. Durch das grobe Zeitraster des Kalendertages (auch Vorgänge, die lediglich eine Dauer von 1 Stunde haben, werden hier mit einer Ressourcenauslastung von 1 Tag erfasst) wurden hier die nötigen Puffer zur Einsatzmittelglättung„systemimmanent“ geschaffen.Aufgrund dieses groben Rasters war es möglich, die benötigten Ressourcen über die Vielzahl der Projekte zu „glätten“. Hieraus ergaben sich die Synergieeffekte in der Ressourcenplanung durch die Mehrprojektsituation.

3.5.7

Kostenplanung/Finanzmittelplanung

Kostenplanung wird seitens der EurAmFi AG lediglich rudimentär und absolut nicht projektorientiert betrieben. Dennoch wurde für KONCOM/IT ein Kostenziel von maximal EUR 1.2 Millionen Euro gesetzt. Um die Zielerreichung planen und zumindest rudimentär überwachen zu können, wurde ein grundlegender Aufwandsplan (vgl. Abbildung 3.13) erstellt. Dieser Aufwandsplan aggregiert die Aufwendungen der beteiligten Unternehmen und Organisationseinheiten in Personentagen. Die pro Betrachtungseinheit auftretenden geplanten Kosten ergeben sich als Produkt aus dem Aufwand pro Betrachtungseinheit und dem vereinfachenden Standard-Tagessatz für Dienstleistungen der EurAmFi Business Services von 640,00 Euro/Tag. Dies ist der Standardtagessatz, zu dem die EurAmFi AG von der EurAmFi Business Services GmbH Leistungen einkauft. Der Aufwandsplan der Abbildung 3.14 ist exemplarisch. Er betrachtet lediglich die Monate Juli bis Oktober 200x. Im Zeitraum Januar bis Juni fanden die Compliance Assessments, die Erstellung des Pflichtenheftes, der Ausschreibungsunterlagen und der Entscheidungstabelle sowie die Konzeptionierung von Migrationsverfahren und Konfigurationsrichtlinien und die Zuordnung der Daten zu den Datenklassen statt. In den Monaten nach Oktober 200x wurden die Implementierungsarbeiten der neuen Hardware, der Software und der Prozesse durchgeführt. Zeitlich versetzt erfolgte parallel dazu „Zug-um-Zug“ die Migration der Server und der Daten auf die Neuumgebung. Aggregieren wir die Summe der veranschlagten Personentage allein anhand dieser 4 dargestellten Monate (950 Personentage) und interpoliert diesen Aufwand über die komplette Projektlaufzeit, so mag man sich fragen, wie das Projektbudget von 1,2 Millionen Euro gehalten werden soll. Dieses Budget summiert sich allein über die direkt dem Projekt zurechenbaren externen Kosten. Die im Projekt KONCOM/IT eingesetzten Mitarbeiter der Herstellerfirmen sowie die Mitarbeiter von EurATel GmbH und EurAmFi AG werden nicht dem Projektbudget belastet, da sie bereits über die bestehenden Wartungs- und Supportverträge abgerechnet werden (Hersteller) oder von der EurAmFi AG als „Eh-da-Kosten“ getragen werden (Mitarbeiter EurAmFi AG und EurATel GmbH). Die Mitarbeiter der EurAmFi Business

108

3 Information Lifecycle Management – Projektorganisation und -struktur

Services GmbH wurden lediglich mit einem halben Tagessatz von 320,00 Euro/Tag dem Projekt zugerechnet, da die im Projekt KONCOM/IT erarbeiteten Verfahren und Methoden zur Automatisierung der Projektabläufe bereits zur Projektlaufzeit Betriebskostensenkungen bewirkten, die über den reduzierten Tagessatz dem Projekt gutgeschrieben wurden. Weiter wurde der Aufwand des Vertriebs der WeDo-IT nicht vergütet, daher wird auch dieser für das Projekt kostenfrei erbracht. Der Aufwand des Projektmanagements wurde zur Hälfte auf den Projektleiter der EurAmFi AG berechnet, der wie sämtliche Mitarbeiter der EurAmFi AG nicht dem Projektbudget belastet wurde (siehe Abbildung 3.14). Zur Ermittlung der Ist-Kosten sollte das bei der EurAmFi AG eingesetzte PrAcSSystem (Project Accounting System) die benötigten Informationen in Form von Reports liefern. Der in Abbildung 3.15 dargestellte Report, bezogen auf das vierte Quartal 200x, zeigt jedoch die Problematik des PrAcS -Systems auf. Eine vorgangsbezogene Aufschlüsselung des angefallenen Aufwandes ist vorgesehen, für den Projektmanager jedoch nicht verfügbar. Aufwand kann von einer Vielzahl von Mitarbeitern auf ein Projekt verbucht werden, selbst von Mitarbeitern, die in dem entsprechenden Betrachtungszeitraum definitiv nicht für das Projekt tätig waren. Zusätzlich werden Rechenfehler nicht abgefangen. So hat im obigen Report eine Mitarbeiterin (Frau Rhesa-Stahl) 980,5 Stunden in den zwölf Wochen des 4. Quartals 200x für KONCOM/IT geleistet. Dies entspräche einer Wochenstundenzahl von 81,66 Stunden.Als Grundlage für eine Aufwands- und IstKosten-Ermittlung ist dieses Werkzeug nicht geeignet. So konnte im Rahmen von KONCOM/IT die Kostenkontrolle lediglich über die tatsächlichen Vorgangsdauern gewonnen werden. Die Finanzmittelplanung erfolgt bei der EurAmFi AG nicht projektbezogen, sondern programmorientiert vom Program-Management. Daher kann aus Projektsicht zur Finanzmittelplanung keine Aussage getroffen werden.

3.5.8

Berichtswesen, Statusgespräche, Projektinformationswesen

Mit dem eigentlichen Beginn des Projektes (Annahme des Angebotes, Kick-offMeeting) wurde ein gemeinsamer Projektleitfaden entwickelt und abgestimmt, in dem die Erstellung regelmäßiger (wöchentlicher) Statusberichte beschlossen wurde, die den aktuellen Projektverlauf zusammenfassen und bewerten sollten. In diesen Statusberichten wurde das Management der EurAmFi AG, EurATel GmbH, EurAmFi Business Services GmbH und der WeDo-IT sowie der Lenkungsausschuss über folgende Punkte informiert: • • • • • •

Beschreibung der laufenden Aktivitäten aktueller Projektstand, Fertigstellungswert gegebenenfalls Abweichungen und Probleme Risiken und Maßnahmen zu ihrer Behebung Termine Verantwortlichkeiten

109

Abb. 3.12. Mitarbeiterplanung exemplarisch

3.5 Aktivitäten über die komplette Projektlaufzeit

110

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.13. Aufwandsplanung KONCOM/IT (exemplarisch)

Die Abstimmung dieses wöchentlichen Statusberichtes war ebenfalls Gegenstand des gemeinsamen Projektmanagement-Meetings. Die Abbildungen 3.16 und 3.17 stellen einen exemplarischen Statusbericht des KONCOM/IT-Projektes dar. Wöchentlich fand mit dem kompletten Team ein Projektmeeting statt. Dieses war mit einer Standardagenda versehen und diente der Information des gesamten Projektteams (vgl. Abbildung 3.17). Das Protokoll des Projektmeetings wurde dem Team zur Verfügung gestellt (vgl. exemplarisch Abbildungen 3.18 und 3.19). Die Statusinformationen der einzelnen Teilprojekte waren geprägt vom projektübergreifenden Austausch von Informationen. Hier konnte wiederum aufgrund des Informationsflusses sichergestellt werden, dass projektübergreifend die Aktivitäten der eingesetzten Ressourcen synchronisiert wurden. Unter anderem sorgte dies für eine nivellierte Qualität der Ressourcenauslastung über sämtliche

3.5 Aktivitäten über die komplette Projektlaufzeit

Abb. 3.14. KONCOM/IT-Kostenplan (exemplarisch)

Abb. 3.15. Ist-Kosten gemäß PrAcS-System

111

112

3 Information Lifecycle Management – Projektorganisation und -struktur

Parallelprojekte bei der EurAmFi AG, der EurATel GmbH und der EurAmFi Business Services GmbH.

3.5.9

Projektsteuerung (Arbeitsweise und Hilfsmittel zur Termin-, Leistungs- und Kostensteuerung)

In der MS-Project-Projektplanung wurde der Basisprojektplan seitens des Projektmanagements gepflegt und alle notwendigen Änderungen durch die vereinbarten Change Requests eingestellt. Der Projektplan bestand aus über 400 Tasks sowie über 40 Teilprojektplänen für die serverbezogenen Migrationsaktivitäten mit jeweils über 40 Tasks (siehe Kapitel 4.1). Zur Projektsteuerung wurden wöchentliche Statusmeetings mit sämtlichen Teilprojekten sowie das Berichtswesen herangezogen. In den montäglichen Projektmanagementmeetings wurde der Projektfortschritt abgeglichen und die Projektplanung aktualisiert. Hierzu wurde der PlanFortschrittsgrad dem Fertigstellungsgrad als Verhältnis der zu einem gegebenen Zeitpunkt erbrachten Leistung zur Gesamtleistung der Vorgänge/Arbeitspakete/ Projektphasen gegenübergestellt. Dazu wurden wöchentlich auf Basis eines jeweils definierten Stichtages die erforderlichen Zeiten bzw. der Aufwand und die damit erzielten Ergebnisse eines Vorgangs/Arbeitspaketes/einer Projektphase in Form des Fertigstellungswertes ermittelt und im Projektstatusbericht dem Lenkungsausschuss mitgeteilt. Zur Vorbereitung des Statusberichts fanden innerhalb des Teams zweimal wöchentlich Feedbackrunden zum gegenwärtigen Stand der Vorgänge/Arbeitspakete statt. Anhand der Ergebnisse dieser Feedbackrunden konnte falls erforderlich steuernd eingegriffen werden, indem zusätzliche Ressourcen für die Bearbeitung der Arbeitspakete angefordert wurden, Changes gemäß dem im Projektleitfaden und Statement of Work definierten Change-Prozess angefordert und durchgeführt wurden. Zusätzlich zu der Steuerung der Vorgänge über diese Feedbackrunden wurde eine Aktionspunkteliste geführt, die bei Auftreten von Verzögerungen oder sonstigen Projektproblemen die Aktivitäten für die Teammitglieder anstelle des Projektplanes visualisierte. Die folgende Abbildung 3.5.8 zeigt eine solche Aktionspunkteliste exemplarisch.

3.5.10

Projektkultur, Teambildung und Teamarbeit

In der bisherigen Darstellung der Projektarbeit in KONCOM/IT wurde bereits vielfach über die Teamarbeit im Rahmen des Projektes berichtet. Im Projekt-Kickoff-Workshop wählte das Projektteam das Logo „KONCOM/IT“ für das Projekt „Konsolidierung und Compliance der IT der EurAmFi AG“. Teambildende Maßnahmen waren über die komplette Projektlaufzeit die wöchentlichen Projektmeetings, die durch gelegentliche gemeinsame Mittagessen aufgelockert wurden. Das Team fand auf dem Onsite-Webserver eine KONCOM/IT- Präsenz, die für die Präsentation des Projektes, jedoch auch für den Austausch mit anderen Projekten genutzt werden konnte. Meetings der Teilprojekte und Koordinationsgespräche der Fachleute waren nicht an die strenge Lokalität des Projektstandorts gebunden. Bei Information des Projektmanagements wurden solche Veranstaltungen auch an

3.5 Aktivitäten über die komplette Projektlaufzeit

113

„angenehmeren“ Orten gefördert und finanziert, um durch eine Trennung vom Arbeitsplatz die Unterbrechungen durch das Tagesgeschäft zu minimieren. Weiter trafen sich die Teammitglieder auch in ihrer Freizeit zu gemeinsamen Veranstaltungen. Der Eingriff des Projektmanagements hinsichtlich einer zusätzlichen Einführung teambildender Maßnahmen war nicht erforderlich. Die schon durch die konstruktive Erfahrung des Kick-off-Workshops geförderte Teambildung setzte sich insbesondere deshalb durch, weil sich jedes einzelne Teammitglied aufgrund des oben beschriebenen Projektinformationswesens gleich informiert empfand. Außerdem wurde der persönliche Nutzen des projektübergreifenden Austauschs geschätzt, der zu konstruktiven Verbesserungsvorschlägen hinsichtlich des Projektablaufs aus dem Team heraus führte. Hier koordinierten die Teammitglieder ihre projektübergreifenden Aktivitäten „beim Kaffee“ oder „bei einem Bier nach Feierabend“ und brachten diese Änderungsvorschläge aktiv ins Projekt ein. Das Projektmanagement konnte nur gut daran tun, diese Erkenntnisse zu berücksichtigen. Die projektübergreifende Kommunikation der Teammitglieder führte dazu, dass seitens des Projektmanagements ein stetiger Austausch mit den Projektmanagern der Parallelprojekte gesucht wurde. Hierfür wurde – aktiv unterstützt vom Projektmanagement – das ProjektmanagementFrühstück an jedem Montagmorgen eingeführt. Dieses diente insbesondere dem Austausch der Projektleiter untereinander und förderte insbesondere die Synergien im Gesamtumfeld des EurAmFi-Konzerns.

114

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.16. EurAmFi-Statusbericht für KONCOM/IT (Seite 1)

3.5 Aktivitäten über die komplette Projektlaufzeit

Abb. 3.17. Standardagenda Projektmeeting KONCOM/IT

115

116

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.18. KONCOM/IT-Protokoll eines Projektmeetings (1)

3.5 Aktivitäten über die komplette Projektlaufzeit

Abb. 3.19. KONCOM/IT-Protokoll eines Projektmeetings (2)

117

3 Information Lifecycle Management – Projektorganisation und -struktur

Abb. 3.20. Aktionspunkteliste KONCOM/IT (exemplarisch)

118

4 Information Lifecycle Management Projekt

4.1

Der Projektplan

Im Rahmen des KONCOM/IT-Kick-off-Meetings wurde der Basisprojektplan des Projektes mit seinen Teilprojekten, Arbeitspaketen und Vorgängen erarbeitet. Der Basisprojektplan auf Basis des willkürlichen Datums 2003 kann als Muster für Konsolidierungs- und Compliance-Projekte verwendet werden. Dieser wurde um eine manuelle Inventur für die Systeme ergänzt, die aufgrund rechtlicher und physikalischer Gegebenheiten nicht automatisiert inventarisiert werden konnten. Die Informationen der Inventur wurden mit den existierenden Dokumentationen abgeglichen. Auf Grundlage dieser Inventarisierung konnte die Kapazitätsplanung für die Neuumgebung durchgeführt werden. Die Performanceplanung für die Neuumgebung basierte auf der Inventur, dem ermittelten Laufzeitverhalten der Altumgebung sowie der Simulation des Laufzeitverhaltens für die Neuumgebung. Bereits in dieser frühen Phase wurde als Voraussetzung für die anzustoßende Ausschreibung eine Planung der Distribution der Anwendungen auf Datenklassen der Neuumgebung sowie die Backup-/Restore- Planung durchgeführt. Der erste Teil der Arbeitspakete zur Ausschreibung diente der Beschreibung der Zielkonfiguration in der Neuumgebung. Hier wurden das Speicher- und ITSicherheitskonzept der Neuumgebung definiert. Danach wurden diese mit den existierenden SLAs abgeglichen und Grundlagen für die Entwicklung zukünftiger SLAs entwickelt. Der zweite Teil der Arbeitspakete zur Ausschreibung diente der Entwicklung der Ausschreibungsunterlagen, hier insbesondere der Entwicklung des Pflichtenhefts und einer Entscheidungsmatrix, die die angeforderten Herstellerangebote homogenisieren und dadurch bewertbar machen sollte. Ferner wurde hier als Bestandteil der Ausschreibungsunterlagen ein Testkonzept entwickelt, durch das jeder bietende Hersteller in Kenntnis gesetzt wurde,wie die Erfüllung der Anforderungen des Pflichtenhefts während der Implementierung getestet werden sollte. Der dritte Teil der Arbeitspakete zur Ausschreibung diente der tatsächlichen Durchführung der Ausschreibung. Eine zuvor definierte Liste von Anbietern erhielt die Aufforderung zur Abgabe eines Angebotes. Den Herstellern wurden fixe Termine für eine Frage- und Antwortstunde zugeteilt, um herstellerseitig aufgetretene Fragen zu den Ausschreibungsunterlagen und -anforderungen zu klären. Die Ergebnisse sämtlicher Hersteller-Q&A wurden projektseitig protokolliert und sämtlichen Anbietern zur Verfügung gestellt. Dadurch sollte diesen für die Be-

120

4 Information Lifecycle Management Projekt

Abb. 4.1. KONCOM/IT-Projektplan mit den definierten Arbeitspaketen und Vorgängen für das Projektmanagement

4.1 Der Projektplan

Abb. 4.2. KONCOM/IT-Projektplan – Grundlegende Arbeitspakete und Vorgänge (1)

121

122

4 Information Lifecycle Management Projekt

Abb. 4.3. KONCOM/IT-Projektplan – Grundlegende Arbeitspakete und Vorgänge (2)

4.1 Der Projektplan

123

arbeitung der Ausschreibung der gleiche Kenntnisstand geboten werden. Für die Auswertung der Ausschreibung wurde die Entscheidungsmatrix einem nochmaligen Review unterzogen, um sicherzustellen, dass in dieser auch technologische Weiterentwicklungen korrekt bewertet werden konnten. Anhand dieser Entscheidungsmatrix wurden die drei sowohl technisch als auch ökonomisch interessantesten Angebote ermittelt. Die drei Hersteller wurden zu einer finalen Vertragsverhandlung eingeladen. Der Anbieter mit dem besten Preis-Leistungsverhältnis sollte den Zuschlag erhalten und wurde anschließend von der EurAmFi AG mit der Lieferung der angebotenen Hard-, Software und Services beauftragt. In der Planungs- und Konzeptionsphase des Teilprojektes SAN wurde die Bereitstellung der passiven Infrastruktur und der Stellplätze im Rack sowie die SANErweiterung für die Rechenzentren 1 und 2 geplant und konzipiert. Anschließend wurde in der Implementierungs- und Testphase des Teilprojektes SAN in den beiden Rechenzentren die passive und die aktive Infrastruktur bereitgestellt und das Personal in die neuen Systeme und das Managementsystem eingewiesen. Abschließend wurde die Neuumgebung dokumentiert. Das Delivery Management zum Kunden OS-CARBON wurde für die Prüfung der vertraglichen Relevanz der Änderungen durch die Neuumgebung, die Einhaltung der SLAs durch die Neuumgebung sowie für ein aktives Projektmanagement hin zum Kunden OS-CARBON eingebunden. Im Teilprojekt Infrastruktur (und Netzwerke) wurden der Standort und die Infrastruktur des Speicherpools sowie dessen Versorgung mit Sekundär- (Strom,Wasser, Kühlung) und Tertiärtechniken (Brandschutz, Zutritts- und Gebäudeschutz, Raumtechnik etc.) geplant.Weiter wurde das 2-GbitDWDM-Netzwerk zwischen den beiden Rechenzentren geplant. Das Teilprojekt Servermigration zeichnete über die komplette Projektlaufzeit verantwortlich für die Beauftragung und Koordination von Fremdunternehmen (z. B. Transportunternehmen für Systemumzüge) und Außenstellen (Pförtner etc.) zur Migration der Serversysteme. Es war verantwortlich für die Bereitstellung der Infrastrukturund Netzwerkkomponenten (RZ-Primärtechnik) und die Durchführung der Serverumzüge. Letztendlich lag die Anpassung der Dokumentation und der Raumplanung nach jedem erfolgten Umzug in seiner Verantwortung.Während der Phase der Umsetzung der Server- und Speichermigrationen wurde der Kunde OSCARBON permanent in die Aktivitäten eingebunden, indem jede Aktion gegen die bestehenden SLAs geprüft wurde, aktives Projektmarketing gegenüber dem Kunden betrieben wurde und nach Abschluss der Server- und Speichermigrationen ein Abschlussbericht für die OS-CARBON erzeugt wurde. Die serverbezogene Migration involvierte die Teilprojekte Servermigration, SAN, Speicher, Infrastruktur und Produktionssteuerung. In der Planungsphase für Serveraktivitäten wurde die Notwendigkeit von Serverumzügen geprüft, es wurden proaktiv Host-BusAdapter eingebaut und das anzuwendende Migrations- und Rückfallverfahren je Server ausgewählt. In der Konzeptions- und Designphase wurden I/O-Subsystem, Plattenlayout und zusätzlich benötigte Hardwarekomponenten designt und konzeptioniert. Es wurde entschieden, auf welche Tape Libraries gesichert wird, ob mit BCVs, Clones oder Snapshots gearbeitet wird. Das Backup über SAN wurde konzipiert. In der Migrationsphase wurden die entwickelten Konzepte je Server

124

4 Information Lifecycle Management Projekt

Abb. 4.4. KONCOM/IT-Projektplan für die Ausschreibung (1)

4.1 Der Projektplan

Abb. 4.5. KONCOM/IT-Projektplan für die Ausschreibung (2)

125

126

4 Information Lifecycle Management Projekt

und je Servercluster durchgeführt und im Change Management (CM-) Verfahren die Involvierung der Kunden, insbesondere von OS-CARBON, bei der Planung der Auszeiten (Downtimeplanung) betrieben. Zum Abschluss der Servermigration wurden Dokumentationstool und Serverdokumentation aktualisiert. Anhand applikationsspezifischer Arbeitspakete wurden in der Planungsphase Migrationsverfahren und Rückfalllösung ausgewählt, Einflüsse auf das Release Management (RM) geprüft und entschieden, den jeweiligen Softwarelieferanten (im Wesentlichen SAP und Oracle) zu involvieren. Nach Durchführung der Migration wurde eine Qualitätssicherung nach SOW betrieben, d. h. es erfolgte ein Test auf Funktionsfähigkeit und Performance. Auch hier stand die Aktualisierung der Anwendungsdokumentation (Verfahrenshandbuch) am Ende der Arbeitspakete. Speicherseitig wurden ebenfalls das Migrationsverfahren und die Rückfalllösung bestimmt sowie die zu migrierenden Server- und Clusterserver-Systeme den Fibre Channel (FC-) Direktoren/Adaptern gemäß Konfigurationsrichtlinien zugeteilt. Während der Migration wurde die Speichermanagementumgebung aktualisiert und permanent die Performance der Speichersysteme und der Verbindung zum Remote Mirroring via DWDM (DWDM = Dense Wavelength Division Multiplexing) erfasst. Letztlich wurde über das Dokumentationstool ebenfalls die Speichersystemdokumentation aktualisiert. Sämtliche EinzelServer- und Clusterserver-Migrationen wurden als eigenständige Teilprojekte geplant, deren Teilprojektpläne vom Teilprojekt Servermigration (Frau Rhesa-Stahl) erstellt und gepflegt und von der Gesamtprojektleitung (Herr McLallan, Herr Sollbach) in den KONCOM/IT-Basisplan eingefügt wurden. Die Abbildungen 4.3.5.2 bis 4.50 zeigen exemplarisch den Teilprojektplan der Servermigration „KW20KW49-Servermigration-Copy“. Es werden hier nicht sämtliche ServermigrationsTeilprojekte komplett dargestellt.Allen Servermigrations-Teilprojekten ist die gleiche Vorgehensweise gemein, je nach Aufwand unterscheiden sich lediglich die Dauern der einzelnen Vorgänge. Im Arbeitspaket „Vorbereitende Arbeiten“ wird das Delivery Management eingebunden, die SAN-Verkabelung vorgenommen und das Konfigurationsgespräch zwischen dem jeweiligen Speichersystemhersteller und dem Delivery Management geführt. Danach wird die Auszeit gemäß ITILbasiertem Change Management (CM) geplant.Dazu werden die Produktionssteuerung und das Datenbankteam der EurAmFi-Business-Services-Produktion eingebunden. Der Servercluster es02 steuert hier das Vertragsmanagement der EurATel GmbH mit deren Mobilfunkpartner T-Mobile. Daher wird T-Mobile ebenso wie auch die Lieferanten in den Change Request und dessen Prozessing eingebunden. Die Migration wird durch zusätzlichen Einbau von FC-HBAs und den folgenden Online-Migration durch weitestmögliches serverbasiertes Kopieren durchgeführt. Die Arbeitspakete zur Durchführung der Auszeit für den FC-HBA-Einbau, den Anschluss des Servers an das SAN der EurAmFi AG und die darauf folgende OnlineMigration der Datenbanken, Dateisysteme und Betriebssystemdateien enthalten die Vorgänge, die im Change Management (CM-) Prozess durch das Change Verfahren genehmigt und im Change Request (CR) abgedeckt sein müssen. Mit der Freigabe des Teilprojektes muss die Dokumentation dahingehend angepasst werden, dass die jeweils frei gewordenen Kapazitäten berücksichtigt werden.

4.1 Der Projektplan

Abb. 4.6. KONCOM/IT-Projektplan für das Teilprojekt SAN (1)

127

128

4 Information Lifecycle Management Projekt

Abb. 4.7. KONCOM/IT-Projektplan für das Teilprojekt SAN (2)

4.1 Der Projektplan

Abb. 4.8. KONCOM/IT-Projektplan für die Einbindung des Delivery Managements

129

130

4 Information Lifecycle Management Projekt

Abb. 4.9. KONCOM/IT-Projektplan für Infrastruktur und Serverumzüge

4.1 Der Projektplan

Abb. 4.10. KONCOM/IT-Projektplan für die Integration der OS-CARBON

131

132

4 Information Lifecycle Management Projekt

Abb. 4.11. KONCOM/IT-Projektplan der Servermigration (1)

4.1 Der Projektplan

Abb. 4.12. KONCOM/IT-Projektplan der Servermigration (2)

133

134

4 Information Lifecycle Management Projekt

Abb. 4.13. KONCOM/IT-Projektplan der Servermigration (3)

4.1 Der Projektplan

Abb. 4.14. KONCOM/IT-Projektplan der Servermigration (4)

135

136

4 Information Lifecycle Management Projekt

Abb. 4.15. KONCOM/IT-Projektplan für Teilprojekt Servermigration es02 (1)

4.1 Der Projektplan

Abb. 4.16. KONCOM/IT-Projektplan für Teilprojekt Servermigration es02 (2)

137

138

4 Information Lifecycle Management Projekt

Abb. 4.17. KONCOM/IT-Projektplan für Teilprojekt Servermigration es02 (3)

4.1 Der Projektplan

139

Abb. 4.18. KONCOM/IT-Projektplan für Compliance Tests, Review und Projektabschluss

140

4 Information Lifecycle Management Projekt

Mit Anpassung der Dokumentation und Freigabe der Kapazitäten ist das jeweilige Server- und Clusterserver-Migrations-Teilprojekt abgeschlossen. Nach Abschluss sämtlicher Migrationen wurde durch das interne Controlling der EurAmFi AG, der EurAmFi Business Services GmbH und der EurATel GmbH die Erfüllung der Compliance-Anforderungen überprüft.Für eventuelle Anpassungen nach der Prüfung wurde ein Vorgang zur Durchführung von Anpassungen eingeplant. Nach einem erneuten Review konnte KONCOM/IT beendet werden.

4.2

Die erarbeiteten Grundlagen

Im Wesentlichen wurden im KONCOM/IT-Projekt die Grundlagen für die spätere Migration der Anwendungen auf die Neuumgebung, die Konfigurationsrichtlinien für die Neuumgebung sowie Dokumentenformate für die Archivierung von MailDokumenten erstellt. Zudem wurden nochmals die IT-Sicherheitsanforderungen für die EurAmFi-Konzernanwendungen definiert. Zur Darstellung der Dokumentenformate für die Archivierung von E-MailDokumenten verweisen wir hier auf die Ausführungen in Band 1 „Grundlagen und Modelle des Information Lifecycle Management“. Dort haben wir bei der Beschreibung der Schlüsselfaktoren Datenklassifizierung und IT-Sicherheit (generell auch als Security bezeichnet) detailliert dazu Stellung bezogen, in welchem Format dokumentenecht zu archivierende Dokumente gespeichert werden müssen. Den IT-Sicherheitsanforderungen ist in diesem Band ein eigenes Kapitel gewidmet, da sie einen der wesentlichen Schlüsselfaktoren zur ILM Implementierung darstellen. Eine detaillierte Dokumentation dieser Anforderungen im beschrieben Projekt KONCOM/IT, dem nur auf Teilprojektebene reale Projekte zugrund liegen, hätte einen stark gekünstelten Charakter aufgewiesen. Aufgrund der sehr unterschiedlichen unternehmens-, branchenspezifischen und nationalen ITSicherheitsausprägungen, die sich im Extremfall in Teilbereichen auch gegenseitig ausschließen können, wurde im vorliegenden zweiten Band auf eine gesonderte Darstellung der einschlägigen Sachverhalte verzichten. Dem interessierten Leser kann an dieser Stelle deshalb nur Band 1 empfohlen werden.

4.2.1

Generelle Migrationsverfahren

Basis der Migration bilden entweder die in ITILv2 und aktuell ITILv3 definierten Serviceprozsee. Wenn Hardware- und Softwareinfrastruktur die zur Erfüllung ihrer Strategien der Bewahrungsphase benötigten Systemkomponenten bereitstellen, so muss hier vor allem die Kenntnis der Geschäftsprozesse die Migration zumindest automatisiert initiieren. Die Prozesskette des ITIL Service-Management der vorangehenden Phasen wird weiter genutzt. Das Change Management muss dafür Sorge tragen, dass geplante Änderungen in der Systemumgebung nicht zu Störungen, unerwarteten Ausfallzeitenoder gar zu einem Datenverlust führen. Das Problem Management muss die Fehlerhäufigkeit überwachen, die Schwachstellen ermitteln und diese über den Change Management (CM-) Prozess beseitigen. Re-

4.2 Die erarbeiteten Grundlagen

141

lease Management, Business Continuity Management und Configuration Management sind ebenfalls von zentraler Bedeutung für die prozessuale Kompetenz in der Bewahrungsphase. Letztlich sollten die Anforderungen der Kernprozesse an die IT in der Migrationsphase bekannt und die Erfüllung der beschriebenen Anforderungen auch während der Migration strikt überwacht werden.

4.2.2

Generelle Migrationsverfahren

Die für die Migration verwendeten Migrationsverfahren wurden gemeinsam von den Teilprojekten Servermigration und Speicher erarbeitet und als Abschlussdokument in einer projektweiten Präsentation dargestellt. Diese Präsentation zeigen die Abbildungen 4.19 bis 4.26. Von den Teilprojekten wurden in Form von drei Kategorien die benötigten Migrationsverfahren entwickelt und in ihren Zeitbedarf, den bestehenden Risiken und den Ausfallzeitbedarf bewertet: • Speicherbasierende Migrationsverfahren • Hostbasierende Migrationsverfahren • Migration über Springersysteme. Die speicherbasierenden Migrationsverfahren wurden zwar entwickelt und beschrieben, konnten für KONCOM/IT jedoch aufgrund der extrem heterogenen Altsystemlandschaft bestehend aus Speichersystemen der Hersteller EMC2, HDS, LSI, HP und StorageTek nur als Konzept verwendet werden, da zum Zeitpunkt des Starts der Migration (SMI-S Standard und SNIA war noch nicht weit genug definiert und implementiert) meist keine 100-prozentige Kompatibilität vorlag. Die Migration über Springersysteme wurde ebenfalls beschrieben, im Projekt jedoch aufgrund des immensen Personalaufwandes und bestehenden hohen Fehlerrisikos nicht verwendet.Die hostbasierten Migrationsverfahren wurden von KONCOM/IT durchgängig für sämtliche Migrationen verwendet. Dennoch wurden außerhalb KONCOM/IT alle im Projekt erarbeiteten Verfahren in homogenen Umgebungen bei kleineren Migrationsprojekten im EurAmFi-Konzern erfolgreich eingesetzt, so dass diese Grundlagenarbeit der EurAmFi AG einen Standardkatalog von Verfahren für zukünftige Migrationen lieferte.

142

4

Information Lifecycle Management Projekt

Abb. 4.19. KONCOM/IT-Migrationsverfahrenskategorien

4.2

Die erarbeiteten Grundlagen

Abb. 4.20. KONCOM/IT-Speicherbasierende Migrationsverfahren (1)

143

144

4

Information Lifecycle Management Projekt

Abb. 4.21. KONCOM/IT-Speicherbasierende Migrationsverfahren (2)

4.2

Die erarbeiteten Grundlagen

Abb. 4.22. KONCOM/IT-Speicherbasierende Migrationsverfahren (3)

145

146

4

Information Lifecycle Management Projekt

Abb. 4.23. KONCOM/IT-Speicherbasierende Migrationsverfahren (4)

4.2

Die erarbeiteten Grundlagen

Abb. 4.24. KONCOM/IT-Hostbasierende Migrationsverfahren (1)

147

148

4

Information Lifecycle Management Projekt

Abb. 4.25. KONCOM/IT-Hostbasierende Migrationsverfahren (2)

4.2

Die erarbeiteten Grundlagen

Abb. 4.26. KONCOM/IT -Migration durch Einsatz von Springersystemen

149

150

4 Information Lifecycle Management Projekt

4.3 Vorbereitung und Durchführung der Ausschreibung 4.3.1

Speicherkonzept und Technologieauswahl51

Klassisch stehen bei der Anbindung externen Speichers heute drei Realisierungsmöglichkeiten in Konkurrenz. Dabei handelt es sich um die Möglichkeiten: • Anschluss externer Plattenkapazitäten über iSCSI oder FCIP • Anschluss externer Plattenkapazitäten über Network Attached Storage (NAS) • Anschluss von Speichersystemen über Storage Area Networks (SAN) Für ein Konsolidierungsprojekt der Größenordnung von KONCOM/IT wurde die Variante iSCSI/FCIP ausgeschlossen. Beide Verfahren waren zum Startzeitpunkt des KONCOM/IT-Projektes noch nicht lange verfügbar, da beide Verfahren noch nicht über die SNIA Schnittstelle Bluefin/SMI-S standardisiert und auch seitens der SNIA nur vage in der Roadmap aufgeführt waren. Daher wurden von der EurAmFi AG für Konzernlösungen lediglich Plattenkapazitäten über NAS oder SAN vorgegeben. Diese beiden Varianten werden im Folgenden kurz beschrieben und bewertet. 4.3.1.1 Anbindung von Plattenkapazitäten über Network Attached Storage (NAS) 4.3.1.1.1 Kurzdarstellung Anwendungsdaten und die mit diesen operierenden Diensten werden auf einer Vielzahl von Servern gespeichert und den Client-Rechnern über ein Netzwerk zur Verfügung gestellt. Da deren Verwaltung, Administration und Sicherung stets lokal durchgeführt werden muss, bedeutet dies einen hohen personellen Aufwand, verbunden mit hohen Kosten. Ein Network Attached Storage (NAS) stellt eine Konsolidierung all dieser Services dar. Fileserver machen bei NAS Dateien und Dateisysteme über IP-Netzwerke verfügbar. Dabei wird auf zentralisierte Speichersysteme zugegriffen. Die Fileserver bieten effizientes Daten-Sharing zu deutlich reduziertenVerwaltungskosten, da die Zentralisierung der Datenhaltung zu einer zentralen Administration genutzt werden kann. Die Clients und die Applikationsserver greifen über unterschiedliche Netzwerkmedien und Netzwerkprotokolle auf die in den Speichersystemen gespeicherten Informationen zu. So werden beispielsweise NFS- und CIFSProtokolle unterstützt, die sowohl Unix-Servern über NFS als auch Microsoft Windows NT/Windows 2000/Windows 2003-Servern über CIFS/SMB den simultanen Zugriff auf die Dateien ermöglichen. 51

Die hier verwendete Kurzbeschreibung der zur Wahl stehenden Technologien diente rein der Entscheidungsfindung und der Gestaltung des Pflichtenheftes für die Ausschreibung. Für eine detaillierte Beschreibung der Technologien vgl. die entsprechende Sekundärliteratur, bspw. Sollbach, Wolfgang: Storage Area Networks/Network Attached Storage – Hohe Datenverfügbarkeit durch Speichernetzwerke, München, 2001.

4.3 Vorbereitung und Durchführung der Ausschreibung

151

4.3.1.1.2 Vorteile von über NAS angeschlossenen Speichermedien Die wesentlichen Vorteile einer NAS-basierten Speicherkonzeption lassen sich wie folgt beschreiben: • Hochverfügbarkeit und Ausschluss eines „Single Point-of-Failure“ werden durch komplett redundante Konfigurationen ermöglicht. • Ein zentralisiertes, serverloses Backup und Restore ist möglich. • NAS ermöglicht geringe Total Cost-of-Ownership (TCO) durch massive Reduzierung des Verwaltungs- und Administrationsaufwandes aufgrund zentraler Administration. • Problemlose und schnelle Integration in bestehende Netzwerke. • File Sharing kann über multiple Plattformen durchgeführt werden. • Günstiger externer Online-Speicher. 4.3.1.1.3 Eckpunkte für die Auswahl einer NAS-Lösung Als sich vor einigen Jahren die Unzufriedenheit der Anwender von Fileservern hauptsächlich in Bezug auf Stabilität, Verfügbarkeit und Skalierbarkeit häufte, kamen die ersten Ansätze von dedizierten Fileservern unter dem Namen „Network Attached Storage“ (NAS) auf den Markt. Zunächst wurden nur im Marktsegment für das NFS-Protokoll entsprechende Systeme entwickelt, die nur die Kernaufgabe des Fileservice bedienen sollten. Alle zusätzlichen Dienste oder gar Anwendungen wurden von dieser Plattform verbannt, um insbesondere dem Ziel der Stabilität näher zu kommen, als dies mit den bis zu diesem Zeitpunkt bekannten Systemen möglich war. Der Appliance-Gedanke, der bereits im Bereich der Netzwerkinfrastruktur mit dedizierten Routern erfolgreich umgesetzt worden war, wurde damit konsequent auch für den Fileservice eingesetzt. Auch vor dem Hintergrund der Berücksichtigung von Kundenwünschen und der weiteren technischen Entwicklung der NASAppliances ist dieser Urgedanke mehr oder weniger in den heutigen Produkten wiederzufinden. Dabei können folgende Merkmale die Implementierungsvarianten von NAS-Appliance beschreiben: • „All in One“-Lösungen machen sämtliche Funktionalitäten über eine einzige zentrale Komponente im Netz zugänglich. Sämtliche Anforderungen sind über die gemeinsame Hard- und Software abzudecken. Die Integration von Fileservices und blockorientiertem Zugriff mit Bearbeitung der verschiedenen Protokolle bis herunter zur Speicherverwaltung und Überwachung des Gesamtsystems müssen in solchen Lösungen abgedeckt werden.Vorteilhaft ist hier das gemeinsame Management von File- und Blockzugriff. Nachteilig sind die hohe Belastung des Gesamtsystems, da alle Zugriffe über die gemeinsame CPU bearbeitet werden müssen, was ein Load Balancing erforderlich macht, sowie die Tatsache, dass All-in-One-Lösungen kaum skalierbar sind, da der Flaschenhals bei der nicht skalierbaren zentralen CPU liegt. • Bei „distributed“ Lösungen wird die Fileserver-Funktionalität vom Speichersystem getrennt. Der NAS wird hier, genau wie andere Serversysteme (UN-

152

4 Information Lifecycle Management Projekt

IX, LINUX, Windows etc.), an ein intelligentes externes Speichersystem angeschlossen. Funktional wird damit File- und Blockzugriff auf unterschiedliche Systeme verteilt, die damit auch für diese speziellen Aufgaben optimiert werden können. Damit gestalten „distributed“ Lösungen das Trennen der Arbeitslast zwischen „file-„ und „blockorientierten“ Zugriffen vorteilhaft. Ein weiterer Vorteil der sich daraus ergibt ist eine bessere Skalierbarkeit durch eigenständige Prozessoren im Server- und Speichersystem und durch die auf die jeweils benötigte Funktion optimierten Betriebssysteme. Negativ stellt sich das externe Speichermanagement dar. Dieses kann jedoch mit der Konfiguration der externen Komponenten (SAN-Switches, SAN-Direktoren etc.) sinnvoll integriert werden. Beide Ansätze unterscheiden sich meist auch in der Art, in der Hochverfügbarkeit erreicht werden kann. Hier gibt es zum einen das Clusterverfahren, bei dem sich die Systemkomponenten untereinander über den jeweiligen Status austauschen müssen, oder den Einsatz von Standby-Komponenten, die den Ausfall von Hardware kompensieren können.Als wesentliches Eckdatum beim Einsatz von Clustern ist die Anzahl der Knoten zu nennen, die einen Cluster bilden können. Bei maximal zwei Knoten zeigt sich recht schnell die eingeschränkte Skalierbarkeit des Gesamtsystems. Notwendige Erweiterungen können dann nur mit weiteren Systemen realisiert werden, die als separat zu administrierende Einheiten eingebunden werden müssen.Insbesondere dann,wenn auch eine räumliche Trennung der Clustermember erforderlich ist,geht das nur zu Lasten des lokalen Schutzes der Lösung. Ein Ausfall eines Clustermembers in einem Aktiv-Aktiv-Cluster hat immer eine Reduktion der Performance des Gesamtsystems zur Folge, da die verbleibenden Member die Aufgabe des ausgefallenen Clustermembers übernehmen müssen.Das Standby-Verfahren kann aufgrund des n:1-Verfahrens auch eine größere Anzahl von NAS-Servern absichern. Durch die Bildung von Failover-Gruppen kann flexibel auf die jeweils abzudeckenden SLAs reagiert werden.Nach einem Failover steht in diesem Verfahren aufgrund identischer Hardware die gleiche Leistungsfähigkeit des Gesamtsystems zur Verfügung wie vor dem Failover auf den Standby-Server. Bei der Entscheidung für eines der vorgenannten Verfahren wird dann meist auch über das mögliche Administrationskonzept entschieden. Bei den Clustersystemen wird meist jedes Member separat administriert, oder aber es müssen bestimmte clusterrelevante Konfigurationen an allen beteiligten Members wiederholt werden. Nicht so beim Einsatz von Standby-Verfahren. Nach dem heutigen Stand der Technik werden hier mehrere Knoten in einem System zusammengefasst,die dann auch als eine Einheit zentral administriert werden können. Die Überwachung erfolgt meist durch eine dedizierte Einheit in der NAS-Lösung, die aus Hochverfügbarkeitsgründen redundant ausgelegt wird. Neben dem zentralen Management kann von hier auch ein automatischer Serviceruf an den Hersteller erfolgen, womit der Austausch defekter Komponenten ohne Zutun des Anwenders veranlasst werden kann. Dabei sind nachfolgende Aspekte insbesondere dann von entscheidender Bedeutung, wenn eine Integration in ein MS-Windows-Umfeld geplant ist:

4.3 Vorbereitung und Durchführung der Ausschreibung

153

• Welche Werkzeuge werden für die Integration der NAS-Lösung in das Microsoft Management Framework angeboten (z. B. MMC)? • Wie tief ist die Integration der NAS-Software in deren aktuellen Version in das Microsoft-Betriebssystem vorangetrieben (Unterstützung Event Log, W2K3 – SMB packet signing, GPOs, Kerberos über TCP usw.)? • Wie ist die Kooperation mit Microsoft, um zukünftige Anpassungen (Patches und Betriebssystemversionen) in die eigene NAS-Software einfließen lassen zu können? 4.3.1.1.4 Verfahren für Datenarchivierung im Fileservicebereich Die immer weiter ansteigende Datenmenge im Fileservicebereich ist eine große Herausforderung an die Infrastruktur. Nicht nur die Datenhaltung und Verwaltung, sondern die Bereiche Datensicherung und Wiederherstellung stellen die Administration vor eine sehr schwierige Aufgabe. Die bloße Einschränkung des zur Verfügung stehenden Datenspeicherbereichs, bspw. durch Quotas, sehen die meisten Endanwender als Eingriff in ihre Arbeitsfähigkeit.Auch der Wunsch, nicht mehr benötigte Datenbestände zu löschen, bringt die Endanwender häufig in die schwierige Lage, die gespeicherten Daten nicht einwandfrei kategorisieren zu können. Hierzu sind effiziente Verfahren für eine Datensicherung und Wiederherstellung zu implementieren einschließlich einem intelligenten Archivierungsverfahren. Folgende Archivierungsverfahren waren dabei zum Zeitpunkt der Erstellung des technischen Konzeptes für KONCOM/IT möglich: • Hierarchic Storage Management (HSM)-Lösung auf Fileserverbasis (NAS) Datenbestände, die auf dem Fileserver (NAS) liegen, werden zyklisch daraufhin untersucht, wann bspw. eine Datei das letzte Mal benutzt worden ist.52 Wird dann festgestellt, dass anhand der eingestellten Regel eine Datei zu archivieren ist, wird die Information auf einen sekundären Speicher ausgelagert und an der Stelle, an der die Datei zuvor vorhanden war, eine Referenz hinterlassen. Aus diesem Verfahren ergeben sich folgende Vor- und Nachteile: Ein Vorteil dieser auf Metadaten wie bspw. dem Modifikationsdatum der Datei basierenden Archivierung ist der transparente Zugriff auf die ausgelagerten Dateien (Endanwender findet die Datei am ursprünglichen Ort im Dateisystem). Eine Installation von Zusatzsoftware auf dem Client ist nicht erforderlich. Als nachteilig stellt sich heraus, dass diese Dateireferenzen eine große Anzahl kleiner Dateien darstellen, die bei der Datensicherung (Einfluss auf die Datensicherung und die Wiederherstellung) ein Streaming verhindern und damit die Dauer der Sicherung und die Wiederherstellung verlängern. • Auslagerung älterer Datenbestände Wie bei der HSM Lösung wird auch bei diesem Verfahren der Datenbestand zyklisch nach verschiedenen Kriterien untersucht und soweit erforderlich auf einen Sekundärspeicher ausgelagert. Beim Auslagern erfolgen Eintragungen in 52

Vgl. Thome Günter., Sollbach Wolfgang, Grundlagen und Modelle des Information Lifecycle Management, Springer Verlag, Berlin Heidelberg, 2007.

154

4 Information Lifecycle Management Projekt

eine Datenbank, die später zum Wiederfinden des Datums benötigt werden. Der Speicherplatz im Fileserver (NAS) wird dabei freigegeben. Eine Referenz am„alten Speicherplatz“ ist nicht vorhanden. Die beschriebene Auslagerungsmethode ist jeweils von der verwendeten Applikation abhängig.Vorteil dieses Verfahrens ist es, dass die Datenbestände endgültig vom primären Speichermedium entfernt werden. Als Nachteil erweißt sich, dass der Endanwender nur über ein„Abfrageprogramm“ auf seine ausgelagerten Daten zugreifen kann. Eine Vielzahl der auf dem Markt für externe Speichersysteme tätigen Hardwarehersteller bietet für die beiden oben aufgeführten Varianten Implementierungen an. Soweit mit diesen Verfahren auch ein dezentrales Konzept umgesetzt werden soll, empfehlen sich auch aus wirtschaftlichen Gründen insbesondere die Lösungen, die Speicher in verschiedenen Klassen innerhalb der gleichen Lösung abbilden können. Die Kombination von schnellen FC-Platten für den produktiven Bereich (Homeshares, Gruppenlaufwerke etc.) und ATA- oder SATAPlattenlaufwerken für den Sekundärspeicher und die Verbindung der NAS-Lösung mit „Snap-Funktionalität“ sind hier sicher ideal. 4.3.1.2 Anbindung von Speichersystemen über Storage Area Networks (SAN) 4.3.1.2.1 Kurzdarstellung Storage Area Networks (SAN) basieren auf der Direktanbindung (Point-to-Point) zwischen Server und Speicher nach dem „Direct Attached Modell“, wobei ein separates Netzwerk aus Speicher-Devices erstellt wird. Beim Netzwerk kann es sich um ein Fibre Channel (FC-) oder Gigabit Ethernet-Netzwerk (iSCSI, FCIP, iFCP) handeln. SANs können externe Festplattensysteme und Bandspeichergeräte umfassen, die über das SAN vielen Servern zur Verfügung gestellt werden. SANs übertragen Daten, ohne dass sich dies auf die Auslastung des Kommunikationsnetzwerks auswirkt. Die zur Verfügung stehende Bandbreite wird von den einzelnen Komponenten exklusive, d. h. nicht geshared verwendet. Der dedizierte SAN-Zugriff macht die Netzwerkbenutzung transparent. Typische Anwendungen, die in einem SAN performant betrieben werden, sind OLTP-Anwendungen, Data Warehousing und ERP-Systeme.Der Datenzugriff im SAN ist blockorientiert.SAN-Technologien bieten Vorteile für geschäftliche und technische Anwendungen, deren Transaktionen eine optimale Performance erfordern, eine große Anzahl von Anwendern und große Datenbanken integrieren. In einem SAN können die Speicher-Devices (d. h. die logischen Festplatten) auf einfache Weise mit höherer Übertragungsrate und Flexibilität gespiegelt werden als in jeder anderen Anschlussart von Plattenspeicher. Fibre Channel (FC-) SANs decken große Entfernungen ab und ermöglichen die Adressierung von Millionen von Devices (Einzelgeräte wie logische Festplatten, Bandlaufwerke, Fibre Channel Controller usw.). Dadurch werden die Verwaltbarkeit und die Flexibilität der Geschäftsumgebung durch ein zentrales Management von hunderten

4.3 Vorbereitung und Durchführung der Ausschreibung

155

und tausenden von Geräten verbessert. Im Rahmen der Konsolidierung gewinnen Management und Sicherheit an Bedeutung. Auf SAN-Basis erstellte Software bietet Verbesserungen, die das Management von Datenmengen im TerabyteBereich ermöglichen. SAN-Infrastrukturen bieten flexibelste Speichermöglichkeiten, weit reichende Interoperabilität und umfassende Datenmigrations- und Verfügbarkeitsoptionen. SANs bieten Volume-Replikationsmöglichkeiten, die Backup- und DisasterRecovery-Lösungen vereinfachen. Durch Konsolidierung, verbesserte Anwendungs-Performance und gesteigerte Skalierbarkeit optimieren SAN-Lösungen die Gesamtkosten (TCO). Unnötiges Duplizieren und Synchronisieren von Datenbeständen wird vermieden. Durch eine SAN-Lösung wird ein Lastausgleich für Server- und Speichersysteme und eine optimale Performance mit besseren Reaktionszeiten für die Anwendungen erreicht. 4.3.1.2.2 Vorteile von über SAN angeschlossenen Speichermedien Im Vergleich zu internen Speichermedien sind über SAN angeschlossene Speichermedien vor allem aufgrund der zentralen Administration des Gesamtsystems mit deutlich geringeren TCO verbunden. Auch der Einsatz der Technologie allein reduziert die Speicherkosten vor allem durch folgende Fakten: • Netzwerkspeichersysteme verbessern die Speicherauslastung durch Konsolidierung Speicherkonsolidierung: Wenn alle Server einen gemeinsamen Speicherpool verwenden, steigt die Auslastung deutlich. Die zu beschaffende und zu verwaltende Speichergesamtkapazität sinkt. Serverkonsolidierung: Der Maximalausbau der Serversysteme beschränkt bei reiner Nutzung interner Festplatten die Anzahl von intern anschließbaren Magnetplatten. Benötigt eine Anwendung mehr Magnetplatten, als intern im Server anschließbar sind, muss ein größer dimensionierter Server oder zusätzliche Server beschafft werden,um die Zahl der Festplatten zu erhöhen.Im SAN wird dem Server lediglich mehr Festplattenkapazität zugewiesen. Konsolidierung des Personals: Weniger Server und weniger Speicher vereinfachen das Management.DieVerwaltung ist weniger komplex,so dass die Mitarbeiter mehr Zeit für unternehmenskritische Aufgaben haben. • SAN-Speichersysteme verbessern die Business Continuity der Geschäftsanwendungen Der Einsatz von SAN-basierten Backup- und Restore-Verfahren reduziert das Risiko,das viele Backup-Devices und viele Backup-Kontrollpunkte mit sich bringen.Es vereinfacht auch Disaster Recovery und Business Continuity, ein weiterer Nebeneffekt der Speicherkonsolidierung. Daten können konsolidiert verwaltet, kontrolliert und synchronisiert werden. Dies verbessert den Schutz der Informationen und gewährleistet die Informationssicherheit sowohl lokal als auch über große Entfernungen.

156

4 Information Lifecycle Management Projekt

• SAN-Speichersysteme steigern die geschäftliche Flexibilität Speichersysteme, die über ein SAN angeschlossen werden, stellen ein besseres Wachstums- und Change-Management für neue und vorhandene Anwendungen zur Verfügung, da mehr Personen, Anwendungen, Server und Speicher in einer Infrastruktur zusammengefasst sind. Dies erleichtert das Hinzufügen oder Erweitern gemeinsamer Funktionen auf mehr Komponenten und für mehr Benutzer. SAN-Speicher stellen eine einzige, konsolidierte Infrastruktur bereit, die den Informationsfluss beschleunigt, indem die Schranken zwischen unterschiedlichen Technologien und veralteten Infrastrukturen beseitigt werden. Dies beschleunigt den Informationsfluss zu mehr Menschen mit weniger Unterbrechungen. SAN-Speichersysteme erleichtern die Erfüllung bestehender SLAs mit bewährten Lösungen für hohe Verfügbarkeit. Damit bietet ein Storage Area Network die Flexibilität, neue SLAs schnell und problemlos umzusetzen. • Gesteigerte Verwaltbarkeit der Gesamtumgebung Ein SAN zentralisiert das Speichermanagement und automatisiert die Gerätesteuerung sowie die Ausführung von Aufgaben und Prozeduren in heterogenen Umgebungen. Außerdem schafft meist erst ein SAN die Voraussetzung um ein leistungsfähigeres Management-Tool einführen und eine Automatisierung von Produktionsabläufen durchführen zu können. die das Speichermanagement vereinfachen und weniger arbeitsintensiv und damit fehleranfällig machen.Dies ist ein wichtiger Schritt in Richtung effizientes und qualitätsorientiertes Management mit einem halben Petabyte oder mehr Effizienz der Administrationsleistung pro Speicheradministrator.

4.3.1.3 Archivierung 4.3.1.3.1 ECM-Systeme Die Geschwindigkeit, mit der die Anforderungen aus der Praxis an die digitale Archivierung und die damit verbundene technologische Entwicklung von Speichersystemen steigen, ist überaus rasant. In den vergangenen Jahren wurden immer mehr Daten erzeugt und elektronisch abgelegt. Dieser Trend hält an und wird sich noch wesentlich verstärken! Marktbeobachtungen haben gezeigt, dass mit sehr stark wachsenden Speichervolumen in Fixed Content Bereichen, also Datenbereichen, in denen Daten erzeugt und danach nicht mehr ändern werden, gerechnet werden muss. Dieses Wachstum wird im Wesentlichen durch • • • • • •

die steigende Anzahl von EDV-Systemen, die steigende Anzahl von elektronischen Daten und Dokumenten, mehr Menschen, die EDV-Systeme nutzen, neue Gesetze und Regularien, überlastete Online-Systeme, den Trend, mehr Daten elektronisch anstelle von Papier zu speichern,

erzeugt. Digitale Inhalte wie z. B.

4.3 Vorbereitung und Durchführung der Ausschreibung

• • • • •

157

E-Mail, klinische Daten (Röntgenaufnahmen, Patientenakten), CAD/CAM Zeichnungen, elektronisch erzeugte Dokumente, gescannte Images (Schecks, Eingangspost, Verträge)

müssen in bestimmten Fällen sehr lange unverändert aufbewahrt werden. Der Lebenszyklus vieler dieser Daten beginnt oftmals transaktionsorientiert oder auch gemeinschaftlich und endet nach einem Zeitraum als Fixed-Content. Zusätzlich steigt auch der Druck auf Unternehmen, diese Daten aus rechtlichen Gründen über einen festgelegten Zeitraum unverändert und nicht löschbar abzulegen. Diese Forderungen existieren vor allen Dingen in Finanz-, Versicherungs-, Medizinund Gesetzesbereichen. Datenarchivierung von 10 bis über 100 Jahren53 kann hier vom Gesetzgeber vorgeschrieben sein. Es gibt kaum einen Zweig in der Informationstechnologie, in der die Zukunftssicherheit der Daten so bedeutend ist, wie bei der digitalen Archivierung. Die Verwaltung und die Sicherstellung dieser Daten stellt für die Zukunft ein bedeutendes Geschäftsfeld dar. Enterprise Content Management (ECM-) Systeme haben sich daher in den letzten Jahren sehr stark im Markt etablieren können. Vorwiegend spielen beim Einsatz dieser Systeme für die Anwender folgende Gründe eine wichtige Rolle: • • • • •

Effizienzsteigerung Kostenreduzierung Besserer Kundenservice Schnellere Reaktion Wettbewerbsvorteile

Die Entwicklung entsprechender Archivlösungen (sowohl Soft- wie auch Hardwareimplementierungen) stellt die Möglichkeit für Betreiber dar, neue Geschäftsmodelle und verbesserte Service Level anbieten zu können. Die Suche nach einer geeigneten langfristigen Archivierungslösung führte zu der Einsicht, dass Bandund optische Lösungen nicht immer die geforderte Flexibilität bereitstellten. Sie gelten als langsam und sie hatten in den vergangenen Jahren eine Reihe von Technologieänderungen (Jukeboxen, Drives, Treiber). Damit verbunden war ein stark erhöhter Managementaufwand. Für digitale Archive gelten daher heute folgende Forderungen: • • • • • 53 54

Verfügbarkeit: jederzeit schneller Zugriff Authentizität: garantierte Unveränderbarkeit der Daten Langlebigkeit: keine Überalterung der Technologien Skalierbarkeit: unterbrechungsfreie, hohe Ausbaubarkeit Managebarkeit: geringste Administration, höchste Verfügbarkeit54 Vgl. Thome, Günter, Sollbach, Wolfgang, Grundlagen und Modelle des Information Lifecycle Management, Kapitel 1 und 2, Berlin Heidelberg, 2007. Vgl. Thome, Günter, Sollbach, Wolfgang, Grundlagen und Modelle des Information Lifecycle Management, Kapitel 1 und 2, Berlin Heidelberg, 2007.

158

4 Information Lifecycle Management Projekt

Daraus ergibt sich die Notwendigkeit, Archivierungslösungen flexibel und schnell auf dem Markt anbieten zu können. In der Vergangenheit wurden Lösungen angeboten, mit denen nur bestimmte Datenarten dediziert adressiert wurden und zu denen oftmals mehrere Technologien zur Lösung gehörten (Magnet-/Optische Platten, Jukeboxen, Treiber). Dieses Vorgehen erzeugt jedoch höhere IT- und Personalkosten und stellt sich daher als ineffizient dar. Die Anzahl und Komplexität von Regularien steigt stetig an. Es reicht derzeit nicht mehr aus, Dokumente zu speichern – sie müssen zeitnahe und im passenden Format zur Verfügung gestellt werden, um Strafen bzw. strafrechtliche Verfolgung zu vermeiden. In Zukunft werden vor allem weitere gesetzliche Anforderungen, wie Basel II im Bankensektor, Solvency in der Versicherungsbranche und Sarbanes Oxley für an der US-Börse notierte Unternehmen, entsprechend abgehandelt werden müssen. Die langfristig orientierte Planung eines Archivsystems wurde oftmals versäumt. Dadurch entstanden Kosten, die bei der Planung des Systems nicht berücksichtigt wurden, wie bspw. das Wachstum des Archivs, Applikationsmanagement und Administration. Der Betrieb von Archivsystemen ist sehr administrationsintensiv, da man ständigen Technologiewechseln in Hardund Software begegnen muss.

4.3.1.3.2 Allgemeines Archivierungskonzept Die Archivierung erfüllt zwei Aufgaben: 1. Revisionssichere Dokumentenablage zur Erfüllung gesetzlicher Vorschriften 2. Entlastung der Produktionsysteme MS-Exchange/Lotus Notes und Fileservices Um die unterschiedlichen rechtlichen Anforderungen abzudecken, sollte ein festplattenbasiertes Archivmedium verwendet werden, welches in sich die Datenintegrität und unverfälschbare Langzeitarchivierung sicherstellt. Dadurch wird die führende Applikation, das DMS oder ECM System von diesen Aufgaben entlastet und es besteht die Möglichkeit,bei geänderten Anforderungen andere oder weitere Applikationen einzusetzen. Zur wirtschaftlichen Ausnutzung der Archivkapazität sollte eine Dublettenreduktion über den gesamten Archivbestand verwendet werden. Dadurch wird ein erhebliches Einsparpotenzial erreicht. Besonders die Kombination von E-Mail und Filesystem beinhaltet erfahrungsgemäß eine große Menge redundant gespeicherter Informationen. Damit hierbei der gesamte archivierte Datenbestand betrachtet wird, sollte die Dublettenreduktion durch das Archivspeichersystem selbst vorgenommen werden. Um den Anforderungen an eine revisionssichere Datenablage gerecht zu werden,sollte das Archivmedium alle Daten durch RAID-Level auf dem lokalen System absichern und darüber hinaus die Replikation in einen zweiten Standort unterstützen.Auftretende Fehler im Datenbestand sollten vom Archivmedium aufgrund von selbsttätigen, ständigen Prüfungen erkannt und behoben werden. Das Archivmedium sollte die zusätzliche Ablage der Metadaten zu den Archivdaten unterstützen. Somit können die Datenbanken des ECM-Systems aus dem Archivmedium rekonstruiert werden („Selbsttragendes-Archiv“).

4.3 Vorbereitung und Durchführung der Ausschreibung

159

Die Aufrüstung des Archivmediums sollte nicht nur bezüglich Kapazität, sondern auch für höhere Systemleistung unterbrechungsfrei und mit minimalem administrativem Aufwand durchführbar sein. Ebenso sollte unter Berücksichtigung der Langlebigkeit die Migration auf neue HW-Technologien vom System unterstützt werden. 4.3.1.4 Schlussfolgerungen für EurAmFi AG und KONCOM/IT Ausgehend von den Anforderungen an das Projekt KONCOM/IT, der bestehenden zu konsolidierenden Ist-Umgebung und der benötigten Kapazitäten konnte im Wesentlichen aufgrund der beiden gravierenden Nachteile einer NAS-Lösung • hohe Belastung des Gesamtsystems, da alle Zugriffe über gemeinsame CPU bearbeitet werden müssen (macht ein Load Balancing erforderlich), sowie • kaum skalierbar, da der Flaschenhals bei der zentralen CPU liegt, und der Bedenken des Einsatzes von NAS-Lösungen im MS-Exchange-Umfeld nur die Implementierung eines Storage Area Network für die Datenklassen 1 (hochverfügbarer Speicher) und 2 (Nearline-Speicher) empfohlen werden. Als Systeme der Datenklasse 3 können NAS-Systeme, Magnetbandlaufwerke, WORM-JukeboxSysteme oder Content Adressable Storage (CAS-) Magnetplattensysteme verwendet werden. Alle eingesetzten Systeme sollen jedoch nur auf Basis eines „zwei“Standort-Prinzips realisiert werden, d. h. unter Realisierung einer Spiegelung der archivierten Daten. Die Lösungen müssen dabei selbständig Archivierungsfehler erkennen und beheben. 4.3.1.5 Storagefunktionalität 4.3.1.5.1 Anforderungen an die Speichersysteme Die für die Datenklassen 1 und 2 einzusetzenden Speichersysteme sind im Allgemeinen mit den folgenden Funktionalitäten versehen, die es hinsichtlich ihrer Bedeutung für KONCOM/IT zu beurteilen galt und die in die Ausschreibung und die Bewertung der Angebote einflossen: • SNAP-Funktionalität (ermöglicht das Erstellen eines logischen Abbilds des Originalbildes der Datenplatte, eingefroren auf einen dedizierten Zeitpunkt) sollte auf lokalem und remote System gegeben (auch Restore) und arbeitsfähig sein. • Local Mirror (RAID 1 + 5, RAID 1 als kompletter Spiegel einer Produktivplatte, RAID 5 als PARITY RAID 5 + 1), muss als Absicherung vorhanden sein. • Remote Mirror (RAID 1 + 5, RAID 1 als kompletter Spiegel einer Produktivplatte,RAID 5 als PARITY RAID 5 + 1),muss als Absicherung vorhanden sein.55 • Promote Mirror Funktionalität (Trennung des Remotespiegels), muss als Absicherung vorhanden sein. 55

Gilt nur für Speichersysteme für Datenklasse 1 – hochverfügbare Systeme, vgl. hierzu: Thome, Günter, Sollbach, Wolfgang, Grundlagen und Modelle des Information Lifecycle Management, Kapitel 1 und 2, Berlin Heidelberg, 2007.

160

4 Information Lifecycle Management Projekt

• Automatische Aktivierung des Remotespiegels (transparente Bereitstellung des Spiegels am Host) muss realisierbar sein.56 • Automatische und manuelle Synchronisation des Remotespiegels muss realisierbar sein.57 • Vom Primärspiegel zum Remotespiegel muss ein inkrementelles „Establish“ möglich sein.58 • Vom Remotespiegel zum Primärspiegel muss ein inkrementeller „Restore“ möglich sein.59 • Online-LUN-Erweiterung muss möglich sein. • Durch die Administrationssoftware oder durch Microcode-Implementierung muss ein dynamischer „Pfad-Failover“ möglich sein. • Ausgefallene physikalische Platten müssen durch dynamische „Hot-Spares“ automatisch ersetzt werden. • Die SAN „Copy“-Funktionalität ist gefordert, d. h. die Möglichkeit, nicht nur innerhalb eines Speichersystems Daten von LUN zu LUN zu kopieren, sondern auch Daten einer LUN in einem Speichersystem zu einer anderen LUN in einem anderen Speichersystem (gegebenenfalls auch herstellerübergreifend) zu kopieren. 4.3.1.5.2 Anforderungen an die Speicheradministration Die Speicheradministration sollte über sämtliche Datenklassen übergreifend in sich konsistent sein und mit möglichst nur einem Administrationswerkzeug durchführbar sein. Dazu sollte dieses folgende Anforderungen erfüllen: • Das Werkzeug sollte eine Web-gestützte Administration ermöglichen. • Ein Commandline Interface (CLI) mit wenigstens denselben Funktionalitäten wie das GUI sollte vorhanden sein. • Betriebssystem-Support für die Administration W2K/W2K3/Windows XP,AIX und Solaris muss gegeben sein. Im EurAmFi-Konzern wird der Administrationsclient auf jeden Fall ein Windows XP-Server sein. • Das Administrationswerkzeug muss ein Berechtigungskonzept auf Benutzerund/oder Gruppenbasis ermöglichen. • Benachrichtigung per Mail an einen definierbaren Benutzerkreis muss im Fehlerfalle möglich sein. • Eine „Reporting“ Funktionalität (Historienwerte, Verfügbarkeit, Auslastung, Performance) muss gegeben sein. • Eine „Accounting“ Funktionalität (genutzte Ressourcen je System/Gruppe, Schnittstelle) muss gegeben sein. • Eine „Optimizer“ Funktion, respektive die Möglichkeit zur Reorganisation fragmentierter RAID-Gruppen muss vorhanden sein. • Das Administrationswerkzeug muss den Tivoli Storage Manager (TSM) unterstützen. 56 57 58 59

Gilt lediglich für Speichersysteme für Datenklasse 1. Ebenso. Ebenso. Ebenso.

4.3 Vorbereitung und Durchführung der Ausschreibung

161

• Die Unterstützung einer Speichervirtualisierung durch das Administrationswerkzeug ist erwünscht. 4.3.1.6 Technische Anforderung Speichersysteme, Switche und Direktoren 4.3.1.6.1 Speichersystem • Die zu beschaffenden Speichersysteme sollten im Frontendbereich in 2-GbitTechnologie ausgeführt sein. Eine Option auf eine dynamische Umstellung auf 4-Gbit war erwünscht. • Für das gesamte Speichersystem muss eine interne Redundanz der Komponenten angeboten werden,d. h.,doppelte (dreifache) Ausführung von Powersupply, Frontend Directoren, Cache, Controller usw. war gefordert. • Der Anbieter musste in der Lage sein, die angebotenen Systeme remote zu überwachen. Die Realisierung der Ferndiagnose erfolgt typischerweise über einen Modemzugang (analog oder ISDN), der eine Dial-out-Funktionalität besitzt. Dieser Zugang sollte im Standardbetrieb nicht zu einem Zugriff aus dem Netz von außen nutzbar sein, im Wartungsfall nach Abstimmung mit der EurAmFi Business Services GmbH jedoch von dieser aktiviert werden können. • Firmware- und Microcode-Updates müssen online durchführbar sein ohne Beeinträchtigung der angeschlossenen Clientsysteme. • Gefordert waren je System mindestens 4 Frontend-Ports pro Frontend-Direktor. • Fiber Channel Support für Brocade und McData Switches und Direktoren war gefordert, für Cisco und evtl. andere gewünscht. • Support für die aktuell gebräuchlichen LWL-Karten der Hersteller EMULEX und Qlogic war zwingend gefordert. • Unterstützung der internen RAID-Level 0, 1, 5, 0 + 1, 0 + 5. Mix verschiedener RAID-Level innerhalb eines Speichersystems sowie die Funktionalität, RAID-Sets über mehrere Disk-Array-Einschübe (DAE-Spreading) verteilen zu können, waren zwingend gefordert. • Die maximale Anzahl von LUNs ohne Berücksichtigung virtueller und SNAPLUNs sollte größer oder gleich 1024 LUNs sein. • In den Speichersystemen sollten die physikalischen Plattengrößen mischbar (73er, 146er, 300er) eingesetzt werden können. • Die Plattentypen sollten über verschiedene DAEs mischbar sein (SATA- und FC-Technologie), innerhalb eines DAEs sollten jedoch einheitliche Plattentypen verwendet werden. • Die Anforderung an den Fan-out je Frontendport war die Unterstützung eines Fan-outs von ≥ 32. Werden 8 Frontend-Ports je Controller angeboten, kann sich der Fan-out auf ≥ 16 reduzieren. • Folgende Betriebssysteme müssen unterstützt werden: AIX, Windows (W2K, W2K3, Advanced Cluster Server), Novell(-Cluster), LINUX (SuSE, RHEL), Solaris, TRU64, HP/UX. • Boot-Support für die o.a. OS-Plattformen. Die Betriebssysteme müssen von Platten auf den externen Speichersystemen booten können. • SNMP-Unterstützung zum schnellen Forward von Ausnahmesituationen.

162

4 Information Lifecycle Management Projekt

• Integration in die Tivoli-Management-Plattform ist unabdingbar. • Die angebotenen Speichersysteme müssen auf wenigstens 16 TB (Netto) pro Speichersystem ausbaubar sein. 4.3.1.6.2 Switches und Direktoren • Gefordert ist mindestens eine 2-Gbit-Technologie (switched) mit der Option zur Aufrüstung auf 4-Gbit. • Remoteüberwachung durch den Hersteller über SNMP (typischerweise nur über LAN). • Ein Berechtigungskonzept über User/Gruppe muss möglich sein. • Die Switches/Direktoren müssen über ein Web GUI zu administrieren sein. • Der Onlinetausch von Gigabit Interface Converter (GBICs) ist gefordert. • Firmwareupdates müssen im Status „online“, d. h. mit einer Auszeit (Switch Downtime) von weniger als 30 Sekunden durchführbar sein. • Interne Redundanz (Power etc.) ist gefordert. 4.3.1.7 „Pre Site“-Anforderungen und Standort Nach Auswahl der Systemlieferanten muss mit diesen in aller Regel eine als „Pre Site“ benannte Begehung des Rechenzentrums durchgeführt werden. Hier geht es den Lieferanten im Wesentlichen darum, unvorhersehbare Hindernisse für die hardware- und softwareseitige Anlieferung, Installation und den Betrieb der von ihnen zu liefernden Komponenten bereits vor Anlieferung zu erkennen und deren Abstellung zu veranlassen. Dabei werden vor allem folgende Informationen eruiert: • • • • • • •

Kontaktpersonen beim Kunden Kontaktpersonen des Lieferanten Wer wird das zu liefernde System warten Fragen zu Organisation und Infrastruktur von An- und Auslieferung Fragen zur RZ-Infrastruktur Herstellerinformationen zu Lieferumfang Fragestellung zur Systemumgebung (Server, OS, HBAs etc.)

Sämtliche für das Projekt KONCOM/IT der EurAmFi AG benötigten Voraussetzungen sind in den beiden Rechenzentrumsstandorten Hauptverwaltung (RZ 1) und Technikzentrum (RZ 2) mehr als ausreichend gegeben. Die Presite-Besprechungen mit den nach dem Ausschreibungsprozess ausgewählten Herstellern werden durch die WeDo-IT begleitet und es wird sichergestellt, dass die Voraussetzungen für die SAN- und Komponentenimplementierung eingehalten werden. Die EurAmFiSysteminformationen wurden bei der Ermittlung des Ist-Zustandes erfasst und werden bereits zum Ausschreibungsprozess den Herstellern zur Verfügung gestellt.

4.3 Vorbereitung und Durchführung der Ausschreibung

163

Tabelle 4.1. KONCOM/IT-Speicher-Schutzklassen Klasse

Bedeutung

1

Local Mirror (RAID 5)

2

Local Mirror (RAID 5) + Snaps (Kalkulation 20 %)

3

Local Mirror (RAID 5) + Snaps (Kalkulation 20 %) + Remote Mirror (RAID 5)

4

Local Mirror (RAID 5) + Snaps (Kalkulation 20 %) + Remote Mirror (RAID 5) + Snaps

4.3.1.8 Definition der Speicher-Schutzklassen Zur Ermittlung des Gesamtbedarfs an Speicher ist es sinnvoll, eine Klassifikation einzuführen, die die Berechnung vereinfacht. In KONCOM/IT wurden als Gruppierungen, die aus den praktischen Anforderungen des Betriebes der EurAmFiUmgebung durch die EurAmFi Business Services als sinnvoll erschienen,die RAIDSchutzklassen identifiziert, die in Tabelle 4.1 dargestellt sind. Aus organisatorischen Gründen und aus Gründen des Ist-Zustandes der Produktion der EurAmFi-Umgebung wird auf eine Differenzierung in verschiedene RAID-Gruppen mit unterschiedlichen RAID-Absicherungsmechanismen verzichtet. Folgende prinzipielle Absicherungsmechanismen von Magnetplatten wären für den Einsatz bei KONCOM/IT möglich gewesen:

Abb. 4.27. RAID-Verfahren

164

4 Information Lifecycle Management Projekt

Das für sämtliche künftige Speichersysteme der EurAmFi vorzusehende RAID5-Verfahren stellt eine heute gängige Variante zu den RAID-S- und RAID-RVerfahren dar,bei dem – je nach Hersteller und Speichersystem der RAID-Verbund aus 3 Daten- und einer Parity-Platte, 7 Daten- und einer Parity-Platte, 9 Datenund einer Parity-Platte und evtl. weiteren Kombinationen gebildet werden kann. Je mehr Platten zu einem RAID-Verbund zusammengeschaltet werden, umso länger dauert in aller Regel eine Synchronisation einer Hot-Spare-Platte und die Resynchronisation nach Austausch der defekten Platte. Generell ist ein RAID-5Verfahren stets weniger performant als ein RAID 1 Verfahren, da bei diesem auch der lokale Spiegel der Produktivplatte zur Parallelisierung von lesenden Zugriffen verwendet werden kann. Der Performancevorteil, den man durch die dedizierte Aufteilung in RAID 1 und RAID 5 erzielen kann, ist zwar messbar vorhanden, der Aufwand in der Verwaltung, d. h. die logischen Zuordnung der Speicher (Devices) zu den einzelnen Hosts (Problem der Datenverteilung auf RAID-1-Verbänden), ist in der Regel größer als der Performancevorteil, den man dadurch erhält. Sollten entsprechende Engpässe auftreten, so ist immer noch eine weitestgehend transparente Migration der Daten auf RAID 1 geschützte Platten möglich. Daher sollen die Anbieter für KONCOM/IT eine für eine aus Performance-Gründen notwendige Migration angemessene Anzahl von Freikapazitätsplatten vorsehen, die bei Bedarf auch einen nachträglichen Schwenk auf RAID 1 möglich machen. Durch den Wechsel auf Speichersysteme in Fiber Channel (FC-) Technologie und die Möglichkeit, die Devices über eine Vielzahl physikalischer Platten im Backend des Speichersystems zu verteilen, lässt sich eine Steigerung der derzeitigen Performance erzielen, auch ohne den Einsatz der teuren RAID-1-Technologie, die für jede Datenplatte einen lokalen Spiegel benötigt.

4.3.1.9 LUN-Größen Die heute gängigen Speichersysteme sind fast alle in der Lage, LUNs von fast beliebiger Größe bereitzustellen. Dieses Feature ist aufgrund einiger technischer Randbedingungen (Anordnungen von Tracks im RAID-Verband) auf eine Granularität von einigen MB begrenzt. In der Praxis hat es sich jedoch bewährt, die Größenordnung der zu verwendenden LUNs auf ein bestimmtes Raster einzugrenzen. Dabei sind verschiedene LUN-Größen sinnvoll und notwendig. Die Eingrenzung durch die Definition fester Datenvolumen fördert unter Umständen den „Verschnitt“, also den nicht sinnvoll nutzbaren Bereich auf einer Platte. Diesen gilt es zu minimieren. DieVereinheitlichung in Form fest definierter„Speicherblöcke“ bietet die Möglichkeit, sehr einfach und effizient SAN-Kopien durchzuführen. Bei SAN-Kopien wird das binäre Abbild einer LUN in eine andere überführt bzw. kopiert. Viele Speichersysteme stellen ein derartiges Feature zur Verfügung. Dies ermöglicht die SAN-gestützte Kopie, ohne einen direkten Vermittler (hostbasierte Kopie) einschalten zu müssen.Letztendlich wird so auch eine Migration bestehender Systeme auf andere Speichersysteme vereinfacht.

4.3 Vorbereitung und Durchführung der Ausschreibung

165

Die Größenordnung der Speicherblockgröße“ bestimmt sich aus der Überlegung, welche Betriebssysteme mit welchem Basisbedarf an Kapazität auskommen. Bei der Verwendung von UNIX- und Windows-Systemen haben sich als besonders praktikabel erwiesen: 4, 8, 24, 50, 100, 500 usw. (alle Werte in Gigabyte). In der Ausschreibungsphase sollten die angeschriebenen Hersteller in ihren Angeboten erläutern, auf welcher LUN-Größen-Grundlage ihr Angebot beruht und warum diese LUN-Größen für die Betriebsumgebung der EurAmFi AG aus Sicht des Anbieters sinnvoll sind. 4.3.1.10 Anzahl der Host Bus Adapter (HBA) Grundsätzlich sind Server gemäß den Basisstandards der EurAmFi AG für den Einsatz von externen Speichersystemen gemäß den definierten IT-SicherheitsBetriebsstandards im SAN zweipfadig anzubinden. Diese Anbindung ist in einer redundanten Art und Weise durchzuführen, indem jeweils ein Adapter in einer für den zweiten Adapter nicht erreichbaren/sichtbaren SAN-Fabric angeschlossen wird. Was die Auswahl von Adaptern und deren Firmware Releasestände angeht, sollte den Empfehlungen der Hersteller Folge geleistet werden. In der Praxis finden sich häufig LWL-Karten der Hersteller EMULEX und QLogic im Einsatz. Für die Backup-Server ist eine Trennung der HBAs zu berücksichtigen. Dies ist aufgrund des sehr unterschiedlichen Verhaltens der Zugriffe auf die Platten bzw. die Tapedrives notwendig. Bei einer derzeit durchschnittlichen Datenrate von ca. 30 MB/s ist ein HBA für drei Magnetbandlaufwerke sinnvoll, um entsprechende Reserven bei einem Austausch von Tapedrives zu haben. Nach der aktuellen IstAufnahme ergeben sich folgende Zahlen für die Adapter: Tabelle 4.2. Anzahl benötigter Host Bus Adapter* Betriebssystem

HBAs

UNIX/LINUX

640 für Serversysteme +37 (= 12 × 3 + 1 für Anbindung Tapedrives und Changer)

LOTUSNOTES EXCHANGE W2K3

528

SUMME

1205

* Bei der Ermittlung des HBA-Bedarfs wurde bei der Berechnung des Clusterbedarfs von einer zweipfadigen Anbindung jedes Clustermembersausgegangen.

4.3.1.11 Anzahl Switch Ports Für das im Rahmen des Projektes entwickelte SAN-Konzept sind insgesamt Switches, bzw. Direktoren, für mindestens 1.800 Ports vorzusehen, diese werden redundant je Standort als zwei SAN-Fabrics aufgebaut. Es werden jeweils zwei separate Switche standortübergreifend mittels mehrerer Interswitch Links (ISL) verbunden.

166

4 Information Lifecycle Management Projekt

Abb. 4.28. Exemplarische Darstellung der Soll-Serveranbindung im SAN

Abb. 4.29. Exemplarische Darstellung der Soll-Backup-SAN-Anbindung

4.3 Vorbereitung und Durchführung der Ausschreibung

167

Abbildung 4.28 (Exemplarische Darstellung EurAmFi Soll-Serveranbindung im SAN) beschreibt die Anbindung einiger Server an einem Standort. Die standortübergreifende Darstellung der vollständigen KONCOM/IT-Umgebung würde allein aufgrund der Zahl der notwendigen Anbindungen die Möglichkeiten des vorliegenden Buches weit sprengen. Das Topologiebild der KONCOM/IT-Produktionsumgebung der EurAmFi wurde mit dem Microsoft-Tool Visio2000 erstellt und wurde – um überhaupt noch eine Übersichtlichkeit zu erlauben – je Standort mit 2 DIN-A0-Bögen ausgedruckt. Eine Verkleinerung auf die Dimensionen des Buches wäre ridikül. Abbildung 4.29 zeigt die Backup-Anbindung für die exemplarische Darstellung der Soll-Serveranbindung an das Speichersystem. 4.3.1.11.1 HBA-Ports Aufgrund der Redundanz ergibt sich der Anschluss eines Servers an zwei Switche, bzw. an zwei Direktoren, so dass die Anzahl der Switch Ports mindestens so hoch sein muss wie die Anzahl der in den Servern benutzten Host Bus Adapter (vgl. Tabelle 4.2). 4.3.1.11.2 ISL-Leitungen und -Kapazität Zusätzlich zu den gemäß den vorgestellten Sachverhalten ermittelten HBA-Ports müssen weitere Ports bereitgestellt werden, die für die Übertragung der zu spiegelnden Informationen verwendet werden müssen, bzw. die beim Ausfall die Verbindung zum Remote-Speicher herstellen. Diese zusätzliche Ports sind für den Aufbau der K-Fall Szenarien für die Datenklasse 1 (hochverfügbare Daten) der EurAmFi AG notwendig. Weiterhin müssen zusätzlich die Ports addiert werden, die für die Anbindung der Libraries benötigt werden. Die Leitungskapazität errechnet sich prinzipiell aus der Überlegung, welche Leistung von dem Speichersystem entnommen werden kann, bzw. wie viele Verbindungen das Speichersystem zum Anschluss von Servern zur Verfügung stellt. Bei den zu erwartenden Angeboten an Speichersystemen wird die Anzahl der Verbindungen wahrscheinlich bei 8 bis 16 für Speichersysteme der Datenklasse 2 der EurAmFi AG (Nearline-Daten) und – je nach angebotener Technologie – der Datenklasse 3 (Archivdaten) liegen. Bei Speichersystemen der Datenklasse 1 werden Enterprise-Speichersysteme in den Angeboten erwartet, die mindestens 64 FibreChannel-Direktor-Ports bereitstellen. Hinzu kommen die Tape-Libraries, die im jeweils gegenüberliegenden Rechenzentrum über Kreuz betrieben werden. Für den unwahrscheinlichen Fall, dass eine Seite des Rechenzentrums komplett ausfällt, ist der Betrieb über die verbleibenden ISLs zu ermöglichen. Hierbei wird normalerweise ein Kompromiss zwischen der theoretisch notwendigen Kapazität und dem durchschnittlich zu erwartenden Durchsatz gemacht. Dies ist insbesondere dann der Fall, wenn es sich um Remote-Standortanbindungen handelt, wie die zwischen der Hauptverwaltung und dem Technik-Zentrum der EurAmFi AG. WAN-Verbindungen im Dark-Fibre-Bereich sind in der Regel mit hohen Kosten verbunden. Bei der EurAmFi AG ist dies aufgrund der lokalen Trennung der Rechenzentren für die Gewährleistung des K-Fall Schutzes der Fall. Dennoch

168

4 Information Lifecycle Management Projekt

wird ein volles Auflegen aller notwendigen Verbindungen empfohlen, da es sich bei den Systemen der Datenklasse 1 nach Datentypisierung auch um die bedeutsamsten Systeme und die Daten in den Nutzungsphasen des Informationslebenszyklus handelt. Die Berechnungen der HBA ergab bei voraussichtlich jeweils 6 Fibre Channel (FC-) Direktoren mit jeweils 124 oder 140 Ports (abhängig vom Hersteller) je Rechenzentrum, 160 Speicherports und 12 Tapedrives an vier HB’s eine ISLVerbindungszahl von 8 je Direktor. 4.3.1.11.3 Summe der Fibre Channel SAN-Ports Die Verteilung auf die einzelnen Standorte ist stets von der Anzahl der in den beiden Rechenzentren zu bedienenden Server abhängig. Die Rechenzentren in der EurAmFi AG sind komplett identisch ausgelegt. Daher wird von KONCOM/IT eine möglichst gleichmäßige Verteilung der SAN-Ports und der Server- und Storagesysteme über beide Rechenzentren erwartet. Tabelle 4.3. Exemplarische Darstellung der Soll-Backup-SAN-Anbindung

LOTUS NOTES EXCHANGE W2K3 UNIX/LINUX TSM ISL Storage SUMME

Rechenzentrum 1 (Hauptverwaltung) 120 200 24 48 160 552

Rechenzentrum 2 (Technikzentrum) 208 140 24 + 8 48 160 588

Bei dieser Verteilung kam für die Ausschreibung lediglich die Forderung nach SAN-Direktoren mit einer möglichen Kapazität von mindestens 124 Ports je Direktor in Frage. Insgesamt sollte für jedes der beiden EurAmFi-Rechenzentren eine Kapazität von 900 SAN-Ports ausgeschrieben werden, um sowohl ein zukünftiges Wachstum als auch eine evtl. aus Performancegründen notwendige mehr als zweipfadige Anbindung der Serversysteme an das SAN zu ermöglichen. Obwohl Direktoren ein weit höheres Maß an Redundanz integriert haben (doppelte Backplane, drei bis vierfach ausgelegte Powersupplies, online aus- und einbaubare Switch-Port-Karten) stellen sie im Falle der regelmäßig wiederkehrenden Firmwareupgrades doch einen „single Point-of-Failure“ dar. Es empfiehlt sich daher nicht, durch den Einsatz von nur einem Gerät an der Sicherheit und Verfügbarkeit zu sparen. Dies sollte allein aufgrund der benötigten Portzahl auch nicht möglich sein. Von einer aus Kostengründen optionalen Bestückung mit kaskadierten Switchen ist gleichwohl abzuraten, da die Transparenz der Verwaltung und Administration stark nachlässt und evtl. zur Fehlerfalle im Betrieb wird. Ebenso ist die Anzahl maximaler ISL’s (HOPs) schnell erreicht. Zusätzlich wird durch die Kaskadierung ein Großteil der verfügbaren Ports für die Schaltung weiterer ISLLeitungen verbraucht.

4.3 Vorbereitung und Durchführung der Ausschreibung

169

4.3.1.12 Hochverfügbare Services und Schutzklassen 4.3.1.12.1 Vorgaben aus KONCOM/IT Die Differenzierung in unterschiedliche Schutzklassen für die Datenplatten folgt den Anforderungen, für unterschiedliche Service-Wertigkeiten auch unterschiedliche physikalische und logische Wiederherstellzeiten nach einem Totalverlust zu gewährleisten. Die derzeitige Ausgestaltung der Schutzklassen resultiert aus den für die Datenklassifizierung der Server, bzw. der Anwendungen genannten SLArelevanten Verfügbarkeitsklassen. Folgende Abschnitte sollen eine Nutzung der Klassifizierungskriterien über die Verfügbarkeitsklasse hinaus anregen (war nicht Gegenstand des Projektes KONCOM/IT), sollten in der Zukunft an die RZ-Produktion der EurAmFi Business Services GmbH weiter gehende SLA-Anforderungen herangetragen werden. 4.3.1.12.2 Vorgehensvorschlag für ein neues SLA-Konzept Ein wichtiger Bestandteil in Leistungsverträgen sind klar strukturierte Service Level Agreements (SLA). SLAs fungieren als Bindeglied zwischen dem Auftraggeber und dem Serviceleister. Sie beschreiben auf der einen Seite die technische Machbarkeit in den einzelnen Servicemodulen in verständlicher Sprache, dienen aber auch auf der anderen Seite zur Abgrenzung des technischen Aufwandes, damit eine Kostenplanung und -kontrolle für Servicegeber und Auftraggeber überhaupt möglich wird. 4.3.1.12.2.1 SLA-Matrix Für die gesamtheitliche Darstellung aller angebotenen Servicemodule ist die SLAMatrix das am Besten geeignete Werkzeug. In Form der SLA-Matrix kann allen Beteiligten transparent die leistbaren Services dargestellt,beschrieben und voneinander abgegrenzt werden. Die vorgeschlagene 4-stufige SLA-Matrix zeigt alle leistbaren Servicemodule. Alle Module sind in ihren Leistungen genau beschrieben. Auch die Darstellung des Wechsels des leistbaren Services in eine andere Serviceklasse ist in beide Richtungen innerhalb eines vereinbarten Zeitraumes möglich. Der Aufbau eines Service Level (SL-) Konzeptes auf Basis einer SLA-Matrix erfolgt in drei Schritten: • Beschreibung der SLA-Module • Festlegen einer Preisstruktur • Zuordnung von SLA-Modulen 4.3.1.12.2.2 Beschreibung der SLA-Module Die einzelnen Konstrukte einer SLA-Matrix müssen im Detail beschrieben werden. So erhält der Kunde einen genauen Überblick über die zu erwartenden Leistungen. Die folgende Abbildung 4.30 zeigt eine erste, grobe Differenzierung, die noch detaillierter beschrieben werden muss. 4.3.1.12.2.3 Festlegung einer Preisstruktur Sobald die Konstrukte klar beschrieben sind, erfolgt ein darauf abgestimmtes Kostenmodell. So kann der Kunde erkennen, welche Mehrkosten für ihn entstehen, wenn er sich bei einer Anwendung für einen höheren Service Level entscheidet.

170

4 Information Lifecycle Management Projekt

4.3.1.12.2.4 Zuordnung von SLA-Modulen pro Anwendung oder Anwendungsgruppe Die folgenden Beispiele zeigen,wie transparent eine Zuordnung von SLA-Modulen mit Hilfe einer Matrix pro Anwendung oder Anwendungsgruppe vorgenommen werden kann. 4.3.1.12.2.4.1 Beispiel „Geringe Anforderungen“

Abb. 4.30. Beschreibung der SLA-Module

Abb. 4.31. SLA-Module für Kleinkunden oder geringe Anforderungen

4.3 Vorbereitung und Durchführung der Ausschreibung

4.3.1.12.2.4.2 Beispiel „Höhere Anforderungen“

Abb. 4.32. SLA-Module für mittelgroße Kunden oder höhere Anforderungen

4.3.1.12.2.4.3 Beispiel „Gehobene Anforderungen“

Abb. 4.33. SLA-Module für mittelgroße Kunden oder gehobene Anforderungen

4.3.1.12.2.4.4 Beispiel „Höchste Anforderungen“

Abb. 4.34. SLA-Module für Großkunden oder höchste Anforderungen

171

172

4 Information Lifecycle Management Projekt

4.3.1.13 Failover-Konzept Für eine hohe Verfügbarkeit der Anwendungen ist es notwendig ein FailoverKonzept bereitzustellen, das es ermöglicht, im Falle eines Hardwarefehlers ausgefallene Komponenten zu ersetzen. Aus Sicht des SANs der EurAmFi AG für die Datenklassen 1 und 2 können folgende Komponenten ausfallen,die entweder durch Redundanz und/oder administrative Maßnahmen kompensiert werden müssen: • • • • •

Ausfall eines HBAs, Ausfall einer Zuleitung Ausfall eines Switches/Directors Ausfall eines Frontend-Controllers des Speichersystems Ausfall eines Servers Ausfall des Primärspeichersystems (des gesamten produktiven Speichersystems bei K-Fall-Absicherung) • Ausfall des Primärstandortes (des gesamten Produktiv-Rechenzentrums bei K-Fall-Absicherung) Von kompensierbaren Ausfällen kann gesprochen werden, wenn nur eine Teilkomponente defekt ist. Sind mehrere Komponenten am Ausfall beteiligt, führt nur unter günstigsten Umständen eine Kombination von singulären Lösungen für die einzelnen Fehlerursachen wieder zu einem funktionierenden System. Mit Hilfe der folgenden Abbildung sollen alle Teilszenarien kurz beschrieben und diskutiert werden. Dazu vorab eine allgemeine Anmerkung: Die im Nachgang beschriebenen Szenarien gehen zumindest von einer rudimentären produktkonformen Funktionsweise der Speichersysteme aus. Die Abbildung dient als Beispiel-SAN für die Beschreibung der folgenden Ausfallszenarien.

Abb. 4.35. Ausfallszenarien im SAN der EurAmFi AG

4.3 Vorbereitung und Durchführung der Ausschreibung

173

Im Falle von Firmware-Fehlern oder Micro-Code-Fehlern im Bereich der Speichersysteme kann die beschriebene rudimentäre Funktionsweise verloren gehen, was zu einem Systemzustand des Speichersystems führen kann, in dem der Zugriff auf die Remote-Speichersysteme und/oder die SNAPs nicht mehr möglich ist. Ein solcher – auf Softwarefehler des Speichersystems oder der Switches-, bzw. SAN-Direktoren zurückzuführender – Fehlerfall ist von den bisherigen FailoverKonzepten nicht abzufangen. Ebenso wenig werden selbstverständlich Fehler abgefangen, die durch bewusste oder unbewusste logische Zerstörung der Daten entstehen. Für den letztgenannten Fall sind zusätzliche Mechanismen zu implementieren wie beispielsweise eine Hot-Standby-Datenbank mit Nachlauf. 4.3.1.13.1 Ausfall eines HBA oder Ausfall einer Zuleitung Der Ausfall eines HBAs oder einer Zuleitung wird entweder durch die dem Betriebssystem zugehörige „Path“-Failover-Software abgedeckt oder durch eine typischerweise vom Speichersystemhersteller gelieferte Dynamic Multipathing Software. Diese Software wird in der Anwendungsschicht oberhalb der eigentlichen Treiber der HBAs integriert. Sie hat neben der Redundanzabsicherung meistenteils den Effekt, im Zusammenspiel mit der Speichersystemsoftware (Firmware) ein Load-Balancing zu ermöglichen. Die Ausfallzeit ist dabei Null.

Abb. 4.36. Ausfall eines HBAs oder Ausfall einer Zuleitung

4.3.1.13.2 Ausfall eines Switches, bzw. eines Direktors Der Ausfall eines Switches oder SAN-Direktors bewirkt auf der Seite des Servers im Wesentlichen denselben Effekt wie der Ausfall eines HBAs oder der Ausfall einer Zuleitung, mit dem Unterschied, dass dieser Ausfall für sämtliche Server

174

4 Information Lifecycle Management Projekt

Abb. 4.37. Ausfall eines Switches/Direktors

stattfindet, die mit einem Pfad an diesem Switch, bzw. dem Direktor angeschlossen sind. Diese sind ab diesem Zeitpunkt nur noch über einen Pfad (d. h. nur eine Leitung und damit einpfadig) an das Speichersystem angeschlossen. Einzig die Anbindung an den Tivoli Storage Manager (TSM) und den TSMAdministrationsserver erfährt hier Einschränkungen. Da Tapedrives in der Regel keine redundante Anbindung haben, ist bei geeigneter Konfiguration die Hälfte der Tapedrives nicht verfügbar. Auch hier beträgt die Ausfallzeit Null. 4.3.1.13.3 Ausfall eines Frontend-Controllers des Speichersystems Fällt ein Frontend-Controller eines Speichersystems aus, so ist dies in etwa dem Ausfall eines Switches gleichzusetzen. Sämtliche Server, die mit einem Pfad über diesen Frontend-Controller an das Speichersystem angeschlossen sind, haben nur noch einen Zugriff auf die Platten über den zweiten oder die weiteren Zugriffspfade. Der wesentliche Unterschied zum Switch-, bzw. dem Direktor-Ausfall besteht darin, dass Zugriffe des TSM auf die Tapedrives auch weiterhin ungestört möglich sind, da hier das Speichersystem einen Mechanismus zum Failover der vom defekten Controller aus erreichbaren LUNs bereitstellen muss. Auch hier ist die Ausfallzeit Null. 4.3.1.13.4 Ausfall eines Servers Bei einem Hardwareausfall eines Servers sind tiefer greifende Maßnahmen erforderlich, um eine Applikation wieder in einen funktionsfähigen Status zu überführen. Grundsätzlich setzt dies das Vorhandensein eines Ersatzservers auf der Remoteseite (für Anwendungs- oder Server-Kombinationen und Verfügbarkeitsklassen der Datenklasse 1 der EurAmFi AG) oder eines lokalen Ersatzservers (für

4.3 Vorbereitung und Durchführung der Ausschreibung

Abb. 4.38. Ausfall eines Frontend-Controllers des Speichersystems

Abb. 4.39. Ausfall eines Serversystems

175

176

4 Information Lifecycle Management Projekt

Anwendungs- oder Server-Kombinationen und Verfügbarkeitsklassen der Datenklasse 2 der EurAmFi AG,obwohl diese keinen K-Fall-Schutz oder keine so schnelle physikalische Wiederherstellzeit erfordern) voraus. Die Umschaltung kann mittels verschiedener Verfahren erfolgen, die alle einen unterschiedlichen (Zeit-)Aufwand für die Umsetzung erfordern. Bei der Umschaltung per Cluster wird vorausgesetzt, dass nur ein spezieller Hardwareausfall vorliegt, in diesem Fall der Ausfall eines Servers oder eines Cluster-Members. Sind mehrere Komponenten betroffen, so ist es per Definition auch mit einem Cluster nicht möglich, diesen Ausfall abzudecken. Die Ausfallzeit richtet sich nach der Art der Applikation. Handelt es sich um einen Fileservice, so ist nach wenigen Sekunden ein funktionsfähiger Zustand wiederhergestellt. Bei einer Datenbank kann dieser Schaltvorgang durchaus mehrere Minuten in Anspruch nehmen. Dies ist bedingt durch die Recovery-Mechanismen der Datenbank. Der Vorgang läuft automatisiert ab. Ein händischer Eingriff ist nicht vorgesehen, ebenso wenig wie Vorlaufzeiten zur Benachrichtigung von Personal eingeplant werden müssen. Die Ausfallzeit beträgt zwischen wenigen Sekunden bis zu Minuten. Ist für die Umschaltung auf ein Cold-Standby-System am Remotestandort ein Rechner im ausgeschalteten Zustand bereitgestellt und sind für diesen alle notwendigen Vorbereitungen im Hinblick auf das Zoning im SAN durchgeführt, so kann man diesen Rechner ohne Weiteres mit den Datenbeständen vom Primärstandort starten und die Applikation aktivieren. Die Ausfallzeit beschränkt sich hier auf den Boot des Systems, den Start der Applikation und die Vorlaufzeit des Wartungspersonals. Die Ausfallzeit beträgt hier je nach Verfügbarkeit oder der Reaktionsgeschwindigkeit des Wartungspersonals zwischen 30 Minuten bis zu 4 Stunden. Die Umschaltung auf ein Hot-Standby-System hat gegenüber der Umschaltung auf ein Cold-Standby-System am Remotestandort den Vorteil, dass die Zeit des Bootens nicht verloren geht. Weiter besteht die Möglichkeit, auf dem „Ersatzsystem“ – je nach Lastanforderung – eine andere Applikation gleichzeitig zu dem zu ersetzenden Anwendungssystem zu fahren. Die Probleme, die typischerweise durch das Aktivieren der Platten des Primärsystems entstehen, müssen jetzt im Gegensatz zu einem Clustersystem entweder durch den Operator von Hand respektive durch geeignete vorbereitete Automatismen (d. h. eine semimanuelle Skriptsteuerung) durchgeführt werden. Die Ausfallzeit beträgt hier analog zur Umschaltung auf Cold-Standby-System zwischen 30 Minuten und 4 Stunden in Abhängigkeit von der Reaktionsgeschwindigkeit des Operators. Die Ausführung durch den Operator ohne geeignet dokumentierte Operationsanweisungen stellt ein zusätzliches Qualitätsrisiko dar.Eine fehlerfreie Durchführung setzt einschlägigen Erfahrungen und eine regelmäßige Übung voraus, die häufig leider nicht gegeben ist. 4.3.1.13.5 Ausfall des Primärsspeichersystems Ein Ausfall des Primärspeichersystems ist lediglich für Server- oder Anwendungskombinationen und Verfügbarkeitsklassen der EurAmFi Datenklasse 1 von Relevanz (K-Fall-Absicherung über Remote Mirroring ist vorhanden). Bei sämtlichen

4.3 Vorbereitung und Durchführung der Ausschreibung

177

weiteren Datenklassen der EurAmFi AG ist bei Ausfall des dann alleinigen Speichersystems der Zugriff auf die Daten von den Anwendungen erst wieder möglich, wenn ein Speichersystem neu beschafft und mit Daten aus der aktuellsten Datensicherung der vom Ausfall betroffenen Anwendungen befüllt worden ist. Ist bei Systemen der Datenklasse 1 jedoch der Primärspeicher ausgefallen, so ist die Existenz eines Spiegels auf der Remoteseite notwendig, damit die Applikation wieder aktiviert werden kann. Als weitere Voraussetzung gilt, dass durch den Ausfall keine fehlerhaften Informationen auf die Primärplatten geschrieben wurden, da sich dieser Fehler bei typisch synchronem Spiegelungsverhalten auf die Remoteplatten überträgt. Bei der Umschaltung durch ein Clustersystem aktiviert der Cluster die Spiegelplatten des Remote-Speichersystems. Die Ausfallzeit beträgt hier meist wenige Sekunden bis wenige Minuten. Bei der Umschaltung mit Hilfe eines Cold-Standby-Systems wird in diesem Falle das Ersatzsystem nicht benötigt. Allerdings kann das derzeit aktive System nur nach vorheriger Anpassung im SAN, d. h. durch eine Änderung im Zoning und evtl. weiterer zusätzlicher Mechanismen beim Booten (d. h. durch ein Reconfigureboot werden nicht bekannte Systemplatten aktiviert) wieder aktiviert werden. Die Ausfallzeit beträgt hier je nach Verfügbarkeit und der Reaktionsgeschwindigkeit des Wartungspersonals zwischen 2 bis 4 Stunden. Bei der Umschaltung mit Hilfe eines Hot-Standby-Systems gelten prinzipiell die Aussagen zum Umschalten über ein Cold-Standby-System. Das Remotesystem muss nicht aktiviert werden. Die Ausfallzeit beträgt auch hier je nach Verfügbarkeit und der Reaktionsgeschwindigkeit des Wartungspersonals zwischen 2 bis 4 Stunden.

4.3.1.13.6 Ausfall des Primärstandortes Beim Ausfall eines gesamten Standortes – sinnvollerweise wird der Ausfall des Primärstandortes betrachtet, der üblicherweise der produktive ist – handelt es sich um die denkbar schwerste Beeinträchtigung der IT-Produktion, den so genannten K-Fall. Der Ausfall eines gesamten Rechenzentrums stellt mehr oder weniger die Summe aller Ausfälle der vorangegangenen Beispiele dar. Bei der Umschaltung vom Primärstandort auf den Remote-Standort durch Clustersysteme werden in aller Regel so genannte spreaded Cluster (d. h. die Cluster-Member sind über größere räumliche Distanzen verteilt) eingesetzt. Der Cluster reagiert so wie bisher beschrieben und aktiviert das Remotesystem und die Spiegelplatten des Remote Speichersystems. Die Ausfallzeit liegt zwischen wenigen Sekunden bis wenigen Minuten. Eine Umschaltung mit Cold-Standby-System kann nur nach vorheriger Anpassung im SAN (d. h. eine Änderung im Zoning) und evtl. weitere zusätzliche Mechanismen beim Booten (d. h. durch ein Reconfigureboot werden bisher nicht bekannte Systemplatten aktiviert) wieder aktiviert werden. Die Ausfallzeit beträgt je nach Verfügbarkeit und der Reaktionsgeschwindigkeit des Wartungspersonals zwischen 2 bis 4 Stunden.

178

4 Information Lifecycle Management Projekt

Abb. 4.40. Ausfall des Primärspeichersystems

Abb. 4.41. Ausfall des Primärstandortes

4.3 Vorbereitung und Durchführung der Ausschreibung

179

Bei der Umschaltung ins Remote-Rechenzentrum über ein Hot-Standby-System gilt prinzipiell dasselbe wie bei der Umschaltung mit Hilfe eines Cold-StandbySystems. Auch hier beträgt die Ausfallzeit je nach Verfügbarkeit und Reaktionsgeschwindigkeit des Wartungspersonals zwischen 2 bis 4 Stunden. Da in einem solchen Falle alle Serversysteme und Anwendungen der Primärseite betroffen sind,spielt der Einsatz von Manpower bei der Wiederherstellung der Systeme eine besondere Rolle.In der Regel werdenVerfügbarkeitsklassen und SLAs für den Ausfall einzelner Systeme und Anwendungen definiert und abgeschlossen. Im Falle des Wegbruchs eines kompletten Standorts sollten in SLA-Vereinbarungen andere Wiederherstellzeiten oder eine strikte Wiederherstellungsreihenfolge festgelegt werden. 4.3.1.14 Backup-Konzept Im Zusammenhang mit der Einführung von SAN-Komponenten spielt die Neugestaltung des Backup-Verfahrens eine wichtige Rolle. Durch den Technologiewechsel ist es der EurAmFi AG jetzt erstmals möglich,die gewünschten LAN-freien (LAN-free-) Sicherungen durchzuführen. Somit wird die Belastung des LANs um den Backup-Traffic verringert. Eine weitere Möglichkeit besteht in der Einführung von virtuellen TapeLibraries (VTL) oder Disk-Libraries, mittels derer man den Engpass Tapedrives umgehen kann. Werden so genannte Filer-, bzw. Data Mover integriert, können die Daten über das NDMP-Protokoll gesichert werden. 4.3.1.14.1 LAN-free-Backup Die Steuerung des LAN-free-Backups der EurAmFi AG wird über das SAN vorgenommen. Es tauschen sich hier der SAN-Client mit einem speziellen Agenten und der TSM-Server über die zu sichernden Daten im Metaformat aus. Es gibt verschiedene Möglichkeiten, die Datenströme im SAN zu steuern. 4.3.1.14.2 SNAP-Technologie In diesem Beispiel wird die Applikation des Clients (Datenbank, Filer, . . . ) zu einem definierten Zeitpunkt in einen „konsistenten“ Stand gebracht. Darum kümmert sich entweder der Speicheragent auf dem Client oder ein vorbereitetes PreScripting, welches durch den TSM-Server angestoßen wird. Anschließend wird dem Speichersystem die Aufgabe übermittelt, ein Abbild sämtlicher LUNs des Clients „einzufrieren“ (SNAP). Diese SNAP-LUNs werden dem Backup-Server zur Sicherung direkt im SAN zur Verfügung gestellt. Die Verwendung der SNAP-Technologie hat folgende Vorteile: • Entlastung des LANs durch Verlagerung des Datenstroms in das SAN. • Höhere Backupgeschwindigkeit durch direktes Mapping der LUNs an den Backup-Server. • Sehr geringe Belastung des Backup-Clients, da die Backupzeit sich auf wenige Sekunden reduziert.

180

4 Information Lifecycle Management Projekt

4.3.1.14.3 Split Mirror Technologie Die grundsätzliche Verhaltensweise des Backups ist der eines SNAPs sehr ähnlich. Der wesentliche Unterschied der Split Mirror (SM-) Technik gegenüber der SNAP-Technik besteht darin, dass die zu sichernden LUNs dem Backup-Server am Remote-Standort zur Verfügung stehen. So ist es möglich, bei einer standortübergreifenden Sicherung die Datenströme jeweils am Standort zu lokalisieren und direkt der Tape-Library zur Verfügung zu stellen. 4.3.1.14.4 VTL-Backup Mit einer Virtual Tape Library (VTL) ist es möglich, den Engpass „Tapedrives“ zu minimieren. Zum einen kann man die Anzahl der nutzbaren Tapedrives annähernd beliebig erhöhen, andererseits sorgt die hinter der Tape-Emulation liegende Sicherung auf Platte für einen wesentlich höheren Durchsatz. Dem Backup-Server wird eine Tape-Library vorgetäuscht, auf die er im Betrieb genauso transparent im SAN wie auf reale physische Tapedrives zugreifen kann. Bei Einsatz dieses Konzeptes ist die Aufteilung der Speichersysteme in Primary(schnelle Fibre-Festplatten) und Secondary-Speicher (evtl.SATA-Platten mit hoher Kapazität) sinnvoll, um hier eine deutliche Kostenreduzierung zu ermöglichen. Im Bereich der Tape-Emulationen handelt es sich in der Regel um große kontinuierliche Datenmengen, die keine transaktionsorientierte Leistung der Speichersysteme notwendig machen. Der Nachteil der Lösung besteht darin, dass die Kosten für Tape-Librarylizenzen, bzw. Tapes im Allgemeinen recht hoch sind. 4.3.1.14.5 Server-free-Backup Beim Server-free-Backup wird die Sicherung vom eigentlichen TSM und dem Backup-Client fast gänzlich entkoppelt. Der Datenstrom wird vom Client ohne den Einfluss eines Speicheragenten direkt über einen SAN-Datamover (3rd Party Extension) auf die Tapedrives weitergereicht. Der TSM-Server fordert die zu sichernden Daten lediglich bei dem Datamover an. Aufgrund des Blocksicherungskonzeptes lassen sich nur Image-(Raw)-Sicherungen der LUNs anfertigen. Das Konzept hat trotz seiner scheinbaren Schlichtheit bisher keine große Verbreitung gefunden. 4.3.1.14.6 NDMP-Backup Genutzt wird diese Technologie vor allem im Filerbereich (NAS-Technologie), bei dem mittels NDMP-Protokoll direkt auf ein Tapedrive der Library zugegriffen wird. Der Backup-Server sorgt über eine Shared-Speicher-Option für die Nutzbarkeit der Tapedrives. Der Einsatz dieser Technologie war bislang erst bei größeren Datenmengen ökonomisch vertretbar. Erst seit etwa einem Jahr ist es möglich, die ausschließlich für NDMP-Sicherungen freigegebenen Tapedrives mit anderen Sicherungsarten zu koppeln, so dass die Auslastung und Verfügbarkeit durch die ehemals exklusive Nutzung wieder steigt.

4.3 Vorbereitung und Durchführung der Ausschreibung

181

KONCOM/IT wird allein ein SAN-basiertes Backup-Verfahren einsetzen. Aufgrund der zu sichernden Datenmengen der von KONCOM/IT betroffenen Anwendungen sollte dieses Verfahren für Anwendungen der Datenklasse 1 die SNAPTechnologie kombiniert mit einem VTL-Backup verwenden. Nach Migration der Anwendungsdaten gemäß Lebenszyklus in Datenklasse 2 werden die Daten herkömmlich auf Magnetband-Library gesichert. Die Anwendungsdaten der Datenklasse 2 sollen möglichst auf ein SNAP-Verfahren verzichten können. 4.3.1.15 IT-Sicherheits-Konzept 4.3.1.15.1 Administrations- und Berechtigungskonzept Zu Administrationszwecken wird die Einrichtung einzelner dedizierter Benutzer für die Administration der Speichersysteme sowie der SAN-Switche und der Direktoren gefordert. Somit ist ein dediziertes Auditing möglich. Weiterhin sollen Zugriffe für einzelne Benutzer in nur lesender Weise erlaubt werden. Damit wird ermöglicht, dass das Controlling-Personal aus dem Operating heraus die Überwachung der Grundfunktionalitäten durchführen kann. 4.3.1.15.2 Einbindung in das Netzwerk Es empfiehlt sich, ein getrenntes Administrationsnetz mit begrenztem Zugriff ausschließlich durch die Administratoren aufzusetzen. Ideal ist ein abgetrenntes VLAN mit eigenem Administrationsnetz. Aufgrund der rechtlichen Anforderungen an ein Konzernunternehmen wie die EurAmFi AG wird dieses Administrations-VLAN durch KONCOM/IT realisiert. 4.3.1.15.3 Sicherheitszellen KONCOM/IT betrachtet im Wesentlichen nur die Anwendungen des EurAmFiKonzerns.Der Outsourcing-Part der EurAmFi Business Services GmbH wird lediglich durch den Schwerpunktkunden OS-CARBON von KONCOM/IT tangiert. Da hier also nicht das Service-Provisioning-Geschäft der EurAmFi Business Services GmbH für unterschiedliche Service-Nehmer betroffen ist, soll auf den Einsatz von Sicherheitszellen („Lampertz-Zellen“) verzichtet werden. Die Anwendungen der OS-CARBON sollen auf dem höchsten Sicherheitsniveau der EurAmFi AG betrieben werden. Die in der Infrastruktur der EurAmFi eingesetzte Primär-, Sekundärund Tertiärtechnik hat derzeit bereits einen sehr hohen IT-Sicherheitsstandard für den Rechenzentrumsbetrieb erreicht. Die Absicherung und Versorgung der einzelnen Brandabschnitte (der einzelnen Rechenzentren) übertrifft die Anforderungen an einen gesicherten Inhouse-Rechenzentrumsbetrieb bei weitem. Auch daher ist die Implementierung von Sicherheitszellen heute nicht vorzusehen. Die Desaster Recovery (DR-) Lösung der Datenhaltung wird für die Anwendungen der Datenklasse 1 mit dem Zwei-Rechenzentren-Konzept von KONCOM/IT realisiert, um Katastrophenanforderungen gerecht zu werden. OS-CARBONAnwendungen werden Datenklasse-1-Anwendungen gleichgesetzt, um der OSCARBON diesen gesteigerten Sicherheitsvorteil zusichern zu können.

182

4 Information Lifecycle Management Projekt

4.3.1.15.4 Schutz vor Computerviren, Worms und Trojanern Virenschutz wird im Betrieb eines Storage Area Network wie beim Betrieb von Stand-alone-Systemen hostseitig realisiert. Dies umso mehr, als Speichersystemund Switchhersteller in aller Regel keine Virensoftware bereitstellen. Erst durch Konzentrationsentwicklungen nach Abschluss des Projektes KONCOM/IT kann heute davon ausgegangen werden60 , dass auch Speichersystem-Hardware- und Softwarehersteller sich mit dem Thema IT-Sicherheit im SAN auseinandersetzen und diese in ihr Produktportfolio aktiv einbauen. Virenschutz ist im Zeitraum von KONCOM/IT ein Aufgabengebiet, auf das sich diverse Unternehmungen spezialisiert haben und effektive Schutzmechanismen hostseitig anbieten. Auf diese Schutzmechanismen ist beim Betrieb des SAN der EurAmFi AG zurückzugreifen. 4.3.1.15.5 SAN-IT-Sicherheit Der Verzicht auf zusätzliche In-Bound-IT-Sicherheit im Rahmen des Projektes KONCOM/IT soll wie der Verzicht auf Sicherheitszellen begründet werden. KONCOM/IT betrachtet im Wesentlichen lediglich die Anwendungen des EurAmFiKonzerns. Der Out-Sourcing-Part der EurAmFi Business Services GmbH ist lediglich durch den Schwerpunktkunden OS-CARBON von KONCOM/IT tangiert. Da hier also nicht das Service-Provisioning-Geschäft der EurAmFi Business Services GmbH für unterschiedliche Service-Nehmer betroffen ist, soll auf zusätzliche InBound-IT-Sicherheit verzichtet werden. Die Anwendungen der OS-CARBON sollen auf dem höchsten Sicherheitsniveau der EurAmFi AG betrieben werden. Auch im zu implementierenden SAN werden somit ausschließlich Systeme in Eigenverwaltung verwendet, die einen hohen Sicherheitsstandard bei physikalischem Zugriff bieten. Daher besteht kein Bedarf an zusätzlicher IN-Band-IT-Sicherheit. Beim Zoning des SAN ist jedoch darauf zu achten, dass kein Port-Zoning, sondern WWPN-Zoning verwendet wird. Dies stellt sicher, dass innerhalb der Fibre Channel Switched Fabric bei Verlust eines Ports auf einem Switch keine administrative Änderung der Plattenzugriffspfade vorgenommen werden muss, die natürlich mit Stillstandzeiten verbunden wäre. 4.3.1.16 Wartungsverträge für Einzelkomponenten Die Verfügbarkeit der Speichersysteme und SAN-Direktoren ist das wesentliche Kriterium, an dem sich Wartungsanforderungen definieren, da unter anderem basierend auf diesen Verfügbarkeiten auch die Verfügbarkeitsklassen zur Klassifizierung der Anwendungs- und Server-Kombinationen der EurAmFi aufgebaut 60

Erst im Jahr 2006 konnte mit der Übernahme von Veritas durch den IT-Sicherheitsspezialisten Symantec die Ausweitung der IT-Sicherheits-Aktivitäten auf das SAN beobachtet werden.Auch seitens der Hardwarehersteller wurde IT-Sicherheit in das Portfolio übernommen. So übernahm EMC2 im Jahr 2006 kurz hintereinander die RSASecurity und Network Intelligence und gründete eine eigenständige Security-Division zur Entwicklung einer Common Security Platform (CSP) für SAN, NAS und CAS. Vgl. hierzu auch Seiler, Martin: EMC schluckt Network Intelligence, in: COMPUTERWOCHE 38/2006, S. 10.

4.3 Vorbereitung und Durchführung der Ausschreibung

183

wurden. Da seitens EurAmFi Business Services GmbH entsprechendes Know-how im eigenen Hause vorhanden ist, lassen sich kleinere Teilaspekte (Tausch von GBICs, Plattentausch) gegebenenfalls hausintern vornehmen und es können so Kosten reduziert werden. Dennoch empfiehlt sich anlässlich der hohen Verfügbarkeitsanforderungen an das SAN, sämtliche SAN-Komponenten (Speichersysteme und Direktoren) mit in den Wartungsvertrag mit den auszuwählenden Lieferanten aufzunehmen. Bei diesem sollte es sich um einen 24x7-Vertrag mit dem Hersteller bzw. den Lieferanten handeln, bei dem die Reaktionszeit auf 2 Stunden und die Ersatzteilliefung bzw. die Vorortbetreuung auf 4 Stunden eingegrenzt ist. Folgende Einzelkomponenten müssen mindestens vertraglich aufgenommen und deren Verfügbarkeit zugesichert sein: • Switches/Direktoren inklusive aller austauschbaren Komponenten • Softwaresupport für Switch-/Direktor-Firmware und gegebenenfalls gelieferte Applikationssoftware für bspw. das WWPN-Zoning im SAN • Speichersysteme aller drei Datenklassen inklusive aller austauschbaren Komponenten • Softwaresupport für die Software zum Management der Speichersysteme Generell ist von jedem Lieferanten ein Zugriff auf herstellerspezifische Datenbanken zu gewähren, in denen bekannte Problemfälle und deren Lösungen und mögliche Workarounds gepflegt sind. Jeder Lieferant hat darüber hinaus Kompatibilitätslisten bereitzustellen, in denen die Kombination und Verträglichkeit verschiedenster Hardware mit dem Speichersystem und den angebotenen SAN-Komponenten (Switches und Direktoren) dokumentiert sind. Dies ermöglicht die zukunftssichere Planung und Anbindung weiterer Server und Techniken an die beschaffte und dann bestehende SAN-Infrastruktur. Um die Lieferanten an dem Risiko einer voll funktionsfähigen SAN-Lösung zu beteiligen, sollte die gesamte Lösung als so genanntes Try & Buy-Konzept eingekauft werden. Erst nach erfolgreichem Durchlaufen komplexer Systemtests sollte die Gesamtlösung abgenommen und damit fakturiert werden können. Das Testkonzept war Bestandteil der Ausschreibung und ist auch in dieses Buch eingegangen (vgl. Kapitel 5). 4.3.1.17 Abhängigkeiten zu anderen Entwicklungsvorhaben Bei einer Projektgröße wie der von KONCOM/IT kam es zu den üblichen Konkurrenzsituationen um die internen Ressourcen der EurAmFi AG. Es kamen für KONCOM/IT keine größeren Abhängigkeiten mit weiteren Projekten im Hause der EurAmFi in Frage. Wie bereits in den Abschnitten zum Projektmanagement erwähnt, fand jeden Montag ein Projektmanagement-Frühstück mit den Projektleitern sämtlicher weiteren Projekte der EurAmFi AG statt. Bei diesem Frühstück wurden Synergien und Konkurrenzsituationen besprochen und bilateral gelöst.

184

4 Information Lifecycle Management Projekt

4.3.2

Die Ausschreibungsunterlagen und Informationen zur Anfrage

Folgende Ausschreibungsunterlagen und Informationen wurden an die in Frage kommenden Lieferantenunternehmen gesendet. 4.3.2.1 Die Anfrage und die beteiligten Unternehmen Die EurAmFi AG ist ein international tätiger Energieversorger mit Hauptsitz in Deutschland und mehreren Tochtergesellschaften im europäischen Ausland sowie zwei Tochtergesellschaften in den Vereinigten Staaten von Amerika. Das Hauptgeschäft der EurAmFi AG ist der Handel mit Primärenergien, also Strom, Gas und (Heiz-) Öl für deren Transport sie ein international weit verzweigtes Leitungsnetz betreibt. Hier werden an drei Übergabepunkten Öl und Erdgas aus Russland, dem Brent-Vorkommen in der Nordsee sowie den Lagerstätten im Golf von Mexiko übernommen und an die jeweiligen Kunden weitergeleitet. Die EurAmFi AG ist zusätzlich primärer Stromlieferant für mehr als 5 Millionen Haushalte in Deutschland, Frankreich und den USA. Wie eine Vielzahl von Energieversorgern besitzt die EurAmFi AG eine TK-Tochtergesellschaft (EurATel GmbH), die mehr als 4 Millionen Privat- und Firmenkunden mit Produkten der Festnetz- und Mobiltelefonie sowie mit Internetzugang versorgt. Die EurAmFi AG beabsichtigt, im Rahmen einer anstehenden Speicherkonsolidierung ein Drei-Ebenen-Modell ihrer kompletten Produktions-IT-Speicherinfrastruktur zu implementieren,um den unterschiedlichen Anforderungen an die Datenverarbeitung und Datenhaltung von Informationen über den Verlauf ihres Lebenszyklus gerecht zu werden. Das Projekt „KONCOM/IT – Konsolidierung und Compliance der IT der EurAmFi AG“ soll die 92 existierenden Speichersysteme älterer Bauart auf High-Performance-Systeme mit zugehöriger SAN-, NAS- oder iSCSI-Infrastruktur konsolidieren. Dies erfolgt mit modularen Komponenten, die neu beschafft werden. Außerdem soll sichergestellt werden, dass nach einer Datenklassifizierung der Produktivdaten sämtlicher Anwendungen der EurAmFi AG in drei Klassen (Datenklasse 1 – Hochproduktivdaten, Datenklasse 2 – NearlineDaten und Datenklasse 3 – Archivdaten) diese Klassen auf unterschiedlichen Speicherplattformen betrieben werden sollen.Daten der Datenklasse 1 sollen auf hochverfügbaren Speichermedien abgelegt werden. Diese sollen zur Sicherstellung der K-Fall-Fähigkeit als Komponenten auf die beiden RZ-Standorte Hauptverwaltung (RZ 1) und Technikzentrum (RZ 2) verteilt werden. Daten der Datenklasse 2 sollen durch ein geeignetes Verfahren lokal abgesichert werden. Ein K-Fall-Szenario ist für diese Daten nicht vorgesehen. Daten der Datenklasse 3 sollen auf einem voll „compliant“ Archivierungssystem mit Hilfe der Archivierungssoftware IXOS abgelegt werden. Im Rahmen eines Vorläuferprojektes von KONCOM/IT wurden ebenfalls die existierenden Serversysteme unterschiedlicher Hersteller (IBM/AIX, Sun/Solaris, FSC/Solaris, FSC/W2K3, FSC/LINUX) auf 384 moderne Systeme konsolidiert. Die Migration der Anwendungen und Services dieser Server auf die neuen Serverplattformen soll möglichst ohne Unterbrechung des Betriebes stattfinden.

4.3 Vorbereitung und Durchführung der Ausschreibung

185

Dieser Refresh der EurAmFi-Umgebung mit sämtlichen Services sowie mit sämtlichen Produktiv-, PreLife-, Test-Instanzen erfordert die Migration auf die High-Performance-Systeme sowie die Anpassung der datenverarbeitungs-technischen Prozesse in der neuen Umgebung, die von der EurAmFi AG betrieben wird. Bei den Services handelt es sich um die produktiven Kernapplikationen des Handels- und Abrechnungssystems der EurAmFi AG, geliefert von SAP, energieversorgerspezifische Anwendungen, basierend auf GIS-Systemen, sowie die komplette IT-Anwendungslandschaft der EurATel GmbH, inklusive einem zugekauften Rating- und Billing-System und einem CRM-System von Siebel. Die folgenden Informationen sind die Anforderungen, die die EurAmFi AG gemeinsam mit dem externen Dienstleister„WeDo-IT – IT-Projektmanagement“ erstellt hat.Die WeDoIT ist beauftragt, im Namen und Auftrag der EurAmFi AG das Pflichtenheft und die Projektausschreibung zu erstellen und die Implementierung von KONCOM/IT durch die ausgewählten Lieferanten zu planen und zu steuern. Dementsprechend übernimmt die WeDo-IT in diesem Vorhaben die Durchführung der Planung, die Unterstützung der EurAmFi AG im Ausschreibungsprozess sowie die Überwachung der Realisierung der SAN-Konsolidierung und des gesamten Projektes KONCOM/IT. Weiterhin übernimmt die WeDo-IT auf Anforderung durch die EurAmFi AG die Koordination sämtlicher notwendiger Aktionen zu dem/den Hersteller/n der Lösung für die komplette Laufzeit des Projektes. 4.3.2.2 Erwartungen an das Angebot Folgende Erwartungen verknüpft die EurAmFi AG mit den aufgrund dieser Ausschreibung eingehenden Angeboten: Mit dieser Ausschreibung beabsichtigt die EurAmFi AG, von den führenden Anbietern von SAN-Komplettlösungen Angebote für die Speicher Konsolidierung, den „tiered“Speicheransatz und die Datentypisierung und Zuordnung einzuholen. Hierbei sollen als Inhalte erkannt werden: • Los 1: Hardwarekonfiguration für die SAN-Lösung in zwei Brandabschnitten der Rechenzentren 1 (Hauptverwaltung) und 2 (Technikzentrum) der EurAmFi AG (Switches/Direktoren, LWL-Verkabelung, externe Speichersysteme) für die Datenklassen 1 (hochverfügbare Speichersysteme) und 2 (Nearline Speichersysteme). • Los 2: Hardwarekonfiguration zum Ersatz der existierenden LAN-basierten Tape-Libraries durch SAN-basierte Tape Libraries, VT-Libraries sowie Speichersysteme für Daten der Datenklasse 3 (Archivierungssysteme) (Laufwerke, SAN-Anbindung, LWL-Verkabelung). • Los 3: Integration des Gesamtsystems in den Tivoli Storage Manager inklusive Einbindung des TSM in das Hochverfügbarkeitskonzept (für Los 1 und Los 2). • Umfang der vom Anbieter erbrachten Dienstleistungen zum Aufbau, Schulung der Mitarbeiter und Test des Gesamtsystems (für sämtliche Lose) im Hause der EurAmFi AG am hier zu beschaffenden System.

186

4 Information Lifecycle Management Projekt

• Preis des angebotenen Gesamtsystems je Los sowie eine TCO-Betrachtung über die Laufzeit von 3 Kalenderjahren (für sämtliche Lose). • Übereinstimmung mit den Anforderungen gemäß Anforderungskatalog (für sämtliche Lose). • Darstellung des Software- und Hardwarekostenaufwandes für eine Dauer von 36 Monaten. 4.3.2.3 Vorgehen zur Bieterauswahl und Beauftragung Die EurAmFi AG erwartet im Angebot eine Aussage zu jeder der im Anforderungskatalog genannten technischen Forderungen an das Gesamtsystem. Der Aufforderung zur Abgabe eines Angebotes ist eine Compliance-Tabelle beigefügt. Der Anbieter wird aufgefordert, in dieser den Grad der Übereinstimmung seines Angebotes mit jedem dieser Prüfkriterien schriftlich dem Angebot beizufügen. Jeder der beteiligten Anbieter sollte für sämtliche 3 Lose ein Angebot abgeben. Es ist jedoch auch möglich, lediglich für eines der beiden Lose 1 oder 2 zu bieten. Auf jeden Fall muss die TSM-Einbindung in das Gesamtsystem (Los 3) angeboten werden, unabhängig davon ob für Los 1 und Los 2 oder nur eines der beiden Lose geboten wird. Am Ende des Ausschreibungsprozesses soll die Bestellung der SAN-Konsolidierungs- und Compliance-Lösung stehen. Die EurAmFi AG behält sich vor, die Vergabe auf mehrere Anbieter zu splitten. Ferner behält sich die EurAmFi AG vor, keines der eingegangenen Angebote anzunehmen und keinen der Anbieter mit der Lieferung zu betrauen, falls die Angebote ersichtlich den Anforderungen der EurAmFi AG nicht entsprechen. Jeder Anbieter ist aufgefordert, evtl. eingebundene Unterauftragnehmer der EurAmFi AG zu benennen. Die EurAmFi AG behält sich vor, vorgeschlagene Unterauftragnehmer in Abstimmung mit dem Anbieter abzulehnen. 4.3.2.4 Angebot als „Try- and Buy-Lösung“ Die Beauftragung wird mit einer „Try-and-Buy-“Option versehen. Das heißt, die EurAmFi AG wird bis zum Ende des Kalenderjahres die ausgewählte Lösung des/der Anbieter, der/die den Zuschlag erhalten wird/werden, einem Funktionstest gemäß dem definierten Testplan unterziehen. Entspricht die Lösung nicht den erwarteten Testergebnissen, wird die EurAmFi AG dem/den Anbietern einen angemessenen Zeitraum zur Nachbesserung zubilligen. Wird das gewünschte Ergebnis auch dann nicht erreicht, behält sich die EurAmFi AG die Rückgabe des Gesamtsystems vor. Dabei werden der EurAmFi AG keine zusätzlichen Kosten für Abbau, Transport und Versicherung des zurückgegebenen Equipments entstehen. 4.3.2.5 Angebotsfristen Sämtliche Angebotsdokumente sollen schriftlich – versehen mit den vertretungsrechtlich ausreichenden Unterschriften – in dreifacher Ausfertigung der EurAmFi AG übersandt werden. Die EurAmFi AG erwartet das Angebot ebenfalls in elektro-

4.3 Vorbereitung und Durchführung der Ausschreibung

187

nischer Form (PDF-Format) sowie die mitgelieferte Compliance-Tabelle in EXCELFormat. Die Frist zur Abgabe dieses schriftlichen Angebotes endet am 07.10.2003 um 24 Uhr – es gilt das Datum des Poststempels. Angebote, die mit einem Poststempel nach dem angegebenen Datum abgegeben wurden, sowie Angebote, die ersichtlich unvollständig abgegeben wurden (die Anforderungs-Compliance für keines der Lose ist komplett erklärt, keines der Lose ist technisch vollständig angeboten, die Kosten der angebotenen Lösung sind nicht vollständig aus dem Angebot ersichtlich), werden bei der Auftragsvergabe nicht berücksichtigt. 4.3.2.6 Fragen zur Ausschreibung Die EurAmFi AG bietet jedem der Anbieter die Möglichkeit, in einem Frage-undAntwort-Meeting am Sitz der EurAmFi AG sämtliche Unklarheiten bzgl. der Ausschreibung zu beseitigen. Alle Fragen und Antworten werden protokolliert und jedem der beteiligten Anbieter zur Verfügung gestellt. Damit soll sichergestellt werden, dass sämtliche beteiligten Bieter ihre Angebote auf Basis eines identischen Wissensstands abgeben können. Das Frage und Antwort Meeting wird mit jedem der Anbieter seitens der EurAmFi AG vorterminiert. 4.3.2.7 Ansprechpartner Für kaufmännische Fragen wenden Sie sich bitte an Herrn Dr.Jürgen von Bleuden61 (EurAmFi AG). Technische Fragen sind ausschließlich im Frage-und-AntwortMeeting zugelassen. Ansprechpartner sind hier Frau Katja Griebel (EurAmFi AG), Frau Greta Islasdottir (EurAmFi AG), Herr Bernd Kania (EurAmFi AG) sowie Herr Dr. Günter Thome (WeDo-IT). 4.3.2.8 Datenschutz- und Geheimhaltungserklärung Der Anbieter wird verpflichtet,alle Betriebseinrichtungen,Geschäftsvorgänge,Verfahren und Arbeitsweisen sowie alle Informationen, die ihm bei der Tätigkeit zur Erstellung des Angebotes zur Kenntnis gelangen, gegenüber Dritten geheim zu halten. Der Anbieter gewährleistet, dass evtl. von ihm betraute Subunternehmer diese Verpflichtung ebenso eingehen. 4.3.2.9 Ist-Situation Ziel der Ist-Aufnahme war es, alle Bestandteile und Komponenten zu erfassen, die es einem externen Anbieter ermöglichen, eine Speicherkonsolidierung und ein Compliance-Angebot für die EurAmFi AG abzugeben. Außerdem wurden gemäß der definierten Klassifizierung die Verfügbarkeitsklassen für Anwendungsund Server-Kombinationen sowie eine Verteilung der anzubietenden Kapazitäten auf Systeme der Datenklassen 1 und 2 und die Grundlage für das Angebot von Systemen der Datenklasse 3 sowie Backup- und Restore-Kapazitäten vorgegeben. 61

Für das virtuelle Projekt KONCOM/IT wurden die Namen verfälscht. Ähnlichkeiten mit natürlichen Personen wären rein zufällig und von uns nicht beabsichtigt.

188

4 Information Lifecycle Management Projekt

Die den Angeboten der Hersteller zugrunde liegenden Vorgaben umfassten im Einzelnen: • Eine Dokumentation der Netzwerkgegebenheiten. • Eine Bestandsaufnahme aller Server- und Anwendungskombinationen, deren derzeitiger Plattenplatzbedarf, sowie deren Hardware- und Betriebssystemeigenschaften. • Informationen über die verwendeten Tape-Libraries, Anzahl der Bänder, und die Größe des Speicherpools. • Grundlegende Informationen über die für KONCOM/IT verfügbaren Rechenzentren, wie allgemeine Infrastrukturdaten, verwendete und verfügbare Sekundär- (Klima, Stromversorgung, USV usw.) und Tertiärtechnologien (Zugangstechnik, Feuertechnik usw.). 4.3.2.9.1 Netzwerk Hier wurde den angeschriebenen Anbietern eine Gesamtübersicht der Netzwerkimplementierung der EurAmFi AG zurVerfügung gestellt.Diese Gesamtübersicht zeigt die Aufteilung der Netzwerkarchitektur der EurAmFi AG in beiden Rechenzentren, die Aufgliederung in netzwerktechnisch eigenständige Service-Areas für Produktion, PreLife und Test sowie Entwicklungsumgebung und das eigenständige Administrationssubnetz. Zudem wurden die Firewalls sowie die Übergabepunkte zwischen Entwicklungs-, PreLife- und Testnetz sowie zwischen PreLife und Testnetz und Produktionsnetz dargestellt. Eine Wiedergabe der Netzwerkarchitektur der EurAmFi-Systemumgebung würde den Rahmen dieses Buches bei weitem sprengen, daher soll es hier bei diesen Erläuterungen bleiben. Mit Hilfe des dedizierten Administrationsnetzes konnte eine sichere Kommunikation neben dem„öffentlichen“ LAN aufgebaut werden. Zum Zeitpunkt der Ausschreibung war kein dediziertes Backupnetz vorhanden, dieses sollte jedoch im Rahmen von KONCOM/IT aufgebaut werden. 4.3.2.9.2 Serverumgebung Die folgenden Abbildungen 4.42 bis 4.46 geben exemplarisch einen Überblick über die zum Zeitpunkt der Ausschreibung vorhandene Serverlandschaft, die im Wesentlichen aus AIX-, Solaris-, LINUX-, W2K3-, Lotus Notes- und ExchangeServern bestand. 4.3.2.9.3 AIX-Server Die folgenden Abbildungen zeigen exemplarisch die Details einiger der verwendeten AIX-Server. Die komplette Darstellung sämtlicher KONCOM/IT-Server würde den Umfang des Buches ebenfalls unnötig aufblähen, daher soll es bei dieser exemplarischen Darstellung belassen werden. Die Abbildung 4.42 beschreibt den Status Quo der AIX-Server. Der Plattenbedarf wird vorzugsweise durch lokale SCSI- bzw. SSA-Platten abgedeckt. Abbildung 4.43 beschreibt den SAN-Storage Bedarf der AIX-Server und damit den kalkulierten Plattenplatz über die Jahre 200x einschließlich einer Wachstums-

4.3 Vorbereitung und Durchführung der Ausschreibung

189

prognose für zwei Folgejahre.Ebenso findet sich eine Spalte und Summe des insgesamt benötigten Speicherbedarfs im Jahre 200x plus einer Speicherplatzprognose für zwei weitere Jahre. Hierbei wurden die Server wie folgt nach Storageklassen aufgeteilt: Tabelle 4.4. Datenklassifizierung der Serversysteme Klasse

Bedeutung

Datenklasse 2

Local Mirror (RAID 5)

Datenklasse 1

Local Mirror (RAID 5) + Snaps (Kalkulation 20 %) + Remote Mirror (RAID 5)

Die Angaben in GB beziehen sich lediglich auf den für die Server „verwertbaren“ Plattenplatz (Remote Mirror mit einbezogen), inklusive der Kalkulation für den zu erwartenden Snapbereich in der Größenordnung von 20 Prozent. Es wurden in diesen Berechnungen keine RAW-Werte für den Speicher ermittelt. Die Kalkulation für Remote Mirror und Snap ist nur in der Spalte „Brutto gesamt“ berücksichtigt (nicht in den einzelnen Jahresspalten!). Abbildung 4.44 beschreibt die Wiederherstellungsprioritäten der AIX-Server. In der Spalte „Services“ wird die Art der vom Server betriebenen Applikationen dokumentiert. Eine Spalte kennzeichnet, wann die genannten Server gegebenenfalls ersetzt werden. Diese Ersetzung wird zum Teil im Rahmen der Einführung von KONCOM/IT geschehen. Bei Maschinen, die in der Zukunft ersetzt werden sollen, sind keine Angaben für den PCI-Bus gemacht worden. Die letzte Spalte kennzeichnet die von der EurAmFi AG geforderte Wiederherstellungszeit. Die angehängte Ziffer ist lediglich eine Priorisierung für die Reihenfolge der Störungsbehebung bei Ausfall mehrerer Systeme und im K-Fall. Sie beginnen mit 1 für die bei einem Ausfall zuerst herzustellenden Systeme (Prio 1). Die beiden Abbildungen 4.45 (AIX-Server – Betriebssystemtechnische Parameter) und 4.46 (AIX-Server – RZ-Zuordnung) dokumentieren die betriebssystemtechnischen Parameter,wie Hersteller,Modell,Firmware,Bios,Betriebssystemversion, 64- oder 32-Bit-Betrieb und evtl. vorhandene FC-HBAs, die zur Ansteuerung der Tapes in der Library notwendig sind. Für sämtliche Betriebssysteme und sämtliche Server wurden die gleichen Informationen in der gleichen tabellarischen Form in den Ausschreibungsunterlagen versandt, so dass klare Vorgaben hinsichtlich Anzahl der Server und Anwendungen, deren Kapazitätsbedarf, deren Zuordnung zu den Datenklassen sowie den Zuordnungen zu den beiden Rechenzentren der EurAmFi AG vorlagen.

190

4 Information Lifecycle Management Projekt

Abb. 4.42. Status Quo für die AIX-Server

4.3 Vorbereitung und Durchführung der Ausschreibung

Abb. 4.43. SAN-Storage-Bedarf der AIX-Server

191

192

4 Information Lifecycle Management Projekt

Abb. 4.44. Wiederherstellungsprioritäten für die AIX-Server

4.3 Vorbereitung und Durchführung der Ausschreibung

Abb. 4.45. AIX-Server und ihre betriebssystemtechnische Parameter

193

194

4 Information Lifecycle Management Projekt

Abb. 4.46. AIX-Server und ihre RZ-Zuordnung

4.3 Vorbereitung und Durchführung der Ausschreibung

195

4.3.2.9.4 TSM Das Backup-Szenario der EurAmFi AG besteht zum Zeitpunkt der Durchführung der Ausschreibung aus einem Haupt-Backup-Server (adsm) und einem StandbyBackup-Server (adstech). Der Haupt-Backup-Server ist an zwei StorageTek „Powderhorn 9360“ angeschlossen, die jeweils ca. 2930 Slots enthalten. Über einen kleinen Fibre-Miniswitch sind 9 x T9940 STK-Tapedrives in der Library „acsystem1“ angeschlossen. Weitere 9 x T9840 STK-Tapedrives, die über SCSI an den HauptBackup-Server konfiguriert sind, befinden sich in der Library „acsystem0“. Am Standby-Backup-Server könnte im Havariefall die Library „acsystem1“ verfügbar gemacht werden. Die Library „acsystem0“ enthält 1.700 beschriebene Kassetten mit einer Kapazität von ca. 100 TB. Die Library „acsystem1“ enthält 1.350 beschriebene Kassetten mit einer Kapazität von ca. 152 TB. 4.3.2.9.5 Rechenzentren Es existieren insgesamt vier Infrastrukturräume, je zwei pro Rechenzentrum. Infrastrukturraum 1 in der Hauptverwaltung der EurAmFi AG und Infrastrukturraum 2 im Technikzentrum der EurAmFi AG befinden sich jeweils im Erdgeschoss. Beide Infrastrukturräume sind durch zwei Brandschutzwände und einen Zwischenraum von den übrigen Funktionsräumen der beiden Rechenzentren getrennt. Sie sind daher als getrennte Rechenzentren zu verstehen, da jeder Raum sowohl mit einer unabhängigen Klimaanlage als auch mit einer eigenständigen USV versehen ist. In diesen Räumlichkeiten sollen auch die neuen Systeme, d. h. die Server, die Speichersysteme und die SAN-Direktoren untergebracht werden. Der derzeitige flächenmäßige Nutzungsgrad beträgt etwa 10 Prozent von jeweils 1.500 qm RZStellfläche. Die Infrastrukturräume Nr.3 und Nr.4 befinden sich jeweils im 1.Obergeschoss der beiden Rechenzentren. Sie sind bezüglich Grundriss, Klima und USV analog zu den Infrastrukturräumen im jeweiligen Erdgeschoss aufgebaut. Der Nutzungsgrad liegt ebenfalls in der Größenordnung von 10 Prozent von 1.500 qm RZ-Stellfläche. Kabel können zwischen den Geschossen über entsprechende Steigschächte eingebracht werden. Die Verbindung innerhalb einer Geschossebene und durch die Steigschächte wird durch Brandschotts hindurchgeführt. Die Hochverfügbarkeit der Stromversorgung wird in den beiden Rechenzentren gewährleistet. Die Stromversorgung in beiden Rechenzentren ist generell über eine USV abgesichert. Es ist jederzeit möglich, für evtl. anstehende Wartungsarbeiten unterbrechungsfrei von einer USV auf die andere umzuschalten. 4.3.2.9.6 USV Bei den Stromversorgern handelt es sich um den Typ PILLER UNIBLOCK. Je Infrastrukturraum werden 18 Blöcke mit jeweils 220 KW betrieben.

196

4 Information Lifecycle Management Projekt

4.3.2.9.7 Klima Die Klimatisierung erfolgt durch ISOVEL-Klimaschränke mit jeweils 12 bis 20 KW Leistung. In jedem der vier Infrastrukturräume (2 in der Hauptverwaltung der EurAmFi AG und 2 im Technikzentrum der EurAmFi AG) werden betrieben: 4 × ISOVEL Zuluft 11.800 m3 /h, in Betrieb 2 × ISOVEL Zuluft 11.800 m3 /h, Standby

4.3.3

Zielumgebung

Aufgrund folgender Kriterien hat sich die EurAmFi AG für eine Speicherkonsolidierung in einem hochverfügbaren SAN (sämtliche angefragte FCSW-Devices inklusive deren Verkabelung) entschieden: Netzwerkspeicher verbessern die Speicherauslastung durch Konsolidierung. Speicherkonsolidierung: Wenn alle Server einen gemeinsamen Speicher-Pool verwenden, steigt die Auslastung deutlich, und die Speichergesamtkapazität, die angeschafft und verwaltet werden muss, sinkt. Serverkonsolidierung: Es müssen nicht mehr Server angeschafft werden, um die Zahl der Festplatten zu erhöhen – dafür sorgt das SAN. Konsolidierung des Personals: Weniger Server und weniger Speicher vereinfachen das Management. Die Verwaltung ist weniger komplex, so dass die Mitarbeiter mehr Zeit für unternehmenskritische Aufgaben haben. Business Continuity: • Reduziert das Risiko, das viele Backup-Devices und viele Backup-Kontrollpunkte mit sich bringen. • Ermöglicht Disaster-Recovery und Business-Continuity als Nebeneffekt der Speicherkonsolidierung. • Daten können konsolidiert verwaltet, kontrolliert und synchronisiert werden. Dies verbessert den Schutz der Informationen und gewährleistet die Informationssicherheit sowohl lokal als auch über große Entfernungen. Geschäftliche Flexibilität: • Besseres Wachstums- und Change-Management für neue und vorhandene Anwendungen, da mehr Personen, Anwendungen, Server und Speicher in einer Infrastruktur zusammengefasst sind. Dies erleichtert das Hinzufügen oder Erweitern gemeinsamer Funktionen auf mehr Komponenten und für mehr Benutzer. • Stellt eine einzige, konsolidierte Infrastruktur bereit, die den Informationsfluss beschleunigt, indem die Schranken zwischen unterschiedlichen Technologien und veralteten Infrastrukturen beseitigt werden, und beschleunigt den Informationsfluss zu mehr Menschen mit weniger Unterbrechungen.

4.3 Vorbereitung und Durchführung der Ausschreibung

197

• Erleichtert die Erfüllung bestehender SLAs mit bewährten Lösungen für hohe Verfügbarkeit und bietet die Flexibilität, neue SLAs schnell und problemlos umzusetzen. Verwaltbarkeit: • Zentralisiert das Speichermanagement und automatisiert die Device-Steuerung sowie die Ausführung von Aufgaben und Prozeduren in heterogenen Umgebungen. • Führt leistungsfähigere Management-Tools und Automatisierung zusammen, die das Speichermanagement vereinfachen und weniger arbeitsintensiv machen. • Ausgehend von den Anforderungen muss im Wesentlichen aufgrund der gravierenden Nachteile einer NAS-Lösung, wie • hohe Belastung des Gesamtsystems, da alle Zugriffe über gemeinsame CPU bearbeitet werden müssen (macht ein Load-Balancing erforderlich), sowie • kaum skalierbar, da der Flaschenhals bei der zentralen CPU liegt • und der Bedenken des Einsatzes von NAS-Lösungen im Exchange-Umfeld die Implementierung eines Storage Area Networks (SAN) gefordert werden.

4.3.4

Anforderungskatalog und Leistungsverzeichnis

Als Anforderungskatalog/Leistungsverzeichnis wurde den angeschriebenen Herstellern im Wesentlichen das bereits dargestellte Speicherkonzept mit den Ausschreibungsunterlagen versandt. Insgesamt wurden im Anforderungskatalog die folgenden Punkte dargestellt:62 Pre-Site-Anforderungen: Geforderte Library Funktionalität (Los 2 - Tape-Library) war eine Konfiguration zum Ersatz der existierenden Tape-Libraries (Laufwerke, SAN-Anbindung, LWLVerkabelung) sowie Integration in den Tivoli Storage Manager. Außerdem werden die Anbieter aufgefordert, für evtl. vorgesehene Migrationsunterstützungsleistungen den von ihnen vorgesehenen Tagessatz anzugeben. Jede Tape-Library sollte wenigstens mit 12 Tapedrives ausgestattet sein. Jedes der Tapedrives hat eine Mindestübertragungsgeschwindigkeit von mindestens 30 MB/s zu bieten. Der initiale Ausbau muss eine Kapazität von 500 TB fassen können. Es muss weiterhin eine Ausbaubarkeit auf 1000 TB bis zum Jahre 2005 gegeben sein. Sollten seitens des Anbieters optionale Technologien zusätzlich zur Tape-Library-Lösung angeboten werden, so müssen diese den Mindestanforderungen für die logische Wiederherstellzeit genügen. • Geforderte Speicherfunktionalität (Los 1 - SAN) • Technische Anforderung Storagesysteme und Switche (Los 1 - SAN) Speichersystem • Switches und Direktoren 62

In den Klammern finden sich die Querverweise auf die entsprechenden Abschnitte des Speicherkonzeptes in diesem Buch.

198

• • • • • • • •

4 Information Lifecycle Management Projekt

Definition der Schutzklassen LUN-Größen Anzahl HBAs Anzahl Switchports HBA-Ports ISL-Leitungen/Kapazität Failoverkonzept Backupkonzept

Die Anbieter werden aufgefordert, die ihrerseits vorgesehenen Backup-Verfahren detailliert zu beschreiben. Dabei sollen die Anbieter die technischen Anforderungen der für das redundante standortübergreifende Backup-Verfahren benötigten Administrationsserver (TSM-Server) benennen. Die TSM-Server werden seitens der EurAmFi AG außerhalb dieses Vorhabens beschafft. Das TSM muss gemeinsam mit den Speichersystemen in der Lage sein, SAN-Platten an den BackupServer mappen zu können. Dieser Vorgang ist durch Agenten zu realisieren bzw. ist Bestandteil des Integrationsverfahrens (Scripting). Es müssen von gemounteten Devices inkrementelle Backups erstellt werden können, ohne dass hierbei das „Archivbit“ des Filesystems genutzt werden muss (Sicherung von Snapshots). Ferner sollte das TSM in der Lage sein, „synthetische Backups“ herstellen und als Image wieder „restoren“ zu können (d. h. die Möglichkeit aus Voll- und Inkrementellen-Backups ein RAW-Image zu erstellen). Diese Anforderungen müssen für die Hochverfügbarkeit des TSM und der TSM-Server standortübergreifend erfüllt sein.Die TSM-Server müssen mit wenigstens 2 Prozessoren (≥ 1,5 GHz) ausgerüstet sein. Zusätzlich muss jeder Server mit wenigstens 4 LWL-HBAs (≥ 2 GbitTechnologie) bestückt sein, paarweise maximal 2 je Bus. Der Hauptspeicher muss ≥ 2 GB betragen. Diese Server werden von der EurAmFi AG gestellt.

4.3.5

Migrationsverfahren und Test der Migration

Um die Einführung des SANs im Rahmen des Projektes KONCOM/IT bei der EurAmFi AG erfolgreich durchführen zu können, ist unter anderem eine Migrationsstrategie zu erarbeiten, mit der die Daten von den lokalen Platten in das SAN gebracht werden können. Zu berücksichtigen sind außerdem mehrere inhomogene Betriebssystemlandschaften. Generell sind zwei Ansätze zur Migration der Daten denkbar: • Lokale Migration der Daten, d. h. die lokalen Daten auf den internen SCSIPlatten werden über die zusätzlich in den Server zu installierenden Fibre Channel (FC-) HBAs über ein einfaches, vom Betriebssystem gesteuertes COPY in das SAN gebracht. • Eine weitere Möglichkeit besteht in der Migration der Daten auf ein Neusystem, das in das SAN integriert ist.Dieses Verfahren wird als Verfahren der Migration über Springersysteme bezeichnet. Beide Varianten sollen in diesem Dokument erläutert werden.

4.3 Vorbereitung und Durchführung der Ausschreibung

199

Außerdem wird das Testkonzept für die verschiedenen KONCOM/IT-Plattformen beschrieben. Parallel zur Durcharbeitung des Testkonzeptes werden die Grade der Compliance der ausgewählten Speichersysteme zu den Anforderungen der EurAmFi AG geprüft und bewertet. Dieses Testkonzept bietet neben der praktischen Erfahrung, die das Betriebspersonal der EurAmFi Business Services GmbH während der Testphase sammeln kann, die Möglichkeit, Failoverstrategien zu prüfen und zu verifizieren, ohne Produktivsysteme bei ungenügendem Ergebnis zu gefährden. Das Testkonzept geht von der Beschaffung von jeweils zwei Maschinen je Betriebssystemplattform zur Durchführung der Tests aus. Für LINUX, Exchange, Lotus Notes und W2K3 kann gegebenenfalls auch dieselbe Plattform benutzt werden. Bei der Beschaffung ist lediglich auf ausreichende Ausstattung mit PCI-Slots zu achten. Sollten im Nachgang der Funktionstests, deren erfolgreiches Durchlaufen zur Abnahme der Try-and-Buy-Lösung bindend ist, durch die Lieferanten auch noch Performancetests angedacht werden, so werden seitens der EurAmFi AG Systeme zur Verfügung gestellt, die in ihrer Ausstattung typischen Produktionssystemen entsprechen. 4.3.5.1 Migration der Daten Unabhängig vom gewählten Migrationsverfahren ist der Transport der Daten von den lokalen Platten in das SAN technisch trivial. Das einzig problematische Kriterium ist die maximal mögliche Offline-Zeit der Applikation, das die Wahl des Migrationsverfahrens beeinflussen kann. Sind die seitens der EurAmFi-Konzerngesellschaften und der OS-CARBON genehmigten Offline-Zeiten für die Migrationsänderungen hinreichend lange, so dass die Daten von den lokalen Platten direkt über die einzubauenden Fibre Channel (FC-) HBA’s oder per Netzwerk auf die SAN-Platten transportiert werden können, so ist das lokale COPY der mit Abstand einfachste Weg. Sind die genehmigten Offline-Zeiten sehr kurz gehalten, kann nur der Weg über ein parallel aufgebautes Springersystem unter Einbeziehung der Backup-, Restore- und RecoveryMechanismen sowie einer abschließenden inkrementellen Kopieraktion gewählt werden. 4.3.5.1.1 Migration der Daten durch lokales COPY Zur Vorbereitung des Serversystems, dessen interne und externe SCSI-Platten migriert werden sollen, muss dieses mit mindestens zwei FC-HBAs bestückt werden. Zur Gewährleistung der Hochverfügbarkeit durch Vermeidung von SinglePoints-of-Failure werden die beiden HBAs an zwei getrennte SAN-Direktoren je Standort angeschlossen. Sehr häufig findet man eine Organisation der Switches und Direktoren vor, die diese in Portgruppen zu je 4 oder 8 Ports aufteilt. Bei der im Design der SAN-Architektur vorzunehmenden Planung der Portbestückung der Direktoren soll der Lieferant auf eine „Paarung“ achten, in der nicht hochbelastete Speicherports mit hochbelasteten Servern zusammengefügt werden, sofern sich eine solche Beurteilung bereits in der Planungsphase ermitteln lässt.

200

4 Information Lifecycle Management Projekt

Nach dem physikalischen Anschluss der HBAs mit dem SAN folgt das Patchen der Firmware der HBAs, da diese im Auslieferungszustand meist einen älteren, von den Speichersystemherstellern nicht mehr unterstützten Firmware- oder MicroCode-Stand haben. Im Speichersystem müssen die für den Server vorgesehenen LUNs erstellt und an den entsprechenden Frontend-Controller-Port gemappt worden sein. Danach erfolgt das Zoning der HBAs auf die gewünschten Frontend-Controller-Ports des Speichersystems sowie das Zuordnen der LUNs zu den Hosts (Device-Masking), gemäß den Administrationsverfahren des gelieferten Speichersystems. Im Anschluss an Zoning und Device-Masking werden diese neuen LUNs für den Host zugreifbar gemacht. Dies geschieht im Idealfall durch die betriebssystemeigenen Verfahren online oder es wird durch ein Reboot des Serversystems erzwungen. Handelt es sich bei dem zu migrierenden System um einen Cluster, so müssen die Platten-IDs der LUNs ermittelt und extern gespeichert (dumpcfg) werden. Nach dem Erstellen der Dateisysteme auf den neuen LUNs wird die Filesystemkopie durchgeführt. Unter LINUX, UNIX und AIX werden die Daten bspw. mittels des Volumemanagement-Kommandos-onlinemirror oder mit dem CPIOKommando, unter W2K3 eventuell mit robocopy – auch mehrmals inkrementell, um die Downzeit zu minimieren – von den lokalen Platten auf die neuen Devices kopiert. Eine Alternative zu diesem lokalen COPY-Verfahren ist ein Voll-Restore aus dem Backup. Ab diesem Zeitpunkt beginnt die Offline-Zeit der Applikation. Je nach Anwendung muss entweder ein letzter inkrementeller Kopiervorgang (Filer) oder ein Recover der Datenbanken vom letzten vorhandenen Redo-Log erfolgen. Nachdem das System ausgeschaltet wurde, können die „alten“ lokalen oder externen SCSI-Platten physikalisch aus dem Serversystem entfernt werden. Danach kann der Server/Cluster erneut gestartet werden. Jetzt werden die Mountpoints bzw. unter W2K3 die Laufwerksbuchstaben reorganisiert. Unter W2K3 müssen die temporär neu angelegten Laufwerksbuchstaben auf die bekannten Originalwerte umbenannt werden. Unter UNIX werden die temporären Mountpoints auf die Originalpfade zurückgesetzt. Bei Clustersystemen werden die originalen Platten-IDs eingespielt (Reskittool: diskpar, auf sämtlichen Cluster Members). Danach können Datenbanksysteme und sonstige Services wieder gestartet und die Applikation gestartet und geprüft werden. Ist dies erfolgreich, ist die Migration mit lokalem COPY abgeschlossen. Das für ein lokales COPY zu verwendende Rollbackverfahren ist denkbar einfach. Schlägt die Migration zu welchem Zeitpunkt auch immer fehl, so werden die neuen SAN-Platten vom System entfernt oder auch nur das Zoning deaktiviert. Danach können die lokalen Festplatten wieder dem System hinzugefügt werden. Nach dem Neustart des Systems ist der Rollback zur Konfiguration vor Start der Migration erfolgreich durchgeführt. Bei diesem Verfahren sind jedoch unter Windows-Clusterbedingungen stets die Festplatten-IDs vor der eigentlichen Kopie zu ermitteln (dumpcfg) und zu notieren. Nach dem Kopiervorgang müssen diese wieder auf die Platten aufgebracht werden, damit der Cluster die Platten erkennt (diskpar).

4.3 Vorbereitung und Durchführung der Ausschreibung

201

4.3.5.1.2 Migration mit Springersystem Die Migration über ein Springersystem bietet mit dem einfachen Aktivieren des Altsystems eine komplikationsfreie Fallback-Lösung. Der wesentliche Unterschied zum Migrationsverfahren des lokalen COPY besteht in der Art und Weise, wie die Daten auf das Zielsystem gelangen. Zunächst wird das Springersystem komplett für die Neuumgebung vorbereitet und installiert. Hier erhält es die neuen Platten, Zoning und Device Masking, das Filesystem etc., Datenbank-, Serversoftware und Anwendungssoftware werden installiert und für die Zielumgebung konfiguriert. Die Daten werden aus einem „Full“-Backup wiederhergestellt oder über das LAN vom Altsystem kopiert. Nun müssen folgende Schritte durchgeführt werden: • • • •

Letzte Offline-Sicherung des Altsystems Ausschalten des Altsystems Nachfahren der letzten Altsystemsicherung auf dem Springersystem Rename des Neusystems auf den Namen des Altsystems (Verlinkung in Software, Datenbank usw.) • „Sicherheitsreboot“ des Neusystems • Starten und Prüfen der Applikation Nach erfolgreicher Prüfung der Applikation ist die Migration mit Hilfe des Springersystems abgeschlossen. Das Altsystem kann abgebaut und als Springersystem für eine nächste Migration verwendet werden. 4.3.5.1.3 Die Migration von Exchange Die Migration von Exchange für die bei der EurAmFi AG eingesetzten 2-KnotenClustersysteme (je Cluster zwischen 3 und 3.000 Exchange-Anwender) wird wie folgt durchgeführt: • Einbau der Fibre Channel (FC-) HBAs in den passiven Knoten • Umschalten des Clusters auf den passiven Knoten • Einbau der Fibre Channel Adapter in den ehemals aktiven, nun passiven Knoten • Einbinden der neuen Laufwerke in den aktiven Clusterknoten • Umschalten des Clusters • Einbinden der neuen Laufwerke in den ehemals passiven, nun wieder aktiven Clusterknoten • Test der eingebundenen Laufwerke • Zug-um-Zug-Verschieben der Mailbox Stores • Deaktivieren der alten Laufwerke • Ausbau der alten SCSI-Adapter 4.3.5.2 Die Entscheidungstabelle zur Anbieterauswahl In der Entscheidungstabelle wurden die für die EurAmFi AG relevanten Parameter für die Auswahl der Technologien und Verfahren mit Punktwerten versehen und die Angebote der Anbieter hinsichtlich deren Erfüllung dieser Parameter durch die Einordnung in den Wertebereich dieser Bepunktung gewichtet. So konnte jedes

202

4 Information Lifecycle Management Projekt

der Angebote bewertet werden. Das Angebot mit der höchsten erreichten Punktzahl war das technisch und kaufmännisch interessanteste Angebot und wich am wenigsten von den Anforderungen des Pflichtenheftes ab. In der reellen Ausschreibung wurden jedoch von dem letztendlichen „Sieger“ auch nur ca. 74 Prozent der Maximalpunktzahl erreicht, was darauf hindeutet, dass keiner der beteiligten Hersteller sämtliche im Speichermarkt verfügbaren Lösungen komplett befriedigend implementieren kann. In der Entscheidungstabelle fehlen Kriterien und Parameter für die Auswahl der zur Archivierung verwendeten Speicherplattform. Hier können im Wesentlichen vier Verfahren und damit auch vier Plattformen realisiert werden: • Realisierung von Langzeitarchiven mit SATA-Techniken in Enterprise- und Midrange-Speichersystemen. Für diese Realisierungsform gelten die in der Entscheidungstabelle für Hardware-Storage aufgezählten Parameter und Bewertungskriterien; • Realisierung von Langzeitarchiven über Magnetbandtechnologien. Für diese Lösung sind die Entscheidungskriterien zur Hardware Library in der Entscheidungstabelle anzuwenden (vergl. Abbildung 4.3.5.2 (4)); • Realisierung von Langzeitarchiven über Jukeboxes, bzw. DVD; • Realisierung von Langzeitarchiven über Content-adressable-Space (CAS, Hersteller EMC2 ) oder HCMP (Hersteller Hitachi Data Systems). Für die Auswahl der beiden letzten Realisierungsmöglichkeiten für Langzeitarchivierung können wir keine Entscheidungsmatrix aufbauen. Die Realisierung der Langzeitarchive über Jukeboxes/DVD stellt Commodity dar. Hier muss in Verbindung mit der ausgewählten Archivierungssoftware und der vorhandenen Anschlusstechnik lediglich noch ein Lieferant ausgewählt werden. Bei dieser Lösung dürften langfristige Lieferantenbeziehungen und letztendlich der Preis die Entscheidung für oder gegen einen Hersteller ausmachen. Die Lösung über Content-adressable-Storage (CAS) oder HCMP wird in der Entscheidungstabelle nicht berücksichtigt, da beide Verfahren alleinstehend auf dem Markt sind. Beide Verfahren haben Vorzüge und Grenzen, können jedoch zumindest die Anforderungen erfüllen, die SATA-Technik und Magnetbandlösungen sowie auch Jukebox- und DVD-Lösungen befriedigen können. Eine Entscheidung zugunsten einer der beiden Technologien ist immer gemeinsam mit der Entscheidung über die komplette Speicherinfrastruktur zu treffen. Beide Hersteller sind als „Vollsortimenter“ in sämtlichen Bereichen des Speichermarktes aktiv. Fällt die SAN- oder NAS-Entscheidung zugunsten eines der beiden Hersteller, so ist die Wahrscheinlichkeit groß, die Archivlösung ebenfalls mit diesem Lieferanten zu betreiben. Betrachten wir nun die EurAmFi-Entscheidungstabelle, so stellt diese in den beiden linken Spalten jeweils den Parameter bzw. das Entscheidungskriterium sowie seine Gewichtung für die Entscheidungsfindung dar. Die folgenden Spalten sind mit den Herstellerangaben zu füllen. Dabei wird in der jeweils vorhandenen Spalte „P 0-5“ der Zielerfüllungsgrad für das jeweilige Kriterium vergeben. Ist ein Kriterium nicht erfüllt, so wird es hier mit 0 bewertet, ist es vollständig erfüllt, so

203

Abb. 4.47. Entscheidungsmatrix zur Anbieterauswahl (1)

4.3 Vorbereitung und Durchführung der Ausschreibung

Abb. 4.48. Entscheidungsmatrix zur Anbieterauswahl (2)

204 4 Information Lifecycle Management Projekt

205

Abb. 4.49. Entscheidungsmatrix zur Anbieterauswahl (3)

4.3 Vorbereitung und Durchführung der Ausschreibung

206

4 Information Lifecycle Management Projekt

Abb. 4.50. Entscheidungsmatrix zur Anbieterauswahl (4)

Abb. 4.51. Entscheidungsmatrix zur Anbieterauswahl (5)

4.3 Vorbereitung und Durchführung der Ausschreibung

207

208

4 Information Lifecycle Management Projekt

lautet die Bewertung 5. Das Produkt aus Wertigkeit und Zielerfüllungsgrad ergibt bezüglich des Einzelkriteriums die Punktzahl der angebotenen Herstellerlösung. So hätte bspw. eine Lösung ohne eigene USV einen Punktwert von 0 (2 × 0) zur Folge.Ist die angebotene Lösung mit einer USV ausgestattet,beträgt der Punktwert 10 (2 × 5) (vgl. Abbildung 4.3.5.2 (1)). Die Entscheidungsmatrix in den Abbildungen 4.46 (1)–(3) für die Auswahl des SAN-Equipments (Speichersysteme sowie Switche und Direktoren) ist in folgende Abschnitte untergliedert: • Anforderungen an Infrastruktur (Klimabedarf, Umgebungstemperatur, Leistungsaufnahme etc.). • Anforderung an das Management der Speichersystemhardware. • Kompatibilität zu eingesetzten Betriebssystemen und der genutzten Administrationsplattform. • Technische Daten der Speichersystemhardware. • Anforderungen an Hardware und Software der Switche und Direktoren. • Kosten der angebotenen Lösung. Die Kosten der angebotenen Lösung wurden nicht mit Gewichtung und Erfüllungsgrad versehen. Hier ist es das Geschick des Einkaufs des Unternehmens, die technisch sinnvollste Lösung zu den bestmöglichen Kosten einzukaufen. Die Ermittlung der technisch und bzgl. der Anforderungen komplettesten Lösung ist durch Addition der Punktwerte, die für die Einzelkriterien erreicht wurden, auf einfache Art und Weise zu erreichen. Die Entscheidungstabelle für die Auswahl der Datensicherungstechnik (Tape Libraries) ist in der beschriebenen Weise aufgebaut und zu handhaben. Die Entscheidungsmatrix zur Integration in ein hochverfügbares TSM (Entscheidungsmatrix zur Anbieterauswahl(5)) ist hier eine Reminiszenz an die Administrationsumgebung der EurAmFi AG. Diese ist für andere Betriebsumgebungen logisch konform anzuwenden. Bezüglich der Bewertung der Angebote mit der Hilfe des hier dargestellten Verfahrens kann kritisiert werden, dass sowohl die Gewichtung der einzelnen Kriterien, als auch die Bewertung der einzelnen Angebote subjektiv sei. Was die Gewichtung der einzelnen Kriterien anbelangt,so glauben die Autoren, eine sachlich korrekte und einer kritischen Prüfung standhaltende Lösung gefunden zu haben. Der Subjektivität der Bewertung kann lediglich durch Verfahren begegnet werden, wie sie klassisch aus Aufwandsschätzungen bekannt sind. Die Bewertung sollte von mindestens 3 Fachkräften unabhängig voneinander durchgeführt werden. Ob die Bewertung letztlich nun durch Bildung des arithmetischen Mittels der Einzelbewertungen oder durch eine weitere Runde nach Diskurs unter den Experten stattfindet, soll dem jeweiligen Einzelunternehmen vorbehalten bleiben.

5 Testkonzept zur Qualitätssicherung

Das Bewusstsein für Qualitätssicherung und für Risikomanagement muss insbesonders in ILM-Projekten sehr ausgeprägt sein. Durch das immer stärkere Gewicht der IT innerhalb der unternehmenskritischen Geschäftsprozesse und der möglichen Haftungsrisiken trotz der Einhaltung von Normen wächst das Risiko, dass auch geringe Fehler in der Leistungserbringung des Ist-Service erhebliche wirtschaftliche Auswirkungen haben. Ein wichtiger Punkt insbesondere innerhalb jedes ILM-Konzeptes ist deshalb die kontinuierliche Qualitätssicherung (QS) in Verbindung mit einem entsprechenden Qualitäts- und Risikomanagements. Der erfolgreich abgeschlossene Test der geforderten Funktionalitäten der Speichersysteme ist Voraussetzung für die letztendliche Abnahme des Gesamtsystems. Zum Test dieser Funktionalitäten wurde ein Testplan erstellt. Da zum Zeitpunkt der Ausschreibung noch nicht bekannt ist, welcher Speicherhersteller mit welcher spezifischen Technologie für KONCOM/IT ausgewählt wird, kann naturgemäß in diesem Plan nicht auf die speichersystemspezifischen Gegebenheiten eingegangen werden. So wurde ein Grundgerüst der erwarteten/gewünschten Funktionen als Basis vorausgesetzt. Diese Funktionen sind in der Entscheidungsmatrix, die der Ausschreibung beigefügt ist, definiert – die Anbieter haben im Angebot den Grad der Compliance ihrer angebotenen Lösung zu dieser Matrix zu erklären. Für die Abnahme des Systems werden laut Testplan folgende Funktionalitäten getestet: • • • • • • • •

Der Ausfall eines HBA Der Ausfall eines primären Servers Ausfall eines primären Speichersystems Der Ausfall des primären Standorts Die Wiederherstellung eines primären Servers Die Wiederherstellung des primären Standorts Das Backup eines Produktionssystems Der SNAP eines Primärsystems und das Mapping der SNAP-Geräte an den Backup-Server • Das Restore eines Primärsystems aus einem SNAP • Der SNAP der Spiegeldevices und Mapping der SNAP-Geräte an den BackupServer • Das Restore eines Systems aus dem SNAP-Spiegel

210

5 Testkonzept zur Qualitätssicherung

Alle Tests werden – so es die Administrationsumgebung der gewählten Umgebung erlaubt – sowohl mit dem GUI,als auch mit der Commandline durchgeführt.Damit ist die Überprüfung von automatisierten Vorgängen gesichert, da diese sich über Commandline-Skripte in Administrationsskripte einbinden lassen und so auch automatisch ausführbar sind. Generell ist für das Backup die Einführung von Mediaservern vorgesehen. Dies sind im Fall der EurAmFi AG Server mit dem W2K3-Betriebssystem. Erst mit Hilfe dieser Mediaserver soll es möglich sein, SAN-Backups durchzuführen. Ohne Windows Mediaserver könnte der UNIX-basierte Backup-Server lediglich RAWImages von Servern mit auf Microsoft Windows basierenden Betriebssystemen erzeugen. Zwar ist der Lese- und Schreibzugriff auf alle offiziell freigegebenen Windows-Filesysteme längst Usus,jedoch wird dies seitens Microsoft nicht offiziell unterstützt. Da auf eine offiziell unterstützte Umgebung nicht verzichtet werden kann, bleiben wir mit Mediaservern auf der sicheren Seite. Im zweiten Abschnitt des Testkonzeptes wird der Test eines Windows-Clusters beschrieben. Bei diesem Test spielt die Applikation, die auf dem Cluster betrieben wird, eine untergeordnete Rolle. Für diese muss im Wesentlichen lediglich der korrekte Zugriff auf die Daten gewährleistet sein. Von einem Test der Aktivierung der Spiegelseite im Windows Advanced Cluster-Umfeld wurde abgesehen, da die Aktivierung der Spiegelseite von diesem Cluster nicht unterstützt wird. Laut Microsoft-Spezifikation wird bei einem solchen Cluster allein von dedizierten lokalen Platten ausgegangen. Ein Umschalten auf den Remotespiegel des Speichersystems ist nur als GEOSPAN-Cluster (Spreaded Cluster) möglich. Das einzige softwarebasierte System, das ein derartiges transparentes Umschalten unter diesen Randbedingungen erlaubt, ist das von Falconstor. Dieses wird jedoch im Umfeld der EurAmFi AG nicht eingesetzt.

5.1 5.1.1

Generalisierter Testplan Revision

Datum

Version

Bearbeiter

Inhalt/Anmerkung

21.08.2003

1.0

W. Sollbach

Abgestimmter EurAmFi AG-Testplan

Abb. 5.1. Generalisierter Testplan – Testumfeld

5.1 Generalisierter Testplan

5.1.2

211

Allgemeiner Überblick – generalisierter Testplan

Abb. 5.2. Generalisierter Testplan – Testumfeld

5.1.3

Ausfall eines HBAs

Vgl. Abbildung 4.35. Tabelle 5.1. KONCOM/IT-Testprotokoll: Ausfall eines HBAs KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung: Testablauf und erwartetes Ergebnis:

Status: Bemerkung:

Simulation Ausfall eines HBAs Generierung von Plattenaktivität mit geeigneten Mitteln Abziehen eines FC-Kabels Gegebenenfalls Austausch und Konfiguration eines HostBus-Adapters im laufenden Betrieb Erwartetes Ergebnis: Keine Beeinträchtigung des Systems aufgrund Redundanz Offen  in Arbeit  erledigt 

212

5 Testkonzept zur Qualitätssicherung

5.1.4

Ausfall eines primären Servers

Vgl. Abbildung 4.36. Tabelle 5.2. KONCOM/IT-Testprotokoll: Ausfall eines primären Servers KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung:

Primärer Server fällt aus

Testablauf und erwartetes Ergebnis:

• Ausschalten des Produktionsservers und Aktivierung der

Status:

Offen  in Arbeit  erledigt 

Zonen der Primärplatten für das Testsystem Erwartetes Ergebnis: Zugriff vom Testsystem auf die Primärplatten

Bemerkung:

5.1.5

Ausfall eines Primärspeichersystems

Vgl. Abbildung 4.40. Tabelle 5.3. KONCOM/IT-Testprotokoll: Ausfall eines Primärspeichersystems KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung: Testablauf und er-wartetes Ergebnis: Status: Bemerkung:

Simulation des Ausfalls des Primärspeichersystems Je nach Integrationssituation entweder Poweroff, oder Abziehen der Fibre-Channel-Verkabelung, oder Deaktivieren sämtlicher Zonen aller FA des Primärspeichersystems Offen  in Arbeit  erledigt 

5.1 Generalisierter Testplan

5.1.6

213

Ausfall des Primärstandortes

Vgl. Abbildung 4.41. Tabelle 5.4. KONCOM/IT-Testprotokoll: Ausfall des Primärstandortes KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung:

Ausfall des kompletten Primärstandortes

Testablauf und er-wartetes Ergebnis:

Simulation durch Abziehen der ISL-Leitungen, Abziehen der Netzwerkverbindungen zum Primärspeichersystem, Ausschalten des Primärsystems Erwartetes Ergebnis: Lediglich Zoning des Testsystems an Spiegelplatten notwendig.

Status:

Offen  in Arbeit  erledigt 

Bemerkung:

5.1.7 Wiederherstellung eines primären Servers Tabelle 5.5. KONCOM/IT-Testprotokoll:Wiederherstellung des primären Servers KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung:

Wiederherstellung des primären Servers

Testablauf und er-wartetes Ergebnis:

Deaktivierung des Zugriffs durch das Testsystem auf die Primärplatten (Entfernen der Zone) Erwartetes Ergebnis: Aktivierung des Primärsystems ist problemlos möglich.

Status:

Offen  in Arbeit  erledigt 

Bemerkung:

214

5 Testkonzept zur Qualitätssicherung

Abb. 5.3. Generalisierter Testplan – Wiederherstellung des primären Servers

5.1.8 Wiederherstellung des Primärstandortes Tabelle 5.6. KONCOM/IT-Testprotokoll:Wiederherstellung des primären Standortes KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung: Testablauf und er-wartetes Ergebnis:

Status: Bemerkung:

Wiederherstellung der Funktionalität des Primärstandortes • Zugriff des Testsystems auf die Spiegelplatten unterbinden (Zone entfernen) • Spiegelrichtung in Richtung Primär-LUN drehen • Vollständige Synchronisation abwarten • Spiegelrichtung in Richtung Spiegel-LUN drehen • Produktionshost starten Erwartetes Ergebnis: Der Produktionshost startet ohne Probleme. Die Produktionsumgebung arbeitet fehlerfrei. Offen  in Arbeit  erledigt  Frage nach inkrementeller Synchronisation

5.1 Generalisierter Testplan

215

Abb. 5.4. Generalisierter Testplan – Wiederherstellung des Primärstandortes

5.1.9

Backup eines Produktionssystems Tabelle 5.7. KONCOM/IT-Testprotokoll: Backup eines Produktionssystems KONCOM/IT

Testdurchführung: Testdatum: Testbeschreibung: Testablauf und er-wartetes Ergebnis:

Status: Bemerkung:

Betrieb der Produktion auf den primären Platten und des Testsystem auf den Spiegelgeräten der Produktionsplatten • Spiegel auftrennen zwischen Primär- und Sekundär-LUN • Zoning des Zugriffs vom Testsystem auf Spiegel-LUN • Aktivierung des Testsystems auf Spiegel-LUN • Gegebenenfalls Deaktivierung der Applikation auf Testsystem Erwartetes Ergebnis: Trennung und Backup von Spiegel ist erfolgreich. Offen  in Arbeit  erledigt  Prüfen, ob bei gelieferter Hardware ein inkrementeller Spiegelaufbau möglich ist.

216

5 Testkonzept zur Qualitätssicherung

5.1.10

SNAP von Primärsystem und Mapping an BackupServer

Tabelle 5.8. KONCOM/IT-Testprotokoll: SNAP Primärsystem/Mapping an Backup-Server (1) KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung:

• Generierung eines SNAPs einer primären LUN • Mapping des SNAPs an den Backup-Server

Abb. 5.5. Generalisierter Testplan – Backup eines Produktionssystems

5.1 Generalisierter Testplan

217

Tabelle 5.9. KONCOM/IT-Testprotokoll: SNAP Primärsystem/Mapping an Backup-Server (2) Testablauf und er-wartetes Ergebnis:

Status: Bemerkung:

KONCOM/IT Das Produktionssystem wird in einen konsistenten Zustand versetzt (Filesystem-Agent, Online Backup). Danach wird der SNAP erzeugt. Überprüfung der Primär-LUN durch Erstellung von Prüfsummen (MD5). Darauf folgend wird der SNAP an den Backup-Server gemappt und dort sichtbar gemacht. Danach kann gegebenenfalls testweise ein Backup der LUN stattfinden. Abschließend prüfen, ob LUN arbeitsfähig (Schreiben von Daten auf SNAP). Erwartetes Ergebnis: Erwartet wird eine schreibfähige LUN. Offen  in Arbeit  erledigt  Sinnvolle Durchführung nur mit UNIX-Hosts möglich (homogene Systemlandschaft)

Abb. 5.6. Generalisierter Testplan – SNAP Primärgeräte/Map SNAP-Geräte an Backup-Server

218

5 Testkonzept zur Qualitätssicherung

5.1.11

Restore eines Primärsystems aus einem SNAP Tabelle 5.10. KONCOM/IT-Testprotokoll: Restore aus einem SNAP KONCOM/IT

Testdurchführung: Testdatum: Testbeschreibung: Testablauf und er-wartetes Ergebnis:

Status: Bemerkung:

Restore aus einem zuvor generierten SNAP Nach der Deaktivierung (unmount) der Primär-LUN am Produktionssystem wird die LUN vom Backup-Server getrennt. Danach wird der SNAP auf der Primär-LUN wiederhergestellt. Nach vollständiger Synchronisationmuss evtl.der SNAP entfernt werden. Im Anschluss daran wird die LUN am Produktionsserver gemappt und die MD5-Summen überprüft. Erwartetes Ergebnis: Gleiche MD5-Summen, Restore erfolgreich. Offen  in Arbeit  erledigt 

Abb. 5.7. Generalisierter Testplan – Restore aus einem SNAP

5.1 Generalisierter Testplan

5.1.12

219

SNAP der Spiegelgeräte und Mapping der SNAP-Geräte an Backup-Server Tabelle 5.11. KONCOM/IT-Testprotokoll: SNAP der Spiegelgeräte KONCOM/IT

Testdurchführung: Testdatum: Testbeschreibung: Status: Testablauf und er-wartetes Ergebnis:

SNAP der Spiegel-LUN des Produktionssystems, Mapping des SNAP an Backup-Server Offen  in Arbeit  erledigt  Das Produktionssystem wird in einen konsistenten Zustand versetzt (Filesystem-Agent, Online-Backup). Danach wird ein Spiegel-SNAP erzeugt, die Prüfsummen (MD5) werden auf der Primär-LUN gebildet. Anschließend werden die SNAPGeräte an den Backup-Server gemappt und dort sichtbar gemacht. Gegebenenfalls testweise Backup der LUN. Prüfen, ob die LUN arbeitsfähig ist (Schreiben von Daten auf SNAP). Erwartetes Ergebnis: Funktionsfähiges Backup.

Bemerkung:

Abb. 5.8. Generalisierter Testplan – SNAP der Spiegelgeräte

220

5 Testkonzept zur Qualitätssicherung

5.1.13

Restore eines Systems aus dem SNAP-Spiegel

Abb. 5.9. Generalisierter Testplan – Restore aus SNAP der Spiegelgeräte

5.2 Testplan Windows-Cluster

221

Tabelle 5.12. KONCOM/IT-Testprotokoll: Restore aus SNAP der Spiegelgeräte KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung: Testablauf und erwartetes Ergebnis:

Status: Bemerkung:

Restore des Produktionssystems aus einem SNAP auf der Spiegelseite • Deaktivierung (unmount) der Primär-LUNs in der Produktion • Entfernen der LUN vom Backup-Server • Drehen der Spiegelrichtung von Spiegel-LUN auf PrimärLUN • Restore des SNAPs auf die Spiegel-LUN • Volle Synchronisation abwarten • (evtl. SNAP entfernen) • Drehen der Spiegelrichtung von Primär-LUN auf SpiegelLUN • Aktivierung (mount) der Primär-LUN • Prüfen der MD5-Summen Erwartetes Ergebnis: MD5-Summen stimmen überein. Restore war erfolgreich. Offen  in Arbeit  erledigt 

5.2 Testplan Windows-Cluster 5.2.1 Datum

Revision Version

Bearbeiter

Inhalt/Anmerkung

222

5 Testkonzept zur Qualitätssicherung

5.2.2

Konfigurationsorientierte Tests

Abb. 5.10. Testumgebung Windows-Cluster

5.2.3

Namensauflösung Tabelle 5.13. KONCOM/IT-Clustertest: Namensauflösung KONCOM/IT

Testdurchführung: Testdatum: Testbeschreibung: Testablauf und Ergebnis:

Status: Bemerkung:

Auflösung von IP-Adressen und Hostnamen Überprüfung der Namensauflösung für alle Server und Cluster-IPs - ping <Servername> offen  in Arbeit  erledigt 

5.2 Testplan Windows-Cluster

5.2.4

223

Servicerelevante Tests

5.2.4.1 Online-Austausch HBA Tabelle 5.14. KONCOM/IT-Clustertest: Online-HBA-Tausch KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung: Testablauf und Ergebnis: Status: Bemerkung:

Online-Austausch eines Host-Bus-Adapters Austausch und Konfiguration eines Host-Bus-Adapters im laufenden Betrieb offen  in Arbeit  erledigt 

5.2.4.2 Failover-Tests Clustermember 1 5.2.4.2.1 Manuelles Failover Clustermember 1 Tabelle 5.15. KONCOM/IT-Clustertest: Manuelles Failover von Clustermember 1 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit und online: – Netzwerk: – FC-Anschluss: Durchführung eines manuellen Failovers von Clustermember 1. Die Anwendung ist auf Clustermember 1 online. Während des Umschaltvorganges wird in der Anwendung gearbeitet. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Clustermember 2 übernimmt alle Funktionen des Clustermember 1. Kurze Unterbrechung im Zugriff auf die Anwendung.

Testablauf und Ergebnis: Status: Bemerkung:

offen  in Arbeit  erledigt 

224

5 Testkonzept zur Qualitätssicherung

5.2.4.2.2 Manuelles Failback Clustermember 1 Tabelle 5.16. KONCOM/IT-Clustertest: Manuelles Failback des Clustermember 1 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis: Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk: – FC-Anschluss: Clustermember 1 ist offline, Clustermember 2 ist online! Durchführung des manuellen Failbacks des Clustermember 1. Während des Umschaltvorganges wird in der Anwendung gearbeitet. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Clustermember 1 übernimmt seine ursprünglichen Funktionen bei einer kurzen Unterbrechung in der Anwendung. offen  in Arbeit  erledigt 

5.2.4.2.3 Power-off-Failover Clustermember 1 Tabelle 5.17. KONCOM/IT-Clustertest: Power-off-Failover von Clustermember 1 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis: Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk: – FC-Anschluss: Ausschalten von Clustermember 1 durch Ziehen der Stromkabel im laufenden Betrieb. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Automatisches Failover: Clustermember 2 übernimmt alle Funktionen vom Clustermember 1. offen  in Arbeit  erledigt 

5.2 Testplan Windows-Cluster

225

5.2.4.2.4 Failover Clustermember 1 – Trennung vom Public LAN Tabelle 5.18. KONCOM/IT-Clustertest: Failover Clustermember 1-Trennung vom Public LAN KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Während des Tests wird in der Anwendung gearbeitet. Ziehen des Netzwerkkabels vom Public LAN. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Automatisches Failover: Clustermember 2 übernimmt alle Funktionen vom Clustermember 1. Dabei sollten keine Auswirkungen am Client sichtbar sein. offen  in Arbeit  erledigt 

5.2.4.2.5 Fail-Save-HBA Clustermember 1 – Trennung einer FC-Verbindung zum Speicher-system Tabelle 5.19. KONCOM/IT-Clustertest: Trennung einer FC-Verbindung zum Speichersystem KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis: Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss In der Anwendung wird zum Testzeitpunkt gearbeitet. Ziehen eines FC-Kabels von einem der beiden HBAs. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Der redundante HBA übernimmt die Funktion des ausgefallenen HBA. Am Client sind keine Auswirkungen sichtbar. offen  in Arbeit  erledigt 

226

5 Testkonzept zur Qualitätssicherung

5.2.4.2.6 Fail-Save-HBA Clustermember 1 – Trennung beider FC-Verbindungen zum Speichersystem Tabelle 5.20. KONCOM/IT-Clustertest: Trennung beider FC-Verbindungen zum Speichersystem KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss In der Anwendung wird zum Testzeitpunkt gearbeitet. Ziehen beider FC-Kabel von beiden HBAs des Clustermember 1. Ermittlung des Zeitbedarfs und Dokumentation der ClientReaktionen. Automatisches Failover von Clustermember 1 auf Clustermember 2. Am Client sind keine Auswirkungen sichtbar. offen  in Arbeit  erledigt 

5.2.4.2.7 Split Brain Clustermember 1 – Trennung aller Netzwerkverbindungen Tabelle 5.21. KONCOM/IT-Clustertest: Split-Brain-Test Clustermember 1 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss In der Anwendung wird zum Testzeitpunkt gearbeitet. Von sämtlichen Netzwerkkarten werden die Netzwerkkabel gezogen. Ermittlung des Zeitbedarfs und Dokumentation der ClientReaktionen. Die Clustermember befinden sich in einem undefinierten Zustand und jeder will der Master sein. Die im Cluster betriebene Anwendung wird abstürzen. offen  in Arbeit  erledigt 

5.2 Testplan Windows-Cluster

227

5.2.4.3 Failover-Tests Clustermember 2 5.2.4.3.1 Manuelles Failover – Clustermember 2 Tabelle 5.22. KONCOM/IT-Clustertest: Manuelles Failover Clustermember 2 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Durchführung eines manuellen Failovers des Clustermember 2. Während des Umschaltvorganges wird in der Anwendung gearbeitet. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Clustermember 1 übernimmt alle Funktionen von Clustermember 2. Kurze Unterbrechung der Netzwerkverbindung bei der Arbeit in der Applikation. offen  in Arbeit  erledigt 

5.2.4.3.2 Manuelles Failback – Clustermember 2 Tabelle 5.23. KONCOM/IT-Clustertest: Manuelles Failback Clustermember 2 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Clustermember 1 ist offline, Clustermember 2 ist online! Durchführung des manuellen Failback von Clustermember 2.Während des Umschaltvorganges wird in der Anwendung gearbeitet. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Clustermember 2 übernimmt seine ursprünglichen Funktionen. Kurze Unterbrechung der Netzwerkverbindung bei der Arbeit in der Applikation. offen  in Arbeit  erledigt 

228

5 Testkonzept zur Qualitätssicherung

5.2.4.3.3 Power-off-Failover Clustermember 2 Tabelle 5.24. KONCOM/IT-Clustertest: Power-off-Failover Clustermember 2 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Ausschalten von Clustermember 2 durch Ziehen der Stromkabel im laufenden Betrieb. Zur Zeit des Power-off-Failover wird in der Anwendung gearbeitet. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Automatisches Failover. Clustermember 1 über-nimmt alle Funktionen von Clustermember 2. Kurze Unterbrechungder Netzwerkverbindung bei der Arbeit in der Anwendung. offen  in Arbeit  erledigt 

5.2.4.3.4 Failover Clustermember 2 – Trennung vom Public LAN Tabelle 5.25. KONCOM/IT-Clustertest: Failover Clustermember 2 – Trennung vom Public LAN KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Zum Zeitpunkt der Störung wird in der Anwendung gearbeitet. Ziehen des Public-LAN Netzwerkkabels. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Automatisches Failover. Clustermember 1 übernimmt alle Funktionen von Clustermember 2. Kurze Unterbrechungder Netzwerkverbindung bei der Arbeit in der Anwendung. offen  in Arbeit  erledigt 

5.2 Testplan Windows-Cluster

229

5.2.4.3.5 Fail-Save-HBA Clustermember 2 – Trennung einer FC-Verbindung zum Speichersystem Tabelle 5.26. KONCOM/IT-Clustertest: Trennung einer FC-Verbindung zum Speichersystem KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Zum Zeitpunkt der Störung wird in der Anwendung gearbeitet. Ziehen des FC-Kabels von einem der beiden HBAs. Ermittlung des Zeitbedarfs und Dokumentation der ClientReaktionen. Der redundante HBA übernimmt die Funktion des ausgefallenen HBA. Auf dem Client sind keine Auswirkungen zu bemerken. offen  in Arbeit  erledigt 

5.2.4.3.6 Split Brain Clustermember 2 – Trennung aller Netzwerkverbindungen Tabelle 5.27. KONCOM/IT-Clustertest: Split-Brain-Test Clustermember 2 KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung:

Erwartetes Ergebnis:

Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss In der Anwendung wird zum Testzeitpunkt gearbeitet. Von sämtlichen Netzwerkkarten werden die Netzwerkkabel gezogen. Ermittlung des Zeitbedarfs und Dokumentation der Client-Reaktionen. Die Clustermember befinden sich in einem undefinierten Zustand und jeder will der Master sein. Die im Cluster betriebene Anwendung wird abstürzen. offen  in Arbeit  erledigt 

230

5 Testkonzept zur Qualitätssicherung

5.2.4.4 Skalierungsmöglichkeiten 5.2.4.4.1 Erweiterung des Filesystems Tabelle 5.28. KONCOM/IT-Cluster-Skalierungstest: Erweiterung des Filesystems KONCOM/IT Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung: Erwartetes Ergebnis: Testablauf und Ergebnis: Status: Bemerkung:

Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Beschreibung LUN/Größe/Mapping der LUN Online-Extension einer LUN im Speichersystem Cluster läuft ohne Beeinflussung weiter, Filesystem ist erweitert. offen  in Arbeit  erledigt 

5.2.4.4.2 Hinzufügen eines Filesystems Tabelle 5.29. KONCOM/IT-Cluster-Skalierungstest: Hinzufügen eines Filesystems Testdurchführung: Testdatum: Ausgangssituation:

Testbeschreibung: Erwartetes Ergebnis: Testablauf und Ergebnis: Status: Bemerkung:

KONCOM/IT Generierung einer zusätzlichen LUN für das System Clustermember 1 und 2 sind mit folgender Konfiguration betriebsbereit: – Netzwerk – FC-Anschluss Beschreibung LUN/Größe/Mapping der LUN Aktivierung der zusätzlichen LUN. Online Hinzufügen eines neuen Filesystems. Hinzufügen und Aktivieren der LUN erfolgt problemlos online. Das Online-Hinzufügen des Filesystems funktioniert. offen  in Arbeit  erledigt 

5.3 Backup und Restore

5.3 5.3.1

231

Backup und Restore Erstellen eines Snapshots Tabelle 5.30. KONCOM/IT-Testplan: Erstellen von Snapshots KONCOM/IT

Testdurchführung: Testdatum: Testbeschreibung:

Testablauf und Ergebnis:

Status: Bemerkung:

5.3.2

Erstellen mehrerer Snapshots als schnelle Lösung für Backup und Restore; Test der beiden Möglichkeiten: manuell und automatisch. • Manuelles Erstellen eines/mehrerer Snapshots • Zeitgesteuertes, automatisches Erstellen von Snapshots, z.B. 10:00, 12:00 und 22:00 Uhr. offen  in Arbeit  erledigt 

Backup und Restore einzelner Dateien und Verzeichnisse mit Snapshots

Tabelle 5.31. KONCOM/IT-Testplan: Backup und Restore einzelner Dateien und Verzeichnisse mit Snapshots KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung:

Testablauf und Ergebnis:

Status: Bemerkung:

Erstellen eines Snapshots als Backup. Anschließend Restore von einzelnen Dateien und Verzeichnissen aus dem Snapshot. Manuelles Erstellen eines Snapshots. Löschen einzelner Dateien bzw. dedizierter Verzeichnisse auf dem Originallaufwerk.Manuelles Erstellen eines zweiten Snapshots nach dem Löschvorgang. Wiederherstellen der Dateien und Verzeichnisse aus dem ersten Snapshot (via Drag & Drop). Überprüfung der Dateien und Verzeichnisse (Freigaben, Rechte und Inhalt). Wiederherstellen der Dateien und Verzeichnisse aus dem zweiten Snapshot (via Drag & Drop). Überprüfung der Dateien und Verzeichnisse (Freigaben, Rechte und Inhalt). offen  in Arbeit  erledigt 

232

5 Testkonzept zur Qualitätssicherung

5.3.3

Backup und Restore kompletter Datenträger mit Snapshots

Tabelle 5.32. KONCOM/IT-Testplan: Backup und Restore kompletter Datenträger und Snapshots KONCOM/IT Testdurchführung: Testdatum: Testbeschreibung: Testablauf und Ergebnis:

Status: Bemerkung:

5.4

Erstellen eines Snapshots als Backup und anschließendes Restore des kompletten Datenträgers aus diesem Snapshot. Manuelles Erstellen eines Snapshots. Löschen des Datenträgers, von dem der Snapshot erstellt wurde. Erstellung eines neuen, leeren Datenträgers. Wiederherstellung der Daten aus dem Snapshot in dem neuen Datenträger. Überprüfung der Dateien und Verzeichnisse (Freigaben, Rechte und Inhalt). offen  in Arbeit  erledigt 

Ermittlung der SAP-Datenbanklast für einen Testvergleich bei Inbetriebnahme des SAN

In SAP wird der Report RBDLSMAP erzeugt. Um einen verlässlichen Mittelwert zu erhalten, wird der Test zu unterschiedlichen Zeiten mehrfach wiederholt. Dieser Report liest eine Vielzahl von Datenbanktabellen verstreut über mehrere physikalische Datenträger aus und gibt somit einen guten Querschnitt über die PlattenI/O-Performance. Als Vergleichswert werden absolute Zeitdauer und durchschnittliche Zugriffszeiten ausgewiesen. Damit soll die Performance eines Systems mit „konventionellen“ DAS-Platten (DAS – Direct Attached Storage) und eines Systems im SAN verglichen werden. Zum Test des Backup- und Restore-Verhaltens von SAP im SAN wird untersucht, wie sich das Originalsystem nach einem Snapshot und anschließendem Backup des Snapshots bei gleichzeitiger hoher DB-Belastung verhält. Die Simulation eines solchen Verhaltens kann mit der Transaktion SGEN und der damit verbundenen Nachgenerierung aller oder einzelner Teile der vorhandenen ABAPLoads erreicht werden.

5.5 Test der Datentypisierung und Archivierung

233

Abb. 5.11. SAP-I/O-Performance – der Report RBDISMAP

5.5 Test der Datentypisierung und Archivierung Im Stadium der Ausschreibung konnte für KONCOM/IT noch kein Testplan für den Test der Hardwarearchitektur der Datenklasse 3 erstellt werden. Zu diesem Zeitpunkt war noch nicht abzusehen, welche Hardwarekonzeption zum Zuge kommen wird. Alternativ waren zwei Ansätze vorgesehen: • Bereitstellung von Tier-3-Speicher in den Speichersystemen der Datenklassen 1 oder 2 (SATA-Magnetplatten) • Bereitstellung eines CAS-Systems (zum damaligen Zeitpunkt lediglich von EMC2 angeboten) Bei der ersten Variante konnten die bereits dargestellten SAN-Tests auch für die Datenklasse 3 verwendet werden. Alternative 2 war gemäß den Ausschreibungsunterlagen ebenfalls remote redundant auszulegen. Hier musste der interne Kopiermechanismus einem Test unterzogen werden. Da die CAS-Umgebung jedoch bereits zum damaligen Zeitpunkt den Compliance-Status der ISACA zertifiziert hatte, musste – falls diese Variante den Zuschlag erhielt – lediglich eine Funktionsprüfung stattfinden. Ansonsten bestanden die Datentypisierungs- und Archivierungstests aus Funktionstests der eingesetzten Archivierungssoftware IXOS sowie der Anwen-

234

5 Testkonzept zur Qualitätssicherung

dungen, die die Archivierungsfunktionen bereitstellten. Die für diese Anwendungen, hauptsächlich • • • • •

SAP, Siebel, Microsoft Exchange, Lotus Notes und Oracle,

zu testenden Archivierungsvorgänge und Wiederherstellungsvorgänge wurden im Rahmen des Projektes in anwendungsspezifischen Testplänen dokumentiert und im Funktions- und Integrationstest erfolgreich getestet. Die Darstellung der einzelnen Testpläne würde den Rahmen dieses Buches bei weitem sprengen, daher verzichten wir an dieser Stelle darauf.

6 Datenklassifizierung

Das Management von unstrukturierten Daten ist zurzeit eines der größeren unaufgeklärten Probleme der Speichertechnologien (vergl. Kapitel 2.8 Schlüsselfaktor Klassifizierungskonzepte). Noch sind über 80 Prozent der gespeicherten Daten unstrukturiert und entziehen sich so einem ökonomischen ILM-Prozess. Die Herausforderung der prozesskonformen Bereitstellung besteht jedoch für strukturierte und unstrukturierte Daten. Kommt jedoch eine gut durchdachte Datenklassifizierung zum Einsatz, so lassen sich unterschiedliche Strategien leichter umsetzen und auch spezifische Service Level Agreements (SLA) einhalten. Konzepte wie ILM mit mehrstufigem Speicher, Risikoverminderung, Einhaltung gesetzlicher Regelungen oder optimiertes Projektmanagement stellen dann keine unerfüllbaren Wünsche dar.

6.1

Speicherklassifizierungskonzepte

Auf der Basis der im Band 1 dieses Werkes „Grundlagen und Modelle des Information Lifecycle Management“ vorgestellten ILM-Modelle erfolgt die notwendige Klassifizierung der Daten. Die Klassifizierung ist dabei ein zentraler Eckstein für den Erfolg des ILM-Modells. Eine allgemeine Klassifizierung von Daten geschieht üblicherweise in Form einer Einordnung in eine drei- bis fünfstufige Gruppe bzw. Skala. Die Kernaufgabe besteht darin, die Geschäftsprozess-Anforderungen auf die verschiedenen Speicherklassen im Rahmen eines Tiered-Storage-Modells umzurechnen. Ziel ist, • den Speicher, dem „Business“entsprechend (Demand), mit niedrigen Kosten und hoher Qualität (Zeit, Funktion) bereitzustellen, sowie • die Trennung der Schichten Anforderung und Lieferung. Der Prozess der Klassifizierung assoziiert Dateien mit Metadaten und/oder Inhalten wie zum Beispiel Kategoriethema, Nutzername, Entstehungsdatum, Änderungsdatum, Inhalt und andere Kriterien. Somit kann ein Mitarbeiter nach verschiedenen Parametern suchen, um die Informationen zurückzuholen oder sie entsprechend ihrem Wert zu verwalten. Eine Klassifizierung identifiziert ebenso Gemeinsamkeiten in Dokumenten, was ungewollten Redundanzen vorbeugt. Das

236

6 Datenklassifizierung

Abb. 6.1. Branchenspezifische Abhängigkeiten63

Clustering gruppiert Dateien nach Wortähnlichkeiten oder miteinander verbundenen Informationen.In einer Taxonomie sind die Informationen in logische Hierarchien strukturiert, die die Daten in spezifische Klassen einteilen. Das jeweilige Unternehmen bestimmt diese Hierarchien nach seinen eigenen Anforderungen, beispielsweise einer Einteilung nach Abteilungen oder nach Applikationen. Erst die Datenklassifizierung gliedert alle Daten im Unternehmen in Kategorien mit bestimmten Attributen. Zu erreichen ist das durch die Klassifizierung der Daten und die Aufteilung der Informationsinfrastruktur in unterschiedliche Speicherebenen (Tiered Storage). Allerdings steigt dadurch die Komplexität der IT, und der Verwaltungsaufwand wächst. Die Verantwortlichen benötigen deshalb Lösungen, die die Administration heterogener Umgebungen vereinfachen und die Mobilität von Informationen steigern. Zum Klassifizierungsvorgang gehört, dass jede Gruppe anhand gemeinsamer Eigenschaften näher definiert wird (zum Beispiel ähnliche Serviceziele). Erst die Klassifizierung schafft die Voraussetzung für ILM und stellt demzufolge den ersten Schritt dar: • Mit dem Aufbau des Prozesses zur Klassifizierung für Speicherklassen werden die Grundlagen für eine weitere Klassifizierung der Information zum ILM erarbeitet. 63

Kleineaschoff, Ulrich: Unternehmenspräsentation T-Systems, 2004.

6.1 Speicherklassifizierungskonzepte

237

Abb. 6.2. Bildung von Speicherklassen als erster Schritt

• Bei der Einführung von ILM müssen technische Lösungen und Prozesse eingerichtet werden. Die Frage nach der Klassifizierung kann jedoch nur unternehmensspezifisch beantwortet werden. Ausschlaggebend dabei sind die jeweilige Ausgangssituation und die branchenspezifischen Anforderungen. Zum Beispiel ergibt sich bei einer Bank eine andere Antwort als beim im Abschnitt 6.4.4.1 ausführlich beschrieben Fallbeispiel. Die aktuell anspruchsvollsten Anforderungen kommen aus dem Trader-Bereich von Banken. Hier gibt es Transaktionsdaten, die innerhalb von Millisekunden abgerufen werden müssen. Weniger aktuelle Informationen, zum Beispiel ein abgeschlossener Konteneröffnungsantrag, werden nur noch selten für Data Mining oder für das Berichtswesen benötigt. Dennoch müssen sie revisionssicher über einen bestimmten Zeitraum vorgehalten werden. Wieder andere Daten sind innerhalb kürzester Zeit veraltet und können oder müssen sogar gelöscht werden. Erst wenn klar ist, welche Informationen vorhanden sind und welche Anforderungen sie an ihren Speicherort stellen, lassen sich die nötigen Servicelevels für die Speicherumgebung formulieren. Der erste Schritt in Richtung einer Tiered-Storage-Umgebung beginnt somit mit der Erfassung und Klassifizierung aller im Unternehmen vorhandenen Daten. Dabei geht es um den Wert der Informationen für das Unternehmen: • Wie kritisch ist jede einzelne Datei und jeder Datensatz für die Geschäftsprozesse?

238

6 Datenklassifizierung

Abb. 6.3. Die Veränderungen der Systemarchitektur64

• Gibt es rechtliche Archivierungsvorgaben? • Welche Anwendungen benötigen sie, und in welcher Form greifen sie darauf zu? Dabei ist zu beachten, dass sich die Systemlandschaft von Applikation zu Server und Speicher verändert, und sich von einer 1:1:1-Beziehung zu einer N:N:NBeziehung wandelt. Voraussetzung für die Bildung und die Überwachung der Speicherklassen ist ein durchgängiges Messverfahren. Die Messung selbst erfolgt über spezielle Agenten und die Nutzung von API auf den Server- und Speichersystemen. Dabei muss die Zuordnung der Messdaten zur Applikation die Systemarchitektur berücksichtigen. Die Verbindung von Datenklassifizierung mit weiteren wichtigen Datenmanagementfunktionen – darunter Backup und Recovery, Datenreplikation sowie Reporting-Werkzeugen – ist zwingend notwendig, um Zeit, Kosten und wertvolle IT-Ressourcen zu sparen. Klassifizierung stellt folgende Parameter bereit: • Parameter zur besseren Strukturierung von Daten für optimalen Schutz, verbesserte Verwaltung sowie Vorhaltung, basierend auf vordefinierten Richtlinien. • Parameter zur Verschiebung der Unternehmensdaten auf die jeweils geeignete Speicherebene entsprechend vordefinierten Richtlinien. 64

Kleineaschoff, Ulrich, a.a.O.

6.2 Generische Klassifizierungsansätze

239

Abb. 6.4. Messung der Speicherklassen

• Parameter zur umfassenden Datenprüfung im Vorfeld und Datenklassifizierung zur Reduzierung des Zeitaufwands für Datenbewegungen sowie der Serverauslastung. Die Kalkulation der Speicherklassen kann auf Basis verschiedener Ansätze erfolgen: • Generationenmodell: Hier wird jedes Jahr für neueste Hardware ein neuer Preis festgelegt. Der Preis für ältere Hardware bleibt jedoch unberührt. • Greenfield Approach: Es wird nur mit neuem, günstigerem Storage kalkuliert (keine Altlast). • Kontinuierlicher Refresh: Durch kontinuierlichen Refresh des„ausgelaufenen“ Speichers verringern sich im Laufe der Zeit die Kosten und damit der Preis pro GB. Diese Kosteneinsparungen sind Gegenstand der in SLAs vereinbarten zyklischen Preisüberprüfungen. • Mischkalkulation: Es muss mit altem und neuem Speicher kalkuliert werden.

6.2

Generische Klassifizierungsansätze

Die Datenklassifizierung unterstützt alle Maßnahmen, um gespeicherte Informationen optimal nutzen zu können. Ganz gleich ob im Content-Management, beim Dokumentenmanagement, beim Hierarchical Storage Management (HSM), beim

240

6 Datenklassifizierung

Information Lifecycle Management (ILM) oder bei der Archivierung – die in Speichernetzen (SAN) gespeicherten Informationen müssen möglichst schnell, nach bestimmten Prioritäten und Attributen gegliedert, dem Informationsmanagement bzw. den alltäglichen Geschäftsprozessen zur Verfügung stehen. Bei der Datenklassifizierung werden die Daten in Gruppen mit bestimmten Attributen aufgegliedert. Jede Gruppe ist durch gemeinsame Eigenschaften definiert.Mit der Klassifizierung wird erreicht, dass die Daten entsprechend der vom Anwender gesetzten Priorität unter einer geeigneten Speicherinfrastruktur gepflegt werden. Größtes Problem dabei ist die fehlende Durchgängigkeit des Datenmanagements insbesondere bei verteilten Speicherstrukturen. Denn auch die derzeitige Speichertechnik ist noch immer meilenweit von dem ehrgeizigen Ziel entfernt, ein durchgängiges, wertorientiertes Datenmanagement zu ermöglichen. Bei der Klassifizierung sind die spezifischen Anforderungen des Unternehmens zu berücksichtigen. Es gibt demzufolge unterschiedliche Klassifizierungsmodelle, die entweder einen statischen Charakter (d. h. eine einmalige Festlegung) oder einen dynamischen Charakter haben (d. h. eine Änderung der Klassifizierung ist möglich). In der praktischen Umsetzung wird meist eine Kombination der einzelnen generischen Ansätze genutzt.

6.2.1

Statische Klassifizierungsmodelle

6.2.1.1 Modell: Anwendungsklassifizierung Aus Sicht der Klassifizierung stehen die Anwendungen und alle Prozesse, die Daten transformieren können, im Zentrum der Betrachtung. Anwendungen können Programme wie z. B. Adobe Acrobat sein, die Informationen zu einem Bund vereinigen, die Anwendungen maßstäblich ändern und zudem häufig die betrieblichen Datenbanken und die Filesysteme des Unternehmens überspannen. Künftige Anwendungen könnten die Fähigkeit haben, Policen und Dienstleistungsstufen zu beeinflussen, sie direkt mit der Beauskunftung verbinden, und somit beim Zustandebringen des Lifecycles der Auskunft helfen. Derartige, zukünftige Anwendungen würden „ILM-aware-Anwendungen“ heißen. 6.2.1.2 Modell: Archivierungsbasierte Klassifizierung Die Abbildung von Geschäftsprozessen und -unterlagen in elektronische Dokumente erfordert eine geeignete Ablage der entstehenden Daten für die spätere Verwendung, deren Wiederfinden und Aufbereitung. Dies betrifft sowohl Datensätze als auch die elektronische Repräsentation papierener Geschäftsdokumente und Belege. Die dauerhafte und unveränderbare Speicherung von elektronischen Dokumenten und anderen Daten wird als Archivierung bezeichnet. Nicht allein, dass steuerrelevante Dateien ggf. 10 Jahre und länger in revisionssicherer Form archiviert werden müssen. Hinzu kommt, dass die Geschäftsführung für die Sicherheit der betriebswichtigen Daten und Systeme persönlich haften kann (vgl. Band 1 dieses Werkes „Grundlagen und Modelle des Information Lifecycle Management“, Kapitel 3.6 Information als Produktionsfaktor und Produkt sowie die relevan-

6.2 Generische Klassifizierungsansätze

241

ten juristischen Grundlagen). Eine geordnete, jederzeit verfügbare Aufbewahrung der elektronischen Geschäftspost ist aber auch aus Gründen der strategischen Rechtssicherheit unabdingbar, insbesondere um das Unternehmen für eine etwaige juristische Auseinandersetzung beweisrechtlich zu positionieren. Indessen greift die uneingeschränkte Archivierung der gesamten Kommunikation ohne geeignete betriebliche Regelungen schnell in die Rechte der Mitarbeiter ein. In diesem Spannungsfeld diametral gegenläufiger Interessen und Rechtspflichten geht der Überblick allzu leicht verloren. Hier schafft die Klassifizierung die Voraussetzung für ILM. Insbesondere zum Thema Archivierung fordert das Bundesamt für die Sicherheit der Informationstechnologie: „Für die Archivierung elektronischer Dokumente müssen geeignete Datenformate gewählt werden. Das Datenformat sollte langfristig eine originalgetreue Reproduktion der Archivdaten sowie ausgewählter Merkmale des ursprünglichen Dokumentmediums (z. B. Papierformat, Farben, Logos, Seitenzahl, Wasserzeichen, Unterschrift) ermöglichen. Die derzeit verwendeten Datenformate sind hierfür unterschiedlich geeignet, ihre Eignung hängt sehr stark vom Einsatzzweck der archivierten Daten und ihren Ursprungsmedien ab. Bei einem Wechsel des Medienund Datenformats können jedoch in der Regel nicht alle Strukturmerkmale des Ursprungsmediums gleichzeitig abgebildet werden. Da im Vorfeld meist nicht absehbar ist, welche Merkmale des Originaldokuments bei einer späteren Reproduktion nachgewiesen werden sollen und mit welcher Nachweiskraft dies erfolgen soll, werden Dokumente typischerweise in mehreren elektronischen Datenformaten gleichzeitig archiviert. Dadurch soll eine möglichst hohe Überdeckung der Merkmale des Originaldokuments erreicht werden. Der Konvertierungsvorgang wird häufig als Rendition bezeichnet.“65 6.2.1.3 Modell: Auskunftsklassifizierung Die Auskunftsklassifizierung ist eine grundsätzliche ILM-Strategie, die sich an der Praxis der Beauskunftung orientiert. Bei diesem Modell steht die Verwaltung von Daten im Mittelpunkt der Betrachtung. Dabei wird eine Unterscheidung zwischen Filesystem, datumsbasierter Klassifizierung und Content-basierter Klassifizierung vorgenommen. In der auskunftsbasierten Klassifizierung kommt das Konzept des Handbuchs versus vollautomatisierte Klassifizierungsverfahren (einschließlich Taxonomieentwicklung) zur Anwendung. Die Beauskunftung kann dabei auf verschiedenen Niveaus erfolgen und sich auf die Konzeption der SNIADMF-ILM-Initiative konzentrieren. Die aktuellen Technologien ermöglichen es, auf alle Aufzeichnungen online zuzugreifen und damit zunehmend die Zeit zwischen Archiv, Sicherstellungen und der ersten Kopie einer gelagerten Aufzeichnung zu eliminieren. Zum Beispiel sind Sicherungskopien traditionell nicht für einen Zugang geplant, außer in sehr seltenen Fällen des Totalausfalls. Diese Vorstellung basiert noch auf der traditionellen Unterscheidung zwischen verschiedenen Verwendungen von festen Speichertechnologien, die üblicherweise benutzt 65

BSI, www.bsi.de, a.a.O.

242

6 Datenklassifizierung

werden, und den neuen Online-Speicherungen. Unternehmen können sich durch den schnelleren Zugang zu ihrer netzbasierten Datenspeicherung einen 24×7Zugang zu ihren Daten verschaffen und damit kontinuierlich eine Beauskunftung ermöglichen, Beispiele sind hier die Expressunternehmen mit Ihrem Service der Sendungsverfolgung. 6.2.1.4 Modell: Business-Transaction-basierte Klassifizierung Basis der „Business-Transaction-basierten Klassifizierung“ ist die Bewertung von Informationen. Leider existiert bis heute keine standardisierte Bewertungsmethode.Wohl gibt es Ansätze,wie die Informationsproduktivität von Paul Strassmann66 , die Informationswertefunktion von Dr. Cramer67 oder auch Bewertungsbetrachtungen des Militärs68, der Wissenschaft69 oder diejenige der Cyberökonomen70. Die Bewertung der Kosten bei Datenausfall kann jedoch ebenso zur indirekten Bewertung der Unternehmensdaten herangezogen werden. Thomas Redman, der Präsident der Firma Navesik Consulting Group in New York, hat 1998 in einer Zusammenfassung einer Reihe von Untersuchungen zum Thema Datenqualität festgestellt, dass durchschnittlich 1-5 Prozent aller Daten eines Unternehmens fehlerhaft sind.71 Redman geht davon aus, dass 8-12 Prozent des Einkommens eines Unternehmens durch Datenverlust verloren gehen. Die SNIA (Storage Networking Industry Association) hat deshalb im März 2004 ein Strategiepapier veröffentlicht, welches ein Bewertungsschema enthält [SNIAILM]. Die Bewertung der Daten gemäß SNIA Business Transactions baut auf dem Modell auf, dass die Transaktionen auf Firmenebene, wie der Kauf oder Verkauf von Firmen oder Firmenbereichen, IPOs und Zusammenschlüsse, sowie Financial Transactions, zu denen Finanztransaktionen wie Geldüberweisungen, Verwaltung von Aktien und Portfolios zählen, für die Bewertung genutzt werden. Weitere Input-Größen für das Bewertungsmodell sind: • Customer Service: Kundendaten eines Unternehmens, wie beispielsweise Kontaktinformationen, Bestellverhalten etc. • Business Intelligence: Daten, die zur Planung und Steuerung eines Unternehmens notwendig sind. • Manufacturing Operations: Alle Daten, die für die Produktion von Gütern benötigt werden. 66

67 68 69 70 71

Dignan, L., Strassman, Paul: Who Led the Baseline 500 and Why, Baseline Magazine Okt. 2004. Cramer, M.L.: Measuring the Value Information, infoWAR-Congress, Vienna, 1997. 100-6INFO,Department of theArmy,Washington,DC,USA,Field-Manual-Nr.100-6,1996. Fafaeli, S., Raban, D.R.: Experimental Investigation of the Subjective Value of Information in Trading, 2003. Bauwens, M.: The free Loss of the Cyber-Economy, in: CMC Magazin 1996. Redman, T.C.: The Impact of poor Data Quality on the Typical Enterprise, ACM Communications, 1998.

6.2 Generische Klassifizierungsansätze

243

Abb. 6.5. Branchenorientierte Bewertung72

• POS/Order Entry: Daten, die den Auftragseingang betreffen, respektive Daten aus dem Verkauf (POS: Point of Sales). • Medical Records: Patientendaten sowie Daten über die Wirkung von Medikamenten. • E-Mail Records: Alle E-Mails einer Firma mit den zugehörigen Attachments. • Accounting: Buchungsdaten und Buchungsbelege sowie Rechnungsabschlüsse wie Bilanz und Erfolgsrechnung. • Legal Records: Verträge und andere juristisch relevante Dokumente. Eine branchenorientierte Bewertung wird abgebildet, wenn die Bewertung der Daten gemäß SNIA mit der Data Protection Class kombiniert wird.So wird für jede Branche festgelegt, ob eine Datenkategorie wie beispielsweise die des Customer Service wichtig oder unwichtig ist. Die Daten werden also einer der Kategorien von Not Important (Class 1) bis Mission Critical (Class 5) zugeordnet. 72

Die Autoren, SNW, a.a.O.

244

6 Datenklassifizierung

Um eine Bewertung der Daten bezogen auf eine Branche zu erreichen, werden die Werte aus der Abbildung mit der fünfstufigen Klassifizierung hinterlegt. Die verfeinerte Bewertung ist ein Klassifizierungsversuch und hat nicht den Anspruch, empirisch belegte Werte zu erzeugen. Für die grundlegende Bewertung von Daten ist sie jedoch hilfreich und nützlich, da eine Firma bzw. eine Branche die Wichtigkeit einer Datenkategorie festlegen kann und daraus direkt die Kosten für einen Datenverlust, also den Wert der Daten, ableiten kann. Die Kosten beziehen sich auf die durchschnittlichen Kosten pro Vorfall, falls die entsprechenden Daten verloren gehen oder nicht im definierten Zeitraum (RPO – Recovery Point Objective) wiederhergestellt werden können. Sie können als Indikatoren betrachtet werden, keinesfalls als absolute Werte in Euro. Durch eine Bewertung der Daten anhand ihrer Bedeutung für ein Unternehmen sind Aussagen bezüglich der Größenordnung der Kosten bei Datenverlust möglich. Die Summierung aller Kosten bei Datenverlust pro Datenkategorie ergibt eine Aussage über den Wert der Informationen für ein Unternehmen. Werden nun diese Werte der Servicequalität (SLO – Service Level Objective), die für die entsprechende Datenkategorie im Unternehmen definiert worden ist, gegenübergestellt, so kann ein Risikoportfolio der Unternehmensinformationen erstellt werden. Dabei wird der Abdeckungsgrad pro Datenkategorie bewertet und der SNIA-Klassifizierung gegenübergestellt. 6.2.1.5 Modell: Data-Protection-Initiative-Klassifizierung Die SNIA hat mit XAM eine klar strukturierte Klassifizierung definiert. Diese Klassifizierung wird mit Vorschriften zur Behandlung der einzelnen Datenklassen ergänzt. Dabei werden Kennzahlen für die Verfügbarkeit, den maximal zulässigen Datenverlust, die maximale Ausfallzeit und die maximale Offline-Zeit für die Datensicherung pro Klasse definiert. Die Kenngrößen der Klassifizierung sind: • RPO (Recovery Point Objective): Der Zeitraum zwischen zwei so genannten„Data Protection Events“.Dies bedeutet, die maximale Menge der Daten, die verloren gehen dürfen. • RTO (Recovery Time Objective): Wie viel Zeit darf vergehen, bis ein System wiederhergestellt ist. • DPW (Data Protection Window): Der Zeitraum, der verwendet werden darf, um Daten zu sichern, während das System nicht online ist. 6.2.1.6 Modell: Datenverwaltungs-Dienstleistungen-Klassifizierung Die Kontrolle von Daten über ihren gesamten Lifecycle steht im Mittelpunkt der Klassifizierung.Datenverwaltungsdienstleistungen umfassen die Dienstleistungen wie Datumsbewegung, Datumsredundanz und Datumslöschung. Bisher wurden die Daten pauschal bewertet und die Container (Informationsobjekte) bestimmt. Dieses Raster wird verfeinert, da sonst die höchste Anforderung auch auf Daten

6.2 Generische Klassifizierungsansätze

245

angewendet werden müsste, die nicht diese Anforderungen haben. Mit der Strukturierung der Daten teilen wir den gesamten Datenbestand in logisch zusammenhängende Teilbereiche auf. Die klassische und wohl auch einfachste Art der Strukturierung liegt in der Strukturierung nach Aufgabengebieten (oder auch Abteilungen). Beispiele sind Forschung, Entwicklung, Einkauf,Verkauf, Marketing oder Personalabteilung. Eine Datenstrukturierung kann auch nach Benutzergruppen erfolgen. Eine orthogonale Einteilung ergibt sich durch die Trennung von „strukturierten“ und „unstrukturierten“ Daten. Interessanter wird das Modell, wenn die vertikalen Verfahren einzelne Datenobjekte mit Attributen versehen können. Ideal wäre es, wenn z. B. ein Prozess im SMTP-Server bereits die Steuerrelevanz von eingehenden E-Mails bestimmen könnte. 6.2.1.7 Modell: Datumsklassifizierung Das Modell der Datumsklassifizierung kommt meist dann zum Einsatz, wenn bezüglich des Information Lifecycle keine Informationen vorliegen. In solchen Fällen ist es sehr schwierig, zu entscheiden, welche Daten einer besonderen Stufe zugeordnet werden sollten. 6.2.1.8 Modell: Dienstleistungsklassifizierung Die Dienstleistungsklassifizierung wird in Bezug auf Service Level Agreements (SLAs) und spezifischer Policies ausgedrückt. Der Begriff SLA bezeichnet eine Vereinbarung, die Dienstleistungen durch genaue Beschreibung der zugesicherten Leistungseigenschaften wie etwa der Reaktionszeit, Umfang oder Schnelligkeit transparenter zu gestalten.Wichtiger Bestandteil ist hierbei die Dienstgüte.Service Level Agreements (SLA) legen fest, welche Leistung z. B. ein Endanwender erwarten kann, wenn er auf Informationsobjekte zugreift. SLAs sollten grundsätzlich für jede Leistungsbereitstellung definiert werden. In einem ILM gewinnt dieser Aspekt zusätzliche Bedeutung, da dynamische Prozesse aufgrund des sich verändernden Wertes der Informationen ablaufen. So können z. B. Informationsobjekte aus dem Online-Bereich auf langsamere, kostengünstigere Speichermedien verdrängt werden, wenn darauf längere Zeit nicht mehr zugegriffen wurde. Sollte auf die verdrängten Informationsobjekte wieder zugegriffen werden müssen, dann muss klar sein, dass der Zugriff länger dauern wird, aber eine bestimmte maximale Zeit nicht überschritten werden darf. Aufgrund der SLA-Festlegungen im Rahmen des Service Level Management (SLM) ergibt sich die Technologie, auf die die Informationsobjekte gemäß den jeweiligen Zeiträumen verdrängt werden können. Die wesentlichen Inhalte eines SLA bestimmen sich auf Basis von ISO 20000 und ITIL. 6.2.1.9 Modell: Disaster-Recovery-Klassifizierung Es gibt Unternehmen, deren wichtigste Herausforderung aus IT-Sicht die Vermeidung des Katastrophenfalls ist,bzw.die Bereitstellung der Daten ohne jeden Datenverlust und ohne wirkliche Ausfallzeit. Zentrales Instrument ist hier der Business

246

6 Datenklassifizierung

Abb. 6.6. SLA im Rahmen des Service Level Management.73

Continuity Plan, in dem Speicher die entscheidende Rolle spielt. Die Klassifizierung erfolgt hier gemäß den spezifischen Anforderungen in Verbindung mit den speziellen Eigenschaften der Speichermedien. Ein Beispiel für eine solche Lösung zeigt die Firmendarstellung aus Abbildung 6.7. 6.2.1.10 Modell: Geschäftsfeldklassifizierung Die Perspektive der Geschäftsfeldklassifizierung ist die Anwendungsebene. Das Modell umfasst die Umwandlung der Geschäftsklassifizierungen zu verkäuferneutralen Dienstleistungsklassifizierungen. Dieses Modell der Klassifizierung muss die Einhaltung branchenspezifischer technischer und nichttechnischer Anforderungen abdecken, wie z. B. den Besitz bzw. die Zuteilung von Hilfsmitteln. Die Geschäftsfeldklassifizierung kann spezifische Dienstleistungsklassifizierungen je nach besonderer Lösung integrieren. 6.2.1.11 Modell: Informationsmanagement-DienstleistungenKlassifizierung Die Informationsmanagement-Dienstleistungen-Klassifizierung betrachtet die Prozesse, die Auskunft und die Aufzeichnungen durch verschiedene, sich gemäß dem Geschäftsprozess ergebende Verbindungen zwischen Unternehmen und 73

ITIL, SLA-Managment.

6.2 Generische Klassifizierungsansätze

247

Abb. 6.7. Klassifizierung mit dem Fokus Verfügbarkeitim Rahmen eines Business Continuity Plans75

deren Steuerung. Diese Dienstleistung kann benutzt werden, um die Beauskunftung, Metadaten, Datenverwaltungsdienstleistungen oder die Nutzung der Infrastrukturen zu der Durchführung der spezifischen„Policy“ bereitzustellen.Beispiele sind im Aufzeichnungsmanagement eines jeden Unternehmens zu finden. 6.2.1.12 Modell: Metadatenbasierte Klassifizierung Metadatenbasierte Klassifizierungsverfahren werden genutzt, um Datumsbewegungen über verschiedene Stufen der Speicherung zu planen. Als Metadaten oder Metainformationen bezeichnet man allgemein Daten, die Informationen über andere Daten enthalten. Bei den beschriebenen Daten handelt es sich oft um größere Datensammlungen (Dokumente) wie Datenbanken oder Dateien. So werden auch Angaben von Eigenschaften eines Objektes als Metadaten bezeichnet.Während der Begriff „Metadaten“ relativ neu ist, ist das Prinzip unter anderem jahrhundertealte bibliothekarische Praxis. 6.2.1.13 Modell: Security-based-Klassifizierung Mit den Veränderungen in der Speicherlandschaft hat die Frage nach der ITSicherheit eine neue Facette erhalten. In dem Maße, wie Unternehmen die Daten75

Die Autoren, aus SNW, a.a.O.

248

6 Datenklassifizierung

speicher vernetzen, nimmt die Notwendigkeit zu, Speichernetze gegen Missbrauch zu schützen. Analog zum Wert der Daten müssen deshalb die Zugriffsrechte prinzipiell aus unternehmerischer Sicht definiert werden. Beispielsweise ist zu entscheiden, ob Daten nur intern oder auch extern zugänglich sein sollen. In der Praxis existieren natürlich zuerst einmal intern unterschiedliche Benutzergruppen mit unterschiedlichen Zugriffsrechten. Diesen Vorgaben muss ILM Rechnung tragen,so dass diese durch die ILM-Aktionen nicht verletzt werden.Nach einerVerdrängung müssen z. B. zuerst einmal dieselben Zugriffsrechte weiter bestehen wie vor der Verdrängung. Das Gleiche gilt für Backup, Replikation, Archivierung etc. Schutzanforderungen können sich im Lebenszyklus verändern.Unternehmerische Vorgaben müssen auch festlegen, für welche Datenbereiche absolute Datenintegrität gefordert wird. Datenintegrität bedeutet, dass Veränderungen in jeglicher Form ausgeschlossen werden. Die neuen Plattentechnologien können u. a. dazu genutzt werden, um das Sicherheitsparadigma zu vergrößern. Die eingesetzten Technologien umfassen die Speicherung von Snapshots (Momentaufnahmen),Vollkopien von Momentaufnahmen (Spiegel), differentiale Momentaufnahmen, und Serial Attached SCSI (SAS) ebenso wie kontinuierlichen Datenschutz (CDP – Continous Data Protection) in seinen verschiedenen Formen. Teilweise werden auch verschiedene Technologien kombiniert. Ein wichtiger Punkt für Integratoren ist, dass es erstmals möglich wird SAS- und SATA-Festplatten in einem Gehäuse zu kombinieren. Dies erlaubt den Bau von Systemen, die einerseits höchste Zuverlässigkeit und Geschwindigkeit bei SAS und andererseits schnelle Geschwindigkeit bei einem günstigen Verhältnis von Kosten pro GByte wie bei SATA vereinen. Die Technologien umfassen auch das SAN-Sicherstellungsparadigma, Bandbibliotheken, die mit normalem SCSI die Bandlaufwerkausführung teilen, Platteninszenierungen mit normaler Platte und virtuellem Band sowie Momentaufnahmen und Erweiterung. 6.2.1.14 Modell: Standardbasierte Klassifizierung Mit dem XAM-Vorschlag der SNIA existiert ein Industrievorschlag zur Schaffung standardmäßiger Schnittstellen, um Metadaten zwischen Anwendungen und Lagerungssystemen zu koordinieren.Weitere Standardisierungsbestrebungen gibt es zurzeit nicht. De-facto-Standards existieren wohl im Bereich einzelner Applikationen und Technologien. Eine Klassifizierung der Daten auf Basis von De-factoStandards kann eine langfristig sinnvolle Klassifizierungsstrategie sowohl im Hinblick auf die Optimierung des TCO als auch des langfristigen Investitionsschutzes darstellen. 6.2.1.15 Modell: Value-driven-Klassifizierung Die Festlegung des Werts der Informationen muss als unternehmerische Vorgabe erfolgen. Die Basis liegt in den betriebswirtschaftlichen Geschäftsprozessen mit der Abbildung der Geschäftslogik. Oft wird man feststellen, dass die Geschäftprozesse nicht hinreichend klar definiert sind. Wenn einmal der Wert der Informationen definiert ist, kann auch der Schutz der Informationen konkretisiert werden.

6.2 Generische Klassifizierungsansätze

249

Die wichtigsten Überlegungen sind, welche Anforderungen z. B. an RPO (Recovery Point Objective) und RTO (Recovery Time Objective) gestellt werden. In bestimmten Branchen ist dies nicht alleine eine interne Entscheidung, sondern wird durch Verbandsvorgaben oder sogar durch Gesetze beeinflusst. Als Grundgedanke liegt dem Konzept zugrunde, dass sich der Wert der meisten Informationen und damit das Zugriffsmuster auf deren Informationsobjekte im Laufe der Zeit verändern. Über automatisierte Prozesse wird sichergestellt, dass die Informationsobjekte zu jeder Zeit am richtigen Ort mit den geringstmöglichen Kosten gespeichert werden. Damit reduzieren sich die Investitionskosten. Hardwarekosten sind jedoch nur ein kleiner Teil der Gesamtkosten. Unterschiedliche TCO-Betrachtungen (TCO – Total Cost of Ownership) gehen davon aus, dass dieser Teil nur ein Drittel bis ein Fünftel ausmacht. Die restlichen Kosten sind Infrastruktur-, Administrations- und Betriebskosten. Eine rechtzeitige Archivierung von Informationsobjekten entlastet z. B. den Online-Bereich, für den aufwendige Datensicherungsprozesse ablaufen.Archivierte bzw. verdrängte Informationsobjekte brauchen im Prinzip nur einmal gesichert zu werden. Durch Archivierung kann somit das tägliche, wöchentliche oder monatliche Datensicherungsvolumen reduziert werden. Noch gravierender ist dies im Bereich der Wiederherstellung. Falls der Online-Bereich nicht von alten Informationsobjekten entlastet ist, müssen alle Objekte erst zurückgeladen werden, bevor die Anwendung wieder online gehen kann. 6.2.1.16 Modell: XAM-Klassifizierung Mit dem SNIA-Standard XAM (Extensible Access Method) sollen Speicherregelwerke über Anwendungsgrenzen hinweg ermöglicht werden. XAM ist ein Industrievorschlag zur Schaffung standardmäßiger Schnittstellen, um Auskunftsmetadaten zwischen Anwendungen und Lagerungssystemen zu koordinieren. Das XAM-Projekt startete im Oktober 2004 als ein Gemeinschaftunternehmen von IBM, EMC, HP, Hitachi und Sun Microsystems. Der vorgeschlagene Standard wurde SNIA im September präsentiert. XAM schafft laut SNIA eine enge Verzahnung zwischen Anwendung und Speichermedium. Dadurch kann das Speichersystem Metadaten bezüglich Informationen, Daten und Sicherheit zu den einzelnen zu speichernden Daten in Beziehung setzen. Dies wiederum ermöglicht die Formulierung von Regeln bezüglich des Speicherorts, der Haltedauer, des Datenschutzes, der Datenverteilung, der Verschiebung und Migration von Daten, ihrer Sicherheit, der nötigen Authentifizierung und so weiter. Das von SNIA entwickelte XAM-Interface soll die Entwicklung vereinfachen, indem durch das Zuweisen „standardmäßiger“ Metadaten, die Informationen auf unterschiedlichen Wegen als aktiv oder sich ändernd gelagert werden können. Diese Metadaten und eine standardmäßige Schnittstelle sind Schlüssel dazu, mit Object-Services zu kommunizieren (OSD) und Auskunftsklassifizierung, langfristige Aufzeichnungszurückhaltung und Auskunftssicherheit zu automatisieren. Mit der langen Speicherfähigkeit von Fixed-Content und der zunehmenden Menge von sich verbindenden Vorschriften wird die XAM-Schnittstelle einen selbstbeschrei-

250

6 Datenklassifizierung

benden Weg eröffnen, Informationen zu bewahren, und es Anwendungen und Aufzeichnungen ermöglichen, über und zwischen Speichersystemen und Anwendungen zu wandern. Zusätzliche XAM-Arbeitsbereiche innerhalb SNIA und hier innerhalb des Datenverwaltungsforums sind der XAM-Schnittstelle gewidmet. SNIA plant die Definition einer Softwareentwicklungs- und Prüfungskonzeption (QS),einVerweismodell für die Verwendung und die schnelle Annahme sowie ein Sicherheitsmodell. Insbesondere die Aspekte Sicherheit und Qualitätssicherung halten die Autoren für so wichtig, dass sie diesen Aspekt gesondert behandeln. „XAM ist somit eine wichtige Entwicklung für Fixed-Content-Aware-Speichersysteme und ILM-Automatisierung. Der Standard fördert eine engere Integration zwischen unterschiedlichen Datentypen und -gruppen, so dass IT- und StorageVerantwortliche Informationen effektiver managen können“, sagt Paul Talbut, Chairman der SNIA Europe. „Die SNIA Europe bietet bereits Hintergrundmaterial zu XAM.Wir wollen Endkunden, Hersteller und Integratoren dazu bewegen, sich darüber zu informieren, wie sie von der Entwicklung dieser neuen StorageSchnittstelle profitieren können“, erläutert Talbut. Da die XAM-Schicht zwischen Anwendung und Speicher liegt,schafft sie damit eine bislang fehlende Voraussetzung für anwendungsübergreifende ILM-Systeme, wie sie die SNIA-ILM-Pyramide auf Ebene 4 und 5 vorsieht. Kundenspezifische Anwendungsschnittstellen verlieren damit ihren Schrecken, sie bleiben für das Speichersystem unsichtbar. Damit erfüllt XAM ähnliche Funktionen wie heutige SAN-Filesysteme. ILM, die Speicherung unstrukturierter Daten, aber auch GridComputing dürften davon profitieren. Die Industriestandardschnittstelle XAM soll auch dafür sorgen, dass Aufbewahrungsorte und Fristen eingehalten werden. Diese Vorstellung wird eine Übersicht über die Anforderungen für die Bewältigung des festen Contents geben. Insbesondere die Planer und Lösungsentwickler, die für Archivlösungen zuständig sind, benötigen die Einhaltung spezifischer Standards. Erst XAM sorgt für eine Übersicht über die sich ergebenden Probleme mit der Sicherstellung der logischen Lesbarkeit im langfristigen Archiv. Die Erfolgsaussicht von XAM muss aktuell noch skeptisch beurteilt werden. Insbesondere Microsoft ist kein Teilnehmer des Standardisierungsgremiums. Microsoft ist aber gerade in kleineren Firmen der Hauptdokumentenlieferant und dürfte weniger auf XAM als auf XML (Extensible Markup Language) setzen, also eine Vereinheitlichung schon auf Ebene des Dokumentenformats. Zudem kündigen Firmen wie CA und Symantec Pre-Certified-XAM-Produkte an, bei denen es bei einer Normung erhebliche Änderungen geben müsste, damit sie die mögliche Norm erfüllen. Das Aperi-Forum möchte eine offene Speichermanagementplattform (Open Source) entwickeln, die dann auch ILM-Komponenten enthalten dürfte. Die neue Industrieassoziation besteht aus Unternehmen wie IBM, Cisco, Computer Associates, Engenio, McData und Network Appliance, die dazu Code beisteuern wollen. Mit EMC, HP, Hitachi Data Systems, SUN und Symantec fehlen aber sehr wichtige Hersteller.

6.2 Generische Klassifizierungsansätze

251

Für XAM spricht, dass insbesondere große Anwenderunternehmen massiv von den vereinheitlichenden Effekten der SNIA-Standards profitieren könnten. Daher dürften SNIA-Normen in Lösungen wie die geplante Plattform von Aperi einfließen. Und so steht die Chance nicht schlecht, dass die zukünftigen ILMStrategien wesentliche Teile von XAM umsetzen werden. ILM wird somit auf jeden Fall von den Arbeiten an XAM profitieren. Sicherheit der Ausführung, Verfügbarkeit, Sicherheit, Authentifizierung, langfristige Onlinesicherung und so weiter können als gesetzt angesehen werden. Die Metadaten ermöglichen sogar eine ILM-gestützte Praxisautomation, so Jeff Porter. Der Vorsitzende des Datenverwaltungsforums von SNIA sieht durch die XAM-Spezifikation eine langfristige Wirkung auch für den Endbenutzer.

6.2.2

Dynamische Klassifizierungskonzepte

Datenklassifizierung und Tiered Storage sind aber noch nicht der Weisheit letzter Schluss, weil es sich dabei um statische Lösungen handelt. Es kann notwendig sein Informationen dynamisch zwischen den Speicherebenen zu verschieben. Die abgewickelte Bestellung eines Kunden muss nicht unbedingt zwei Jahre lang auf den teuren Online-Systemen verfügbar sein und dort unnötig Speicherplatz belegen. Nach definierter Zeit verschieben dynamische Systeme solche Daten z. B. auf ein Worm-System und archivieren sie dort wesentlich kostengünstiger. Sowohl für die IT-Administratoren als auch für die Anwender ist das Thema dynamische Anpassung der Klassifizierung und damit der Speicherung der Daten zu komplex und kann allein aufgrund der Masse an Daten im Unternehmen nicht manuell erledigt werden. Für die kontinuierliche Klassifizierung der Dokumente eignen sich beispielsweise DMS/ECM-Systeme, Filesystem-Archivierung (HSM – Hierarchical Storage Management), E-Mail-Anwendungen und Datenbanken. Entscheidend ist das Verständnis für die Prozesse im Unternehmen und wie sich diese auf die Informationen auswirken und vice versa. Wenn beispielsweise die Forschung im Labor ein Dokument erstellt, kann dies in verschiedenen Prozessen eine wichtige Rolle spielen. Die Information kann in der Folge Teil eines Patentantrags, einer Studie oder eines Antrags für Drittmittel sein. Damit überschreitet die gespeicherte Information viele Grenzen innerhalb und außerhalb des Unternehmens. Dynamische Klassifizierung erfordert, dass die Daten schon bei der Erstellung den Prozessen zugeordnet werden. Unterschiedlichste Systeme wie Publishing Engines, Applikationen für Studien sowie Vertriebs- und Marketing-Portale müssen damit interagieren. Wenn die Inhalte schon bei ihrer Erstellung bestimmten Prozessen zugeordnet werden, kann eine Auswirkungsanalyse schon frühzeitig die Lebensphasen einer Information und ihre voraussichtlichen Anforderungen an den Speicherort aufdecken. Dies hängt beispielsweise davon ab, ob sie später archiviert werden muss oder nach Beendigung des letzten Prozesses gelöscht werden kann. Diese Informationen werden, neben Basisangaben wie Erstellungsdatum und Quelle, in den Metadaten gespeichert. Ein weiterer Vorteil ist, dass der Content später über die Metadaten sehr viel einfacher wieder aufzufinden ist. Na-

252

6 Datenklassifizierung

türlich kann dies nicht nach einem statischen Schema ablaufen, in dem genau die Zeitpunkte und Migrationsstufen vorgegeben sind. Das System muss eigenständig den Status der Informationen im Rahmen der zugeordneten Prozesse analysieren und sie den entsprechenden Informationsklassen zuordnen. Ändert sich die Klassifizierung, und damit auch die nötigen Service Levels, müssen die Daten innerhalb der Infrastruktur migriert werden. Auch dies sollte mittels intelligenter Managementsoftware automatisiert ablaufen. Dazu werden in einem Regelwerk die Speicherebenen und ihre Service Levels in Bezug gesetzt. So muss das System eigenständig ermitteln, ob die Daten korrekt abgelegt sind, und sie gegebenenfalls verschieben.Voraussetzung für eine solche dynamische Informationsverwaltung ist eine einheitliche Managementumgebung für die gesamte Speicherinfrastruktur mit allen Speichersystemen und Netzkomponenten im SANund NAS-Bereich. Sie muss in der Lage sein, die Daten ohne Auswirkungen auf die Applikationen zwischen den Speicherebenen zu verschieben. Das gelingt mit Virtualisierungslösungen, die die physikalische von der logischen Speicherebene trennen.

6.3 Tiered Storage als Lösungsinstrument bei der operativen Umsetzung der Klassifizierung ILM kann umso wirksamer arbeiten, je besser der gesamte Speicherbereich strukturiert ist. Dies erfolgt üblicherweise über Speicherhierarchien und Speicherklassen. Speicherhierarchien ergeben sich in der Klassifizierung von Speichertechnologien nach technischen oder nach Kostengesichtspunkten in einer absteigenden bzw. aufsteigenden Ordnung. Technische Aspekte und Kostengesichtspunkte sind oft voneinander abhängig. So sind z. B. Speichersysteme mit schnellem Zugriff in einer höheren Preisklasse angesiedelt als Speichersysteme mit langsamerem Zugriff. Speicherklassen ergeben sich aus der logischen Strukturierung des Speicherbereichs. Somit können Speicherhierarchien noch feiner strukturiert werden. Darüber hinaus kann z. B. nach Anzahl der automatisch zu erzeugenden Kopien von Informationsobjekten differenziert werden, auch wenn die Speicherobjekte in derselben Speicherhierarchie liegen. Aufsetzend auf den durch Klassifizierung ermittelten Anforderungen wird eine Tiered-Storage-Architektur abgeleitet. Das Spektrum des Tiered Storage reicht von hochverfügbaren Umgebungen für kritische Produktionsdaten, die zusätzlich an einen zweiten Standort gespiegelt werden, über Online-Archive bis hin zu Bandrobotern für die Datensicherung und -archivierung. Dazwischen lassen sich vielfältige Zwischenstufen einrichten, um die Serviceziele für Anwendungsdaten wie E-Mail oder Datenbank zu erreichen. Beim Tiered Storage können beispielsweise die Informationen in drei Verfügbarkeitsklassen eingeteilt werden. • Klasse 3 ist z. B. für die Speicherung und Sicherung weniger wichtiger Daten wie Home Directories oder das SAP-Testsystem vorgesehen und besteht aus Midrange-Systemen mit FC-Platten (Fibre Channel).

6.4 Projektbezogene Umsetzung

253

• Klasse 2 bietet z. B. die Standard-Speicher-Performance ebenfalls auf Basis der Mittelklassespeicher mit FC-Technologie, allerdings mit einer zusätzlichen Spiegelung. • Klasse 1 ist für unternehmenskritische Informationen. Die kritischen, produktiven Daten der Klasse 1 lagern auf hochperformanten, gespiegelten HighendSystemen. Unveränderliche Daten, die nicht mehr aktiv benötigt werden, werden z. B. in ein Online-Langzeitarchiv mit ATA-Platten und Worm-Funktionalität verlagert. Genereller Grundsatz ist: Je wichtiger die Daten für ein Unternehmen sind, desto höher sollte ihreVerfügbarkeit sein und desto teurer sind die geeigneten Speichermedien. Für die Einrichtung der Speicherebenen können Technologien wie Storage Area Network (SAN), Network Attached Storage (NAS) oder Content Addressed Storage (CAS) innerhalb eines Speichernetzes auch kombiniert werden. Einige Hersteller bieten mittlerweile sogar innerhalb eines Systems verschiedene Speicherklassen an. So können beispielsweise in einem Array leistungsfähige und teure FC-Festplatten mit günstigeren ATA-Laufwerken kombiniert werden. Und selbst innerhalb der FC-Technik gibt es mittlerweile unterschiedliche Typen, so dass auch im Highend eine Abstufung möglich ist, wie sie EDS vorschlägt. Ist der tatsächliche Wert der Informationen bekannt, lassen sich die Speicherinvestitionen dementsprechend planen und die Gesamtkosten senken. Die Vorteile von Tiered Storage lassen sich auch im Archiv nutzen.Wenn Transaktionsspeicher und Backup-Umgebung von allen unveränderlichen Daten entlastet werden und diese in ein sich selbst verwaltendes Langzeitarchiv, basierend beispielsweise auf CAS,verlagert werden,vereinfacht dies den Backup-Prozess und senkt den Verwaltungsaufwand.

6.4 Projektbezogene Umsetzung Die dargestellten Datenklassifizierungsansätze zeigen generisch das Vorgehen zur Klassifizierung, können jedoch keinen Implementierungsweg beschreiben, da dieser stets unternehmensspezifisch ist. Die Implementierung von Datenklassen verbleibt beim anwendenden Unternehmen, ist Brainware und muss vom Anwendungsunternehmen automatisiert werden. Die ursprüngliche Projektzielsetzung von KONCOM/IT wies bereits klar den Weg zu einer „tiered“ Speicherumgebung auf. Es soll gemäß dem Informationslebenszyklus eine abgestufte Speicherumgebung für die drei Datenklassen • Hochverfügbarkeitsdaten, • Nearline-Daten und • Archivdaten aufgebaut werden. Für die Hochverfügbarkeitsdaten soll eine Speicherumgebung mit Disaster Recovery über zwei Standorte eingeführt werden. Nearline-Daten

254

6 Datenklassifizierung

sollen lokal abgesichert werden. Zu den Archivdaten wurde lediglich eine Aussage über das zu verwendende Archivierungssystem IXOS gemacht. Die Klassifizierung der Daten in die drei Datenklassen stellte sich als das größte Problem des Projektes heraus. Um eine Zuordnung einer Information zu einer der drei Datenklassen zu automatisieren, mussten diskrete Attribute gefunden werden, die die Identifikation der Daten fehlerfrei ermöglichen. An diese Problematik arbeitete man sich im Projekt iterativ heran. KONCOM/IT wählte als iterativen Weg zur Datenklassifizierung folgende Raster: • • • •

Klassifizierung nach Servern, Klassifizierung nach Anwendungen, Klassifizierung nach Metadaten, Klassifizierung nach Dateiinhalten.

Vor jeglicher Klassifizierung wurden für sämtliche Systeme gültige Standards definiert, die im Folgenden dargestellt werden.

6.4.1

Betriebsstandards der EurAmFi AG

6.4.1.1 Infrastrukturstandards Die Standards werden in der Konfigurationsmanagement-Datenbank (cmdb) der EurAmFi AG abgelegt, um eine einheitliche Pflege und Recherche nach standardisierten Mustern zu erleichtern. Um internen Controlling- und Audit-Anforderungen an ein Verfahrenshandbuch Genüge zu leisten, werden die Standards in ihrem jeweilig aktuellsten Zustand halbjährlich aus der cmdb extrahiert und in einem Dokument zusammengefasst. Das Dokument wird mit einer zweistelligen Versionsnummer versehen, die als höchste Version die Version 20 enthalten darf (10 Jahre à 2 Versionen). Nach zehn Jahren Aufbewahrungszeit wird die Version 01 des Standarddokumentes durch den dann gültigen Auszug aus der cmdb der EurAmFi AG ersetzt usw. Für folgende Infrastrukturbereiche wurden Standards beschrieben: • Standards für Primärinfrastruktur • Standards für Server Server werden in Serversysteme und Clustersysteme unterschieden. Dabei fassen Clustersysteme mehrere gleichartige Serversysteme zusammen, von denen jedes einzelne für den Betrieb einer oder mehrerer Anwendungen installiert und konfiguriert ist und jedes diese Anwendung/en für sich gestellt verfügbar halten kann. Clustersysteme dienen damit der Steigerung der Leistungsfähigkeit (PerformanceCluster), der Erhöhung der Verfügbarkeit (Failover-Cluster) oder beidem zu gleichen Anteilen (Parallel-Cluster). In einem Performance Cluster arbeiten alle Server (Clustermember) gleichberechtigt über einen Lastverteilungsmechanismus parallel am Betrieb der Anwendung/en.

6.4 Projektbezogene Umsetzung

255

In einem Failover-Cluster ist zu jedem Zeitpunkt nur einer der Server aktiv und stellt allein die Anwendung produktiv zur Verfügung. Die restlichen Clustermember verbleiben laufend in Bereitschaft (Hot-Stand-By). Bei einem Ausfall des aktiven Servers übernimmt ein anderes Clustermember den Betrieb der Anwendung/en, so dass nur für den Zeitraum der Umschaltung auf das bisher passive Clustermember auf den Produktivbetrieb die Anwendung nicht verfügbar ist.Nach Behebung des Ausfalls des ursprünglich aktiven Servers kann dieser wieder als in der Regel passives Clustermember (Hot-Stand-By-Server) in den Cluster integriert werden. Failover-Clustersysteme können die Verfügbarkeit nur im Falle von Hardwareausfällen sichern. Logische Fehler werden dagegen nicht behoben, da sämtliche Memberserver des Clustersystems dieselbe Anwendungssoftware einsetzen und auf denselben Datenbestand zugreifen. Clustersysteme sind für höchste Verfügbarkeit mit maximalen Hardwareausfallzeiten von bis zu einer Stunde zwingend erforderlich. 6.4.1.2 Speichersysteme Für den Betrieb einer Anwendung ist der Zugriff auf die Anwendungsdaten unverzichtbar. Diese Daten werden über Datenbanken oder Dateisysteme auf serversysteminternen Platten oder Plattensubsystemen (DAS – Direct Attached Storage) oder externen Speichersystemen gehalten, auf die der Server über so genannte Host-Bus-Adapter (HBA) und ein Storage Area Network (SAN) sowie Netzwerkkarten und ein Network Attached Storage (NAS) oder iSCSI zugreift. Das im Hause EurAmFi AG vor KONCOM/IT eingesetzte Speicherverfahren war DAS. KONCOM/IT führt externe Speichersysteme in einem SAN und/oder NAS/iSCSI ein. Um die Verfügbarkeit der Anwendung zu steigern, kann der Anschluss an ein SAN mit mehreren HBAs erfolgen, so dass bei Ausfall eines HBA der SAN-Zugriff über die anderen HBAs weiter sichergestellt ist. Auch das SAN selbst kann redundant ausgelegt werden, indem die HBAs vollständig getrennte Verbindungen (Verkabelung und Komponenten) zu den Speichersystemen haben. Für EurAmFi-Server und sämtliche Server, die von KONCOM/IT betroffen sind, ist die zweifache Anbindung an SAN und Speichersysteme zwingend gefordert. 6.4.1.3 Netzwerk Für Anwendungen, die auf Server- und Clustersystemen betrieben werden, ist die Netzwerkkommunikation mit anderen Anwendungen, Server- und Clustersystemen oder Arbeitsplatzrechnern unverzichtbar. Um die Verfügbarkeit einer Anwendung zu steigern, muss also einem Netzwerkausfall vorgebeugt werden. Dazu kann der Anschluss an das Netzwerk mit zwei oder mehreren Netzwerkadaptern (NIC – Network Interface Card) erfolgen, so dass bei Ausfall eines NIC der Netzwerkzugriff über einen oder weitere NICs auch weiterhin sichergestellt ist. Auch das Netzwerk selbst kann redundant ausgelegt werden, indem die NICs vollständig getrennte Verbindungen (Verkabelung und Komponenten) haben.

256

6 Datenklassifizierung

Für EurAmFi-Server und sämtliche Server, die von KONCOM/IT betroffen sind, ist die zweifache Anbindung an das Netzwerk zwingend gefordert.

6.4.2

Standards für Sekundärinfrastruktur

6.4.2.1 Stromversorgung Die Verfügbarkeit der Stromversorgung von Geräten, speziell Server- und Clustersystemen sowie externen Speichersystemen, kann mit drei Maßnahmen gesteigert werden: • Eine so genannte unterbrechungsfreie Stromversorgung (USV) liefert Energie, wenn die normale Stromlieferung ausfällt. Ein Energiespeicher (Batterie, Akkumulator, Kondensator) überbrückt dann die Zeitspanne, bis die Stromlieferung wieder funktioniert oder gegebenenfalls ein Notstromaggregat angelaufen ist und die Stromversorgung übernimmt. • Multiple Netzteile in einem Gerät bilden eine redundante Anbindung an das Stromnetz. Wenn eines der Netzteile ausfällt, springen die anderen ein und stellen die Versorgung der Primärtechnik mit Strom sicher. • Die Netzteile werden auf zwei unterschiedliche Stromkreise unterschiedlicher Lieferanten geschaltet. Dadurch kann sichergestellt werden, dass der Ausfall der Energieversorgung eines Lieferanten durch das Weiterbestehen der Energieversorgung des zweiten Lieferanten kompensiert wird. Die Kombination dieser drei Maßnahmen ist für die EurAmFi-Primärinfrastruktur und sämtliche Primärtechnik, die von KONCOM/IT betroffen ist, zwingend gefordert. 6.4.2.2 Klimatisierung Die hohe Rechenleistung moderner Rechnersysteme, Speichersysteme und Netzwerkinfrastruktur (Switches, Router, SAN-Switches, SAN-Direktoren) bringt auch hohe Verlustleistungen mit sich, die in Form von Wärme in die Umgebung abgegeben werden müssen. Wird diese Abwärme nicht schnell genug abgeleitet, ist in der Regel ein Hardwareausfall die Folge. Deshalb sind Rechenzentrumsräume üblicherweise mit einer Klimatisierung auszustatten, die die Aufgabe des Wärmetransports übernimmt. Für Rechenzentrumsräume in Rechenzentren der EurAmFi AG und sämtlicher verbundener Unternehmungen ist eine Klimatisierung, die die Wärmeabgabe der eingesetzten aktiven und passiven RZ-Technologien um den Faktor 1,5 übersteigt, zwingend gefordert. 6.4.2.3 Verschiedene Standorte Die Verfügbarkeit von Anwendungen kann auch im Falle des Ausfalls eines kompletten Rechenzentrums sichergestellt werden. Für die Serversysteme kann dazu ein Failover-Cluster verwendet werden, bei dem die Clustermember des Clusters

6.4 Projektbezogene Umsetzung

257

nicht alle an einem Standort stehen. Aber auch die Anwendungsdaten müssen an mehr als einem Standort gehalten werden. Dies wird mit der synchronen Spiegelung auf einen anderen Standort erreicht. Dabei werden zwei externe Speichersysteme, die über ein SAN, NAS oder iSCSI zugreifbar sind, über das SAN oder ein 4-GB-Backbone-Netzwerk so miteinander gekoppelt, dass jeder Schreibvorgang auf beiden Systemen synchron ausgeführt wird; ein Schreibvorgang ist also erst dann beendet, wenn beide Systeme – an verschiedenen Standorten – die Daten dauerhaft gespeichert haben. Für Anwendungen mit einer geforderten maximalen Hardwareausfallzeit von weniger als 4 Stunden, ist die synchrone Spiegelung der Anwendungsdaten durch KONCOM/IT zwingend erforderlich.

6.4.3

Klassifizierung nach Server und Anwendungen

Beim Vorgehen zur Klassifizierung wurde zunächst ein grobes Raster – die Klassifizierung nach der Bedeutsamkeit der Server – gewählt. Dabei stellte sich schnell heraus, dass dieses Klassifikationsschema zu einer starken Verfälschung der Ergebnisse führt. Im Hause der EurAmFi AG wurde konsequent eine dreischichtige Serverarchitektur eingesetzt, auf der die unterschiedlichen Instanzen von Anwendungen liefen. So wurden – auch netztechnisch voneinander getrennt – folgende Systemebenen betrieben: • Produktivsysteme, • Pre-Life- und Testsysteme, • Entwicklungssysteme. Die Pre-Life- und Testsysteme wurden per Architekturstandard in der gleichen Dimension wie die Produktivsysteme betrieben. Das heißt, ein Produktivsystem der Enterprise-Klasse hatte natürlich auch ein identisches Pre-Life- und Testsystem der Enterprise-Klasse im Pre-Life-Netzwerk als Pendant. Eine Klassifizierung rein nach Servermerkmalen wie • • • •

Anzahl-CPUs, CPU-Geschwindigkeit, Ausstattung mit Hauptspeicher, etc.

stellte Serversysteme der Pre-Life- und Testumgebungen auf die gleiche Ebene der Bedeutsamkeit wie Produktivsysteme. Pre-Life- und Testumgebungen für Anwendungen, die allein aufgrund hoher Benutzeranzahl, hohen CPU-Bedarfs, hohen Hauptspeicherbedarfs in der Produktivumgebung eine Enterprise-Umgebung erforderten, standen bei diesem Klassifizierungskriterium sogar vor Produktivanwendungen, die aufgrund geringerer Benutzerzahl, geringeren CPU-oder Hauptspeicherbedarfs mit Servern im mittleren Leistungsspektrum auskamen. Daher stellte sich der Server als primäres Klassifizierungskriterium als ungeeignet heraus. Unternehmensbedeutung konnte eher der Anwendung zugesprochen werden. Mit der Kombination beider Kriterien wurde das Raster noch ge-

258

6 Datenklassifizierung

nauer eingestellt. In der Einschätzung von Anwendungen, die gleiche Unternehmensbedeutung besaßen, waren die zu priorisieren, deren Anforderungen an die Serversysteme größer waren. Als erste Klassifizierungsebene wurde im Projekt KONCOM/IT also die Bedeutung der Anwendung/Server-Kombination gewählt. Da das primäre Kriterium der Klassifizierung die Anwendung darstellte, mussten Attribute, die die Bedeutung der Anwendung bestimmen, definiert und bewertet werden. Als dominierendes Attribut stellte sich die Business Continuity der Anwendungen heraus, die durch die Verfügbarkeit der Systemkomponenten ausgedrückt wird. Diese Verfügbarkeit besitzt ihrerseits beschreibende Attribute, deren Ausprägung die Klassifizierung der Verfügbarkeit ermöglichen. Durch die Einführung von Verfügbarkeitsklassen sollte eine Klassifizierung der Anwendungen hinsichtlich ihrer Verfügbarkeit, Wiederherstellungszeiten im Fehlerfall und Betriebszeiten erreicht werden. Damit werden die Anwendungen auf eine überschaubare Menge von Klassen vereinheitlicht, die den gewünschten Datenklassen zugeteilt werden können und standardisierte Lösungen für die Einhaltung der Vorgaben von Verfügbarkeitsklassen können entwickelt werden. Die EurAmFi Business Services GmbH bietet dann den Betrieb einer Anwendung unter den durch die zugeordnete Verfügbarkeitsklasse festgelegten Bedingungen als Dienstleistung an. Die EurAmFi AG, die EurATel GmbH und im Wesentlichen die OS-CARBON erhalten auf der Basis der Verfügbarkeitsklassen eine klar definierte, kalkulierbare Dienstleistungsqualität. Daher ist die Verfügbarkeitsklasse prägendes Attribut der SLAs der EurAmFi Business Services GmbH mit ihren Kunden. Nach der durch KONCOM/IT durchgeführten Zuordnung einer der von der EurAmFi Business Services betriebenen Anwendung zu einerVerfügbarkeitsklasse wurde ein Audit durchgeführt, um zu überprüfen, ob die Systemkomponenten und das System- und Betriebskonzept der Anwendung die getroffene Zuordnung zulassen. Dieses Vorgehen wurde gewählt, um schnell eine Größenordnung für die zu beschaffenden Kapazitäten der Datenklassen 1, 2 und 3 zu erhalten, im Nachgang jedoch ist die so getroffene Entscheidung detailliert zu verifizieren. Die Vorgaben der Verfügbarkeitsklasse einer Anwendung sollten nur für die Produktivsysteme gelten, d. h. für Systeme mit anderem Status wurden die geforderten Wiederherstellungszeiten oder Dienstleistungen nicht eingefordert. Das erlaubte schon zu einem früheren Zeitpunkt die Zuordnung der für den späteren produktiven Betrieb notwendigen Verfügbarkeitsklasse, da auch das Systemkonzept der Anwendung daran ausgerichtet werden musste. Die folgenden Seiten beschreiben die vom Projekt KONCOM/IT definierten und heute von der EurAmFi eingesetzten Verfügbarkeitsklassen. Dazu wurden zuerst die Attribute beschrieben, auf deren Basis Verfügbarkeitsklassen formuliert wurden. Danach wurden die Verfügbarkeitsklassen als Kombinationen von Werten für die Attribute definiert und daraus Vorschläge für die technische Umsetzung abgeleitet.

6.4 Projektbezogene Umsetzung

6.4.4

259

Abgrenzung zwischen Klassifizierung nach Verfügbarkeit, Verfügbarkeitsklasse und SLA

In Abgrenzung zu einem Service Level Agreement enthalten Verfügbarkeitsklassen keine Attribute zur System-Performance und Ähnliches. Es werden keine Festlegungen getroffen, wie die Messung der Servicequalität durchgeführt werden soll oder wie auf Abweichungen von den vereinbarten Verfügbarkeitsklassen reagiert werden soll.Ebenso waren auch nicht die Betriebskosten fürVerfügbarkeitsklassen oder Abrechnungsmodalitäten Gegenstand der Klassifizierung. Bestimmte Notfallvorsorgemaßnahmen (zum Beispiel doppelte Netzwerkanbindung, redundante SAN-Anbindung) wurden als vorhanden vorausgesetzt, Details wurden bereits im Abschnitt 6.4.1.1 „Infrastrukturstandards“ behandelt. 6.4.4.1 Attribute von Verfügbarkeitsklassen Attribute beschreiben die Eigenschaften von Verfügbarkeitsklassen. Folgende Attribute wurden von KONCOM/IT als wesentlich erachtet: • • • • •

Maximale Hardwareausfallzeit (physikalische Wiederherstellzeit) Maximale logische Wiederherstellzeit Notwendigkeit eines Service-Desk Notwendigkeit einer Betriebsbereitschaft Reaktionszeiten

Zunächst wurden die Begriffe für Zeiträume in der Störungsbearbeitung definiert. Anschließend werden hier die Attribute detailliert beschrieben und die Wertebereiche ihrer Ausprägungen definiert. Zur Abgrenzung wird auch auf Attribute von Anwendungen eingegangen, die verwandt mit Verfügbarkeitsklassen sind, diese jedoch nicht unbedingt beschreiben. Diese Attribute sind: • Haupt- und Nebenbetriebszeit der Anwendung • Sonderzeiträume wie bspw. Zeiträume von Spezialaktionen (Weihnachtsgeschäft, Ostergeschäft etc.) • Wartungszeiträume (geplante Ausfallzeiten) • Maximaler erwarteter Datenverlust bei einem Anwendungsausfall • Service-Area, in der die Anwendung betrieben wird • Zeitlicher Ablauf einer Störungsbearbeitung Abbildung 6.8 veranschaulicht den zeitlichen Ablauf einer Störungsbearbeitung und den Zusammenhang zwischen Hardwareausfallzeit (physikalischer Wiederherstellzeit) und logischer Wiederherstellzeit. Die Begriffe „Behebungszeit HW-Fehler“,„Behebungszeit logische Fehler“,„Hardwareausfallzeit“ und„logische Wiederherstellzeit“ wurden von KONCOM/IT definiert und besitzen innerhalb der EurAmFi den Status von Standardbegriffen. Anwendungen können durch zwei Arten von Fehlern ausfallen, durch Hardwarefehler – will heißen physikalischen Ausfall einer Systemkomponente – und logische Fehler. Letztere sind definiert als alle Abweichungen vom spezifizierten Ver-

260

6 Datenklassifizierung

Abb. 6.8. Zeitlicher Ablauf einer Störungsbearbeitung

halten einer Anwendung, die nicht unmittelbar auf einen Hardwarefehler zurückzuführen sind. Beispiele für logische Fehler sind Administrationsfehler (Fehlkonfigurationen, irrtümlich durchgeführte Aktionen), Softwarefehler (sowohl falsch implementierte Anwendungslogik als auch Bugs) oder Dateninkonsistenzen. In Abbildung 6.8 wird der Spezialfall gezeigt, dass ein Hardwareausfall mittelbar einen logischen Fehler nach sich zieht, etwa bei beschädigten Dateisystemen. Im Allgemeinen kann ein Hardwareausfall oder ein logischer Fehler allein auftreten, die Hardwareausfallzeit ergibt sich dann aus der Reaktionszeit und der Zeit für die Behebung des HW-Fehlers, während die logische Wiederherstellzeit die Summe aus Reaktionszeit und Zeit für die Behebung des logischen Fehlers ist. Der Begriff „Behebung“ kann nicht nur die Reparatur bzw. Korrektur des ausgefallenen Systems, sondern auch das Umschalten auf ein Ersatzsystem in einer Clusterumgebung bedeuten. Die Messung der Zeiträume der maximalen Hardwareausfallzeit und der maximalen logischen Wiederherstellzeit erfolgt immer ausschließlich innerhalb der Haupt- oder innerhalb der Nebenbetriebszeit. Wenn also ein Vorfall in der Hauptbetriebszeit auftritt und die Bearbeitung nicht vor Beginn der Nebenbetriebszeit abgeschlossen werden kann, wird die Uhr angehalten und erst beim Beginn des nächsten Zeitraums, der wieder zur Hauptbetriebszeit zählt, wieder in Gang gesetzt. Außerdem ist hier immer Rechenzentrumsverfügbarkeit gemeint, d. h. Verfügbarkeit am Standort eines Rechenzentrums. Da die Fehlerbehebung auch das

6.4 Projektbezogene Umsetzung

261

Umschalten auf ein anderes System umfassen kann, kann das lauffähige System auch an einem anderen Standort als das ausgefallene bereitgestellt werden. Die Verfügbarkeit von Endgeräten und des Netzwerks außerhalb des Rechenzentrums ist deshalb für die betrachteten Attributausprägungen irrelevant. 6.4.4.2 Maximale Hardwareausfallzeit (physikalische Wiederherstellzeit) Die Hardwareausfallzeit ist die Zeitspanne von der Meldung des Ausfalls der Anwendung bis zum Zeitpunkt, zu dem ein lauffähiges Hardwaresystem für die Anwendung wieder zurVerfügung steht.Ein System gilt als lauffähig,wenn alle für den Betrieb der Anwendung benötigten Hardwarekomponenten wieder korrekt funktionieren, alle erforderlichen Basisdienste76 entsprechend den Anforderungen der Anwendung konfiguriert sind und die Anwendung installiert, konfiguriert und somit nutzbar ist. 77 Eine Verfügbarkeitsklasse legt mit dem Attribut „maximale Hardwareausfallzeit“ getrennt für Hauptbetriebszeiten und Nebenbetriebszeiten fest, wie groß diese Zeitspanne maximal sein darf; welche Zeiten als Haupt- und Nebenbetriebszeiten gelten, legt die Anwendung fest. Die folgende Tabelle gibt die möglichen Werte des Attributs an – der angegebene Wert ist jeweils als Maximalwert zu verstehen. Tabelle 6.1. Maximale physikalischeWiederherstellzeit und zu treffende Vorkehrungen Wert in Stunden

Notwendige Realisierungen

1

Failover-Cluster (Windows-Cluster oder Veritas-Cluster oder MetroCluster) oder Software-Cluster

4

Unix-Server: Automatisierte manuelle Umschaltung, Windows-Server: Hot-Stand-By

12

Ersatzserver (direkter Ersatz vorhanden, der für mehrere Server verwendet werden kann – Springersysteme der gleichen Klasse)

48

Ersatzserver (Suche nach einem geeigneten Serversystem – Springersysteme unterschiedlicher Klasse)

–

keinerlei Vorkehrungen notwendig

6.4.4.3 Maximale logische Wiederherstellzeit Die logische Wiederherstellzeit oder Target Resolution Time (TRT) einer Anwendung ist die Zeitspanne von der Meldung des Ausfalls der Anwendung bis zur vollständigen Wiederherstellung des Zustands vor dem Ausfall, mit Ausnahme ei76

77

Basisdienste sind Systemkomponenten, hier Services, die generell für den RZ-Betrieb der EurAmFi als gegeben vorausgesetzt werden. Dazu gehören ein installiertes und konfiguriertes Betriebssystem, eine funktionierende und konfigurierte Netzwerkanbindung, falls erforderlich ein installiertes und konfiguriertes Datenbankmanagementsystem usw. Es wird davon ausgegangen, dass ein Hardwarefehler die Installation und Konfiguration (Systemdaten) der Anwendung nicht beeinträchtigt, so dass hierzu kein besonderer Aufwand notwendig ist.

262

6 Datenklassifizierung

Tabelle 6.2. Maximale logische Wiederherstellzeit und zu treffende Vorkehrungen Wert in Stunden 4

Notwendige Realisierungen Schattendatenbank, logischer Spiegel der Datenbank

12

Wiederherstellung der Datenbank aus dem Backup (Restore aus Snapshots auf schnellen Nearline-Medien)

24

Wiederherstellung der Datenbank aus dem Backup (Restore von schnellen Nearline-Medien)

48

Wiederherstellung der Datenbank aus dem Backup

–

keinerlei Vorkehrungen notwendig

nes möglichen Verlusts der Daten, die in der Zeit vor dem Ausfall bzw. Erkennen des Fehlers geändert oder erfasst wurden (eingeplanter Datenverlust). Der für die Datenwiederherstellung notwendige Zeitaufwand ist stark vom Datenvolumen der Anwendung geprägt und grundsätzlich vom Design der Anwendung abhängig (Schattendatenbank vs. Rücksicherung). Wenn zum Beispiel eine Rücksicherung notwendig ist, hängt die Dauer vom Datenvolumen ab. Ist lediglich eine Schattendatenbank zu aktivieren, ist die Dauer vom Nachfahren der Protokolldateien abhängig. Daher kann nicht jede Anwendung in jede Verfügbarkeitsklasse eingeordnet werden, sondern ist gemäß ihrem Verfahren bzgl. Schattendatenbank bzw. Rücksicherung einzugruppieren. Außerdem ist zu beachten, dass nach der logischen Wiederherstellung einer Anwendung, die mit anderen über Schnittstellen verbunden ist, die verschiedenen Datenbestände der Anwendungen voneinander abweichen können. Die maximale logische Wiederherstellzeit beinhaltet nicht die Prüfung auf Fehlerfreiheit der Anwendungsdaten. Diese kann je Anwendung und je eingesetztem Datenbankmanagementsystem und natürlich auch abhängig von der Anzahl der zu prüfenden Datenbankobjekte und des Datenvolumens stark differieren. Daher können Anwendungen zwar in eine hohe Verfügbarkeitsklasse bezüglich der logischen Wiederherstellzeit eingeordnet werden, der tatsächliche Zeitbedarf zur Prüfung auf Fehlerfreiheit kann jedoch so groß sein, dass die Anwendung mit gesicherter logischer Konsistenz der Daten erst nach einem deutlich größeren Zeitraum wieder verfügbar ist. Eine Verfügbarkeitsklasse legt mit dem Attribut „Maximale logische Wiederherstellzeit“ getrennt für Hauptbetriebszeiten und Nebenbetriebszeiten fest, wie groß die logische Wiederherstellzeit maximal sein darf. Mögliche Realisierungen und Vorkehrungen sind in Tabelle 6.2 angedeutet. Der angegebene Wert ist jeweils als Maximalwert zu verstehen. 6.4.4.4 Notwendigkeit eines Service-Desk Für Anwendungen mit hohem Hilfestellungsbedarf kann es angeraten sein, den Benutzern die Service-Desk-Dienstleistung der RZ-Produktion der EurAmFi Business Services zur Verfügung zu stellen. Dann müssen die Mitarbeiter des ServiceDesk zum einen zeitlich verfügbar und zum anderen in der Lage sein, die zu

6.4 Projektbezogene Umsetzung

263

Tabelle 6.3. Attributausprägungen„Notwendigkeit eines Service-Desk“ Wert

Bedeutung

Ja

Während der Hauptbetriebszeit steht den Benutzern der Anwendung der ServiceDesk der RZ-Produktion der EurAmFi Business Services zur Verfügung.

Nein

Der Service-Desk steht nicht zur Verfügung.

erwartenden Fragen kompetent zu beantworten. Bei der Diskussion der Verfügbarkeitsklassen wurden keine Details zu diesen Dienstleistungen, wie zum Beispiel maximale Antwortzeiten der Service-Desk-Mitarbeiter, festgelegt, da diese nicht von der Verfügbarkeitsklasse abhängen.Deshalb muss für eine Verfügbarkeitsklasse nur festgehalten werden, ob sie diese Dienstleistung einschließt oder nicht. Ob der Service-Desk für die Annahme einer Fehlermeldung zuständig ist, wird durch die Anwendung festgelegt. Das Attribut „Notwendigkeit eines Service-Desk“ regelt, ob den Anwendern eine zentrale Rufnummer während der Betriebszeiten der Anwendung zur Verfügung steht oder nicht. Im Rahmen von KONCOM/IT wurde hier lediglich die Hauptbetriebszeit der Anwendungen betrachtet. In den Nebenbetriebszeiten kann das Attribut „Notwendigkeit eines Service-Desk“ durch die entsprechenden Ausprägungen des Attributs „Notwendigkeit einer Betriebsbereitschaft“ zur Einordnung der Anwendung in eine Verfügbarkeitsklasse sinnvoll ergänzt werden. 6.4.4.5 Notwendigkeit einer Betriebsbereitschaft Der Bereitschaftsdienst der RZ-Produktion der EurAmFi Business Services für eine Anwendung erlaubt im Falle von Problemen eine wesentlich schnellere Reaktionszeit, speziell in Nebenbetriebszeiten. Eine Abstufung der Qualität dieser Dienstleistung wird wie auch schon beim Attribut „Notwendigkeit eines ServiceDesk“ nicht gemacht. Auch inhaltliche Festlegungen etwa zum Umfang der Leistungen wurden im Rahmen von KONCOM/IT zur Einordnung einer Anwendung in eine Verfügbarkeitsklasse nicht diskutiert.Wie schon bezüglich der Ausprägungen des Attributs „Notwendigkeit eines Service-Desk“ reicht deshalb auch für die „Notwendigkeit einer Betriebsbereitschaft“ pro Verfügbarkeitsklasse die Angabe, ob sie einen Bereitschaftsdienst beinhaltet oder nicht. Wenn eine Verfügbarkeitsklasse einen Bereitschaftsdienst enthält, dann muss sie auch einen Service-Desk benötigen, da dieser die Reaktionszeit innerhalb der Hauptbetriebszeiten, der Be-

Tabelle 6.4. Attributausprägungen„Notwendigkeit einer Betriebsbereitschaft“ Wert

Bedeutung

Ja

Während der Hauptbetriebszeit steht eine Betriebsbereitschaft für die Anwendung zur Verfügung.

Nein

Es steht keine Betriebsbereitschaft zur Verfügung.

264

6 Datenklassifizierung

reitschaftsdienst jedoch im Wesentlichen die Reaktionszeiten in den Nebenbetriebszeiten garantiert. 6.4.4.6 Reaktionszeiten Die Reaktionszeit ist die Zeit zwischen der Meldung eines Störfalls und dem Start der Bearbeitung durch die RZ-Produktion der EurAmFi Business Services. Die Definition der Reaktionszeit für eine Anwendung als Attribut der Verfügbarkeitsklasse, zu der die Anwendung zugeordnet wird, verfolgt operative Ziele: • Begrenzung des Interpretationsspielraumes hinsichtlich der Bearbeitungsreihenfolge bei der Bearbeitung von gleichzeitig auftretenden Störfällen mit gleicher Priorität. • Schaffung eines zeitlichen Spielraums zur Herstellung der Handlungsfähigkeit der RZ-Produktion der EurAmFi Business Services insbesondere im Bereitschaftsfall (Nebenbetriebszeiten). • Verlässliche Definition des Mindest-Startzeitpunktes der fachlichen Störfallbearbeitung. Als Bezugspunkt für die Ausgestaltung der Reaktionszeit stehen die zuvor bereits definierten Attribute der jeweiligen Verfügbarkeitsklasse zur Verfügung. Die höchste Abhängigkeit kann man dabei von den zeitlichen Vorgaben für die maximale Hardwareausfallzeit (physikalische Wiederherstellzeit) ableiten. Grundsätzlich sind für den Start des Vorfallsbearbeitungsprozesses zwei auslösende Instanzen denkbar. 6.4.4.6.1 Störfallauslösung durch Benutzermeldung Benutzermeldungen werden generell an die zentrale Telefonnummer oder Mailadresse des Service-Desk der EurAmFi Business Services gerichtet. Störfälle, die nicht mit Ressourcen des Service-Desk gelöst werden können, werden darüber hinaus an die entsprechenden Fachteams der RZ-Produktion weitergeleitet. Dabei wird in der Betriebszeit (06:30 Uhr – 20:00 Uhr) des Service-Desk eine Benutzermeldung direkt aufgenommen. Außerhalb dieser Zeit eingehende Benutzermeldungen werden an die Nummer einer Service-Desk-Bereitschaft weitergeleitet. Daraus resultierende Störfälle werden an das entsprechende RZ-ProduktionsFachteam oder – außerhalb der Hauptbetriebszeiten – an die jeweilige Betriebsbereitschaft weitergeleitet. 6.4.4.6.2 Störfallauslösung durch Betriebsalarm (Alert-Management) Die von der EurAmFi Business Services betreuten Applikationen werden ständig von verschiedenen Systemen überwacht. Bei Eintritt undefinierter Zustände werden entsprechende Alarmierungen direkt an die Fachteams der RZ-Produktion versendet (ohne Einbeziehung des Service-Desk). Auf dieser Basis werden unter Berücksichtigung der möglichen Startpunkte für den Störfallbearbeitungsprozess folgende Reaktionszeiten (unabhängig von der Art der Betriebszeit) definiert:

6.4 Projektbezogene Umsetzung

265

Tabelle 6.5. Attributausprägungen„Reaktionszeiten“ Auslöser: Herkunft des Störfalls

Maximale physikalische Wiederherstellzeit

Reaktionszeit

Service-Desk innerhalb der ServiceDesk-Betriebszeiten

≤ 1Stunde

≤ 15 Minuten

Service-Desk außerhalb seiner Betriebszeiten

≤ 1 Stunde

1,0 Stunden78

> 1 Stunde

1,5 Stunden

Betriebsalarm

≤ 1 Stunde > 1 Stunde

0,5 Stunden 1,0 Stunden

6.4.4.7 Betriebszeiten Für die Festlegung von Verfügbarkeitsklassen wird die Gesamtbetriebszeit in zwei Betriebszeit-Bereiche unterteilt, Hauptbetriebszeit und die Betriebsnebenzeit (Nebenbetriebszeit). Die Hauptbetriebszeit grenzt die übliche Online-Arbeits/Nutzungszeit der Anwendung ein, so dass in diesem Zeitraum bei einem Ausfall der Anwendung erhebliche Auswirkungen auf die Arbeitsweise der Benutzer der Anwendung zu erwarten sind. Die restlichen Betriebszeiten ergeben die Nebenbetriebszeit, in der ein Anwendungsausfall weniger gravierend ist. Bei einem Ausfall in der Nebenbetriebszeit wird also ein geringerer Schaden erwartet als bei einem in der Hauptbetriebszeit. Es gibt für die Unternehmen im EurAmFi-Konzern keine einheitliche Regelung für die Hauptbetriebszeit, zudem spielt der Wochentag eine Rolle. Teilweise unterscheiden sich die üblichen Arbeitszeiten am Donnerstag (Dienstleistungsabend), Freitag (Ausgleichstag für 38,5-Stunden-Woche), Sonnabend und Sonntag von denen der übrigen Wochentage. Verfügbarkeitsklassen aus KONCOM/IT nennen keine konkreten Betriebszeiten, sondern unterscheiden nur Haupt- und Nebenbetriebszeit. Die konkreten Zeiten müssen für jede Anwendung festgelegt werden.Außerdem muss klargestellt werden,wie Feiertage zu behandeln sind.Dies kann entweder direkt für jede Anwendung oder indirekt in einem SLA geschehen. Beispielsweise kann ein SLA festlegen, dass Feiertage wie Sonntage zu behandeln sind, oder Sonderregelungen treffen. Aus den Betriebszeiten ergibt sich gegebenenfalls die Anzahl der Tage sowie die Zeiträume, in denen der Service-Desk oder der Bereitschaftsdienst der EurAmFi Business Services-RZ-Produktion zur Verfügung stehen müssen. Dabei ist jedoch auch zu beachten, dass die Anwendung unter Umständen sehr wohl auch außerhalb der Hauptbetriebszeit hochverfügbar sein muss. Dies gilt im Wesentlichen für die Schnittstellen mit anderen Systemen, aber auch für 78

Verfügbarkeitsklassen mit einer maximalen Hardwareausfallzeit von 1 Stunde setzen Systemkonzepte mit automatisierten Hochverfügbarkeitsverfahren (z. B. Cluster) voraus – d. h., ein Cluster-Server-Schwenk erfolgt im Fehlerfall immer automatisiert. Ein Eingriff seitens des RZ-Produktions-Fachteams der EurAmFi Business Services ist nicht erforderlich, jedoch erfolgt eine automatisierte Alarmierung über das Alert-Management.

266

6 Datenklassifizierung

verarbeitende (Batch-)Teile der Anwendung, die eben gerade in den Zeiten mit dem geringsten Online-Aufkommen abgearbeitet werden, also üblicherweise nicht während der Hauptbetriebszeit, um dann keine zusätzliche Last zu erzeugen. Diese Anwendungsteile sind aber dennoch nicht zu vernachlässigen. 6.4.4.8 Sonderzeiträume Die IT-Anwendungen im EurAmFi-Konzern unterstützen die Geschäftsprozesse des Unternehmens und werden je nach deren Gewicht für den Erfolg des Konzerns unterschiedlichen Verfügbarkeitsklassen zugeordnet. Bei nur selten auftretenden Geschäftsprozessen kommt es jedoch zu einem Ungleichgewicht: Stellt der beispielsweise monatlich ausgeführte Geschäftsprozess wesentlich höhere Ansprüche als die übrigen Prozesse, dann lohnt sich einerseits die Einstufung in eine aufwendige und damit in der Leistungserbringung teurere Verfügbarkeitsklasse nicht – andererseits kann der Schaden im Falle eines Ausfalls während dieses wichtigen Prozesses erheblich sein. Deshalb müssen Sonderzeiträume für Anwendungen vereinbart werden können, in denen diese zusätzliche Dienstleistungen in Anspruch nehmen, also beispielsweise die Verfügbarkeit des Service-Desks und/oder der Betriebsbereitschaft. Klassische Beispiele für solche Sonderzeiträume sind die zu Ostern und Weihnachten wiederkehrenden Sonderaktionen der EurATel, da traditionell im Telefonie- und Internet-Geschäft diese Zeiträume die Hauptgeschäftszeiträume des gesamten Jahres darstellen. In diesen Zeiträumen werden sämtliche Anwendungen der EurATel mit zusätzlichen Dienstleistungen der RZ-Produktion der EurAmFi Business Services höchst verfügbar gehalten. 6.4.4.9 Wartungszeiträume In Wartungszeiträumen (auch Wartungsfenster genannt) können Anwendungen geplant angehalten werden, um Wartungsarbeiten wie etwa das Einspielen von Patches, die logische Reorganisation der Datenbanken usw. zu erledigen. Natürlich sollten diese Zeiträume weder in den Hauptbetriebszeiten noch in den Sonderzeiträumen liegen, um die Benutzer der Anwendung nicht unnötig zu behindern. Zusätzlich müssen Wartungszeiträume in 24x7-Anwendungsbetrieben möglichst kurz sein. Wie auch die Betriebszeiten und Sonderzeiträume müssen die Wartungszeiträume individuell pro Anwendung festgelegt werden, um nicht die Wartungsarbeiten bei mehreren Anwendungen unnötigerweise alle im selben kurzen Zeitraum durchführen zu müssen. Wartungszeiträume sind deshalb kein Attribut von Verfügbarkeitsklassen, sondern von Anwendungen. 6.4.4.10 Maximaler geplanter Datenverlust Durch einen Ausfall können Anwendungsdaten unrettbar verloren gehen. Betroffen sind alle Daten, die seit der letzten Datensicherung bis zum Ausfall erfasst wurden; Datensicherung in diesem Sinne ist zum Beispiel auch das Synchronisieren einer Schattendatenbank über Log-Dateien („Redo-Log-Shipping“). Auch Änderungen an bestehenden Daten, die in diesem Zeitraum durchgeführt wurden,

6.4 Projektbezogene Umsetzung

267

sind dann verloren. Da die Größe der Zeitspanne vom Datensicherungskonzept der Anwendung abhängt und dieses nicht Bestandteil einer Verfügbarkeitsklasse ist, stellt der maximal akzeptable Datenverlustzeitraum kein Attribut von Verfügbarkeitsklassen dar, sehr wohl aber ist der maximale geplante Datenverlust ein Attribut der Anwendung selbst. 6.4.4.11 Betriebsumgebung der Anwendung Die EurAmFi stellt für den Betrieb ihrer Anwendungen spezielle, klar abgegrenzte Betriebsumgebungen (Service-Areas) zur Verfügung. Eine Service-Area stellt einen speziell geschützten Netzwerkbereich dar, in dem eine Anwendung samt der benötigten Infrastruktur betrieben werden kann. Der Zugang einer Service-Area von und zu79 anderen Netzwerkbereichen ist stark eingeschränkt, um Missbrauch zu verhindern. Das Service-Area-Konzept ist zentraler Bestandteil des Sicherheitskonzeptes der EurAmFi und wurde daher für die von KONCOM/IT betroffenen Systeme und Anwendungen strikt verfolgt. Für eine Verfügbarkeitsklasse muss jedoch nicht festgehalten werden,ob ihre Anwendungen eine Service-Area erfordern oder nicht. Dies ist eine Entscheidung, die abhängig vom Schutzbedarf und nicht abhängig von der Anforderung nach Verfügbarkeit (und damit der Verfügbarkeitsklasse) getroffen werden muss. Verfügbarkeitsklasse und Schutzbedarf einer Anwendung können also vollkommen unabhängig voneinander gewählt werden.

6.4.5 Verfügbarkeitsklassen Verfügbarkeitsklassen zur Datenklassifizierung von KONCOM/IT wurden festgelegt, indem für jedes der oben definierten Attribute ein Wert gewählt wurde. Zur Identifikation wurden die Verfügbarkeitsklassen fortlaufend nummeriert, eine Wertung war damit implizit verbunden. Die folgende Tabelle definiert die Verfügbarkeitsklassen. Aus Gründen der Übersichtlichkeit sind einige Attributnamen abgekürzt worden: Betriebszeiten = BZ (im Gegensatz zu Sonderzeiten), Hauptbetriebszeit = HBZ, Nebenbetriebszeit = NBZ, maximale Hardwareausfallzeit = max. HW, maximale logische Wiederherstellzeit = max. log. Jede von der EurAmFi Business Services GmbH für die EurAmFi, deren Tochtergesellschaften sowie deren Kunden (OS-CARBON) betriebene Anwendung musste einer dieser Verfügbarkeitsklassen zugeordnet werden. Als relativ unbedeutsam erkannte Anwendungen werden stets der Verfügbarkeitsklasse 8 zugeordnet, die praktisch keine Anforderungen an die Verfügbarkeit stellt.

79

Dies wird technisch dadurch realisiert, dass die eingehende Netzwerk-Kommunikation über Firewall-Regeln gefiltert wird. Durch die Definition von „Eingangsregeln“ für jede Betriebsumgebung, jeden Netzbereich einer Service-Area werden diese de facto ebenfalls zur Einschränkung für die ausgehende Kommunikation. Dies heißt, aus einer ServiceArea der EurAmFi AG kann nur die Kommunikation in eine zweite Service-Area erfolgen, die über deren Eingangsregeln zugelassen ist.

268

6 Datenklassifizierung

Tabelle 6.6. KONCOM/IT-Verfügbarkeitsklassen Klasse

HBZ max. HW

max. log.

NBZ max. HW

max. log.

Service-Desk in BZ

Bereitschaft in BZ

1

1

4

4

12

J

J

2

4

4

4

12

J

J

3

4

12

12

24

J

J

4

1

4

–

–

J

N

5

4

12

–

–

J

N

6

12

24

–

–

J

N

7

48

48

–

–

N

N

8

–

–

–

–

N

N

6.4.6 Verfügbarkeitsklassen und KONCOM/IT-Datenklassen Die generellen EurAmFi-Betriebsstandards für Speichersysteme sehen vor, dass sämtliche von KONKOM/IT betroffenen Server-/Clustersysteme zumindest zweipfadig über ein SAN mit externen Speichersystemen angeschlossen werden müssen.Die Klassifizierung über die Verfügbarkeit der Server/Anwendungs-Kombination sollte lediglich für Produktivsysteme gelten. Bei den drei angestrebten Datenklassen Hochverfügbarkeitsdaten, Nearline-Daten und Archivdaten waren die ersten beiden Klassen als SAN-basierte Speichersysteme zu realisieren. Die Datenklasse der Nearline-Daten war auf lokal abgesicherten Speichersystemen der Midrange-Klasse abzulegen.Die Datenklasse der Hochverfügbarkeitsdaten war auf Speichersystemen der Enterprise-Klasse mit K-Fall-Absicherung durch RemoteSpiegelung zu realisieren. Mit diesen von KONCOM/IT herausgearbeiteten Klassifizierungen konnten die Anwendungen auf die zu beschaffenden Speichersysteme verteilt, deren Anzahl, Ausstattung und Verteilung geplant, Pflichtenheft und Ausschreibungsunterlagen erstellt und die Ausschreibung mit Herstellerauswahl durchgeführt werden. Gemäß der Verteilung der Anwendungen wurden von KONCOM/IT folgende Regeln definiert und im Projekt geplant und realisiert: • Sämtliche Entwicklungssysteme werden logisch den Verfügbarkeitsklassen 7 und 8 zugeordnet80 und auf Nearline Speicher der Datenklasse 2 implementiert. 80

Sowohl Entwicklungs- als auch PreLife- und Testsysteme gehörten per Definition nicht zu Produktivsystemen, waren also von KONCOM/IT auch keiner Verfügbarkeitsklasse zuzuordnen. Projektintern wurde dennoch so verfahren, um zumindest die Risiken des Ausfalls der Systeme berücksichtigen zu können. So bedeutete der Ausfall einer Entwicklungsumgebung des Siebel-CRM-Systems den Stillstand der Siebel-Entwicklung. Diese wurde von einem Projekt außerhalb des Projektes KONCOM/IT betrieben. Die SiebelEntwicklung war mit 16 Projektmitarbeitern besetzt, die im Zweifelsfalle bei Ausfall der Entwicklungsumgebung beschäftigungslos wären. Dennoch wurde seitens der EurAmFi AG eine maximale logische Wiederherstellzeit von größer gleich 48 Stunden vorgegeben,

6.4 Projektbezogene Umsetzung

269

• Sämtliche Pre-Life- und Testsysteme werden logisch den Verfügbarkeitsklassen 7 und 8 zugeordnet81 und ebenfalls auf Nearline-Speicher der Datenklasse 2 implementiert. • Sämtliche Server- und Clustersysteme,auf denen Anwendungen betrieben werden,die denVerfügbarkeitsklassen 1 bis 4 zugeordnet wurden,werden auf Speichersystemen der Datenklasse 1 implementiert. Hier wurden lediglich die Anwendungen diskutiert, die in den Nebenbetriebszeiten keine Anforderungen an die maximale logische Wiederherstellzeit oder physikalische Wiederherstellzeit stellten. Da jedoch die Hauptbetriebszeiten sämtlicher Anwendungen dieser Verfügbarkeitsklasse mit Ausnahme der Wochenenden täglich waren, hätte eine maximale logische Wiederherstellungszeit von größer als 24 Stunden – außer bei Störfalleintritt in der Nebenbetriebszeit ab Freitag 20:00 Uhr bis Sonntag 06:00 Uhr – stets Auswirkungen auf die Hauptbetriebszeit der Anwendungen gehabt. Daher wurden die Anwendungen und Server der Verfügbarkeitsklasse 4 denen der Verfügbarkeitsklasse 3 gleichgestellt. Sämtliche Server- und Clustersysteme,auf denen Anwendungen betrieben werden, die den Verfügbarkeitsklassen 5 bis 8 entsprechen, wurden auf Speichersystemen der Datenklasse 2 realisiert. Mit dieser Klassifizierung über die Verfügbarkeit der Kombination Server/Anwendung war die Implementierung des Tiered-Storage für die Informationslebenszyklus-Phasen • Erstellung, • Verdichtung und • Nutzung für KONCOM/IT erreicht. Die Implementierung und Automatisierung des TieredStorage-Konzeptes für die Lebenszyklusphasen Bewahrung und Archivierung forderte von KONCOM/IT weitere Stufen der Datenklassifizierung. Die Entscheidung darüber, welche Informationen zur Bewahrung von Datenklasse 1 automatisiert auf günstigere Medien der Datenklasse 2 oder innerhalb der Datenklasse 2 über Änderung der Sicherungsmechanismen migriert werden sollten, bedurfte der Klassifizierung über Metadaten.Die Entscheidung darüber,welche Informationen zur Sicherung der Compliance-Anforderungen an die internationalen Gesetze und Rechtsvorschriften auf Speicher der Datenklasse 3 migriert werden sollten, und Wege zur Automatisierung dieser Migrationen erforderte die detaillierteste Datentypisierung des Projektes, die Typisierung nach Content der Daten. Beide weiter reichende Datentypisierungen werden im Folgenden dargestellt.

81

da die TCO einer höheren Verfügbarkeit das unproduktive „Herumsitzen“ der Entwickler bei der geringen Ausfallwahrscheinlichkeit der Entwicklungsumgebung (durch den Ausbau der Server, die lokale Absicherung der Speichersysteme und den doppelpfadigen Ausbau der SAN-Anbindung der Server wurde eine Verfügbarkeit von 99,5 % für die Entwicklungsumgebungen erreicht) weit überstiegen hätte. Vgl. vorige Fußnote.

270

6 Datenklassifizierung

6.4.7

Klassifizierung mit Hilfe von Metadaten

Wie bereits dargestellt sind Metadaten Daten, die Daten beschreiben und anhand derer das eigentliche Datum automatisch klassifiziert und – unserem Zweck entsprechend – der korrekten Datenklasse und Speicherklasse zugeordnet werden kann. Die für KONCOM/IT in Frage kommenden Parameter oder Metadaten waren diejenigen, die automatisiert mit der Bearbeitung unstrukturierter Daten in Dateien abgelegt und gepflegt werden. Dabei handelt es sich klassischerweise um die Dateiparameter, die auch von den jeweiligen Dateisystemen zur Adressierung der Dateien verwendet werden: • Benutzer/Ersteller (Klassifikation nach Autorisierung) • Benutzergruppe • Datum der letzten Modifikation Nach Durchführung der Klassifikation gemäß der Bedeutung von Server/Anwendung wurden die Daten der betreffenden Anwendungen auf Speichersysteme der Datenklasse 1 und Datenklasse 2 verteilt. Allgemein wurde eine Unternehmenspolitik eingeführt, dass Daten, die mehr als 90 Tage nicht mehr modifiziert wurden, zur Archivierung markiert wurden. Es wurde ein Daemon entwickelt, der die Dateisysteme der Server nach solchen zu archivierenden Daten durchsuchte und den Dateinamen sowie die Metadaten der Dateien nach Benutzergruppen und Benutzern sortiert vorlegte. Für KONCOM/IT wurde im zweiten Durchlauf eine Klassifizierung nach diesen Metadaten durchgeführt. Hier wurde – um archivierungsrelevante Dokumente zu entdecken – zunächst nach dem Parameter Autorisierung klassifiziert. Die unstrukturierten Dateien bestimmter Benutzer und Benutzergruppen konnten von der Notwendigkeit zur Archivierung ausgeschlossen werden. Hierbei handelte es sich im Wesentlichen um interne Leistungserbringer, die keinerlei direkten Kundenkontakt pflegen und die auch keine produktions-, verfahrens- und kaufmännisch relevante Dokumentation zu pflegen hatten. Für diese Benutzer wurden die Daten außerhalb der Datenklasse 3, die von dem Daemon als zu archivieren markiert und – nach Nachfrage beim Benutzer – von diesem als zu archivieren gemeldet wurden,direkt auf Band archiviert.Dateien,die der Benutzer gelöscht haben wollte,wurden vor der tatsächlichen Löschung nochmals zur Sicherheit nach bestimmten Klassifizierungsmerkmalen des Inhaltes durchsucht (vgl. Kapitel 6.4). Enthielten die Dateien keines dieser Klassifizierungsmerkmale, so wurden sie gelöscht. Mit Benutzern und Benutzergruppen,die prinzipiell Compliance-relevante Daten bearbeiten, wurde vergleichbar verfahren. Für diese wurde lediglich in der Datenklasse 3 ein Archivbereich bereitgestellt, in dem die nach dem obigen Verfahren klassifizierten Dateien archiviert wurden.

6.4.8

Content-basierte Klassifizierung

Die Klassifizierung nach dem Inhalt der Dateien wurde als letzte Stufe durchgeführt. Hierzu wurden die in der Klassifizierung nach Metadaten als zu archivie-

6.4 Projektbezogene Umsetzung

271

ren markierten Dateien von einem zweiten Daemon nach dem Vorkommen einer vom Projekt definierten Stichwortliste durchsucht. Diese Stichwortliste wurde von den Rechts- und Controlling-Abteilungen der beteiligten Unternehmen gemäß den Compliance-Anforderungen an Energieversorgungs-, ITK- und IT-BetriebsUnternehmungen erstellt. Sämtliche Dateien, in denen der Daemon zumindest eines der definierten Schlüsselwörter oder Textcharakteristika (bspw. Währungskürzel wie USD oder EUR, alphanumerische Zeichen, die als Zahl mit zwei Dezimalstellen interpretiert werden konnten) vorfand,wurden nach Ablauf der Modifikationsfrist von 90 Tagen auf Speichersysteme der Datenklasse 3 migriert. Der von KONCOM/IT implementierte Klassifizierungspfad stellt somit eine dreistufige Klassifizierung dar, die halbautomatisiert – basierend auf GeschäftsPolicies der beteiligten Unternehmen – durchgeführt wurde.Die entwickelten Daemons werden auch noch heute nach der initialen Zuordnung der Dateien zu Datenklassen für Neudaten verwendet.

7 Sicherheit

7.1

Speichersicherheit

In der Vergangenheit war Speicher physikalisch und logisch isoliert. Es wurde auf DAS (Direct Attached Storage) gesichert. Nur derjenige, der von seinem Rechner aus speicherte, griff auch wieder auf die Daten zu. Diese Art der Datensicherung wird zunehmend aufgrund der wachsenden Datenpräsenz ineffizient. NAS (Network Attached Storage) und schließlich SAN (Storage Area Network) mit dem Fibre-Channel-Protokoll (FC) ersetzten schnell die traditionellen Konzepte. Die Gefahr von Angriffen aus dem weltweiten Netz blieb gerade mit FC noch gering.Der Grund ist banal.Das FC-Protokoll ist weniger bekannt und durchschaubar als das IP-Protokoll. In den letzten Jahren kommen gerade im WAN-Bereich (WAN – Wide Area Network) jedoch auch IP-basierte Speichernetzwerke zum Einsatz. Das hier verwendete Internet-Protokoll (IP) ist von Angreifern bis aufs Kleinste auseinandergenommen, jede Schwachstelle bekannt und „beliebt“. Leider spüren das auch die auf Speichernetze und IP gleichermaßen konzentrierten neuen Protokolle wie iSCSI oder FCIP. Sie nutzen die Vorteile von IP, versenden Befehle getunnelt über das klassische Protokoll und können so große Distanzen überbrücken, um Rechenzentren in geografisch verteilten Standorten zu erreichen. Unglücklicherweise ist iSCSI noch nicht auf einem hohen Sicherheitsniveau, auch wenn neue Standards auf dem richtigen Weg sind. Während IPSec durch den im IP-Protokoll verwendeten Sicherheitsstandard beispielsweise DoS-Attacken abwehren kann, muss diese Funktion in iSCSI erst noch implementiert werden. Der Aufbau von Verschlüsselungsmechanismen und Zugangskontrollen jeder Art, die Speichernetze mit ihren ruhenden und ständig bewegten Daten vor Zugriffen schützen, hat gerade erst begonnen. Neben der Gefahr von außen lauert selbige insbesondere von innen. Gemeint sind Mitarbeiter, die versehentlich oder absichtlich Informationen einsehen,gebrauchen oder gar verändern,die eigentlich nicht für sie bestimmt sind. Der Wunsch nach schnellem und einfachem Zugang zu alle relevanten Informationen, im Idealfall von jedem Arbeitsplatz weltweit und mobil, unterstreicht die Bedeutung der Information für den Unternehmenserfolg. Auskunft, die von jedem Ort und jederzeit zugänglich ist, gibt erst die Freiheit, erfolgreich Projekte zu managen und Aufgaben an jedem Ort und in jeder Zeitzone effizient abzuwickeln. Die Konsequenz dieser Freiheit ist, dass auch Konkurrenten, Regierungen,

274

7 Sicherheit

Industrie- und Wirtschaftsspionage und sogar verstimmte Angestellte sich durch bekannte und unbekannte Löcher einen Zugang zu den privilegierten Daten verschaffen können. Außer die Information zu kopieren, können sie sich legitimen Zugang zu den meist schlecht gesicherten Aufbewahrungsorten verschaffen und Informationen verändern oder wertvolle Informationen zerstören. In der vernetzten Speicherwelt sind die Brennpunkte die Zugangspunkte. Wird das Speichernetz direkt an öffentlichen Netzen angeschlossen, ist eine Hintertür geschaffen worden. Die Sicherung des Zugangs zu vertraulichen Informationen ist ein andauernder Akt. Sicherheits-Best-Practices benötigen einen einheitlichen und durchgängigen unternehmensweiten Security-Management-Plan. Aktuell ist es noch einfacher, die an einem festen Ort gespeicherten Daten auszuspionieren als solche, die durch das Netz fließen. So bieten zentrale Datenspeicherungen eine beängstigend große Angriffsfläche für die mehr als 25 unterschiedlichen Angriffstechniken allein aus dem Internet. Sichere Datenspeicherung ist aber entscheidend, um das geistige Eigentum und die Betriebsgeheimnisse zu schützen und sich gemäß den einschlägigen Vorschriften zu verhalten (wie z. B. SarbanesOxley, HIPAA, Gramm-Leach-Bliley und SEC 17a4).

7.2

Klassische Sicherheitskonzepte bei zentraler Datenspeicherung

Gegenwärtige Sicherheitskonzepte in den zentralen Datenspeicherinfrastrukturen sind darauf fokussiert, die externe Grenze zu schützen, d. h. den Standort des Datenspeichers und den notwendigen Verkehr bei Zugriff auf den zentralen Datenspeicher nur über sichere Netzwerke zu erlauben. Nur wo dies aus wirtschaftlichen Gründen nicht möglich ist, werden virtuelle Privatnetze (VPNs) und Rand-Router-Zugriffssicherungslisten (ACLs) eingesetzt. Die Instrumente im Bereich Sicherheit sind: • • • • •

Firewalls Virtual Private Networks (VPNs) Access Control Lists (ACLs) Fibre-Channel- (FC-)Verkabelung Kontinuierliche Datensicherung

7.2.1

Firewall

Eine Firewall (von engl. Firewall – Brandmauer) ist entweder eine spezifische Hardware oder Software, die den Zugriff auf das Rechnernetz einschränkt oder gar ganz verhindert. In einer Firewall werden bestimmte Sicherheitskonzepte umgesetzt. Hardwarekomponenten einer Firewall sind Rechner mit Netzwerkschnittstellen wie Router oder Hosts. Softwarekomponenten einer Firewall sind spezifische Paketfilter, Stateful Inspections, Content Filter oder Proxyserver. Der Einsatzzweck einer Firewall im Rahmen von ILM besteht darin, den Datenverkehr

7.2 Klassische Sicherheitskonzepte bei zentraler Datenspeicherung

275

zwischen einem zu schützenden lokalen Speichernetzwerk (NAS oder SAN) und dem Internet zu kontrollieren. Zusätzlich werden immer häufiger „Intrusion Detection Systeme (IDS)“ und „Intrusion Prevention Systeme (IPS)“ in eine Firewall integriert.Da IDS einen Einbruchversuch in ein System nur anhand von Kommunikationsmustern (zum Beispiel Portscans) aufdeckt, ist es aber wohl nicht wirklich als Firewall-Technologie anzusehen. IPS hingegen ist tatsächlich eine FirewallTechnologie, da hierbei nach dem Erkennen eines Einbruchversuches Gegenmaßnahmen getroffen werden, wie zum Beispiel das zeitlich begrenzte Sperren der vermutlich attackierenden IP-Adresse.

7.2.2 Virtual Private Network Ein Virtual Private Network (VPN) ist ein Netzwerk, das zum Transport privater Daten ein öffentlich zugängliches Netz, wie zum Beispiel das Internet, nutzt. Man unterscheidet grundsätzlich bei VPNs zwischen zwei Formen: • Site-to-Site: Sollen zwei lokale Netze verbunden werden, wird auf beiden Seiten ein VPN-Gateway verwendet. Diese bauen dann untereinander eine VPNVerbindung auf. Andere Rechner in einem lokalen Netz verwenden nun den Gateway auf ihrer Seite, um Daten in das andere Netz zu senden. So lassen sich zum Beispiel zwei weit entfernte Standorte einer Firma verbinden (Siteto-Site-VPN). • Site-to-End: VPNs werden oft verwendet, um Mitarbeitern außerhalb einer Organisation oder eines Unternehmens Zugriff auf das interne Netz zu geben. Dabei baut der Computer des Mitarbeiters eine VPN-Verbindung zu dem ihm bekannten VPN-Gateway des Unternehmens auf. Über diese Verbindung ist es dem Mitarbeiter nun möglich, so zu arbeiten, als ob er im lokalen Netz der Firma wäre (Remote-Access-VPN). Dieses Verfahren wird auch verwendet, um WLANs und andere Funkstrecken zu sichern (End-to-Site-VPN). Der Begriff „Private“ in VPN impliziert jedoch nicht, wie vielfach angenommen, dass es sich zwingend um eine verschlüsselte Übertragung handelt. Private bedeutet lediglich, eine Verbindung der Netze wird über einen Tunnel zwischen dem VPN-Client und VPN-Server (Concentrator) hergestellt, der oft eine feste Bandbreite als Übertragungskapazität hat. Meist wird der Tunnel dabei gesichert, aber auch ein ungesicherter Klartexttunnel ist ein VPN. IP-VPNs nutzen das Internet zum Transport von IP-Protokoll-basierten Paketen unabhängig vom Übertragungsnetz, was im Gegensatz zum direkten Remote-Zugriff auf ein internes Netz häufig wesentlich flexibler und kostengünstiger ist. Meist ist ein Nebenprodukt der Verschlüsselung die Datenkomprimierung, so dass sich der Mehraufwand für Verschlüsselung und Datenkomprimierung in geringeren Bandbreiten bei der Datenübertragung auszahlt. VPNs in Speichernetzwerken sind immer dann nützlich: • wenn feste, garantierte Bandbreiten zwingend erforderlich sind, • wenn öffentliche Netze wie das Internet genutzt und die Daten gekapselt oder verschlüsselt werden müssen und

276

7 Sicherheit

• wenn die vorhandene Bandbreite für die geforderte Datenübertragungsrate nicht ausreicht.

7.2.3

Access Control List

Für die Beurteilung der Sicherheit von Computersystemen werden die Sicherheitssysteme zur Verwaltung von Zugriffsrechten in zwei Klassen eingeteilt: • Discretionary Access Control: Zugriff wird aufgrund der Identität des Akteurs (Benutzers) und Objektes gewährt oder verweigert. In diese Klasse fällt zum Beispiel der Zugriffsschutz für Dateien in den gängigen Dateisystemen. • Mandatory Access Control bzw. multiliterale Sicherheitsmodelle: Hier wird der Zugriff aufgrund allgemeiner Regeln und Eigenschaften von Objekten und Subjekten gewährt oder verweigert. Dies ist ein wichtiger Bestandteil von Hochsicherheitssystemen und geht oft mit der Forderung einher, dass die Zugriffskontrolle durch einen Referenzmonitor implementiert wird. Modell und Verwaltung der Zugriffsrechte ist ein wichtiger Bestandteil sicherer Computersysteme und daher Kriterium der Zertifizierung gemäß den gängigen Sicherheitsstandards wie TCSEC und ITSEC. Eine Möglichkeit, die Zugriffsrechte sehr flexibel zu gestalten, sind somit die Zugriffskontrolllisten: Für jedes zu schützende Objekt gibt es eine Liste, die für jeden Benutzer (Benutzerrolle) oder jede Gruppe angibt, welche Zugriffe erlaubt sind und welche nicht. Die Access Control List (ACL) wird von Betriebssystemen und Anwendungen verwendet, um zu kontrollieren, welcher Benutzer zu welchen Diensten (Dateien, Netzwerkdiensten) Zugang hat. ACLs sind meist feiner einstellbar als reguläre Zugriffsrechte. So ist es mit vielen ACL-Systemen möglich, einem Prozess, beispielsweise dem FTP-ServerProzess, exakt die Rechte zu geben, die er zur Erledigung seiner Aufgaben braucht, aber nicht mehr. So darf er etwa seine Konfigurationsdatei lesen, Programmbibliotheken laden etc. Der Prozess darf aber keine Shell starten oder bestimmte Systemaufrufe ausführen, wie es unter Unix oft der Fall ist. In der Unixwelt versteht man unter Access Control List eine Erweiterung der „normalen“ Zugriffssteuerung auf Ebene des Benutzer-Gruppe-Welt-Modells. Bei Access Control Lists lassen sich Zugriffsrechte spezifisch für einzelne Benutzer zuteilen oder verbieten. Als erstes Unix unterstützte HP-UX dieses Modell der erweiterten Zugriffssteuerung. Mittlerweile bieten auch Linux, FreeBSD (TrustedBSD) und Solaris (TrustedSolaris) native Unterstützung für ACLs. Unter Linux unterstützen dabei die Dateisysteme ext2, ext3, JFS, XFS und ReiserFS ACLs vollständig. Mit der KDE-Version 3.5 steht auch der Dateimanager Konqueror mit nativer ACL-Unterstützung zur Verfügung. Für den GNOME-Desktop beherrscht der Dateimanager Nautilus seit Version 2.16 native ACLs. ACLs werden in Linux statisch vererbt, d. h. die Berechtigungen pflanzen sich in neu angelegte Unterverzeichnisse und Dateien je nach Bedarf fort. Wird die ACL eines übergeordneten Verzeichnisses geändert, hat dies keinen Einfluss auf die darunterliegende Struktur.

7.2 Klassische Sicherheitskonzepte bei zentraler Datenspeicherung

277

Unter Microsoft Windows (XP, 2003 Server) ist jedem Betriebssystemobjekt (Dateien, Prozesse etc.) ein Sicherheit Descriptor zugeordnet, der eine ACL enthalten kann. Ist keine ACL vorhanden, so erhält jeder Benutzer Vollzugriff auf das Objekt. Ist die ACL vorhanden, aber leer, so erhält kein Benutzer Zugriff. Eine ACL besteht aus einem Header und maximal 1.820 Access Control Entries (ACE). Ein ACE enthält jeweils die Information,ob einem Benutzer oder einer Benutzergruppe eine bestimmte Zugriffsart erlaubt (allow) oder verweigert (deny) werden soll. Der Windows-Explorer schreibt die Einträge, die Zugriff verweigern, an den Anfang der ACL. Fordert nun ein Benutzer Zugriff auf ein Objekt an, so geht der Windows Object Manager die Liste von Anfang an durch. Sobald Einträge für alle angeforderten Rechte gefunden wurden, erlaubt oder verweigert der Object Manager entsprechend den Zugriff. Trifft der Object Manager beim Durchgehen der Liste auf einen Eintrag, der den Zugriff verweigert, wird die Suche abgebrochen und der Zugriff auf das Objekt verweigert. Bei Windows NT werden ACLs statisch vererbt, ab Windows 2000 geschieht dies dynamisch. Wird die ACL eines übergeordneten Verzeichnisses geändert, so hat dies Auswirkungen auf die darunterliegende Verzeichnisstruktur.

7.2.4

FC-Verkabelung

Einer der Nutzen einer FC-basierten SAN- oder NAS-Verkabelung ist, dass jeder I/O über Glasfaser erfolgt. Dies vermindert dramatisch die Wahrscheinlichkeiten des unberechtigten „Schnüffelns“.

7.2.5

Kontinuierliche Datensicherung

Durch den Einsatz von SANs ist es möglich, Daten kontinuierlich in Echtzeit auf mindestens zwei verschiedene Speichersysteme in unterschiedlichen Brandschutzabschnitten oder Standorten synchron oder asynchron zu spiegeln. Die Informationen werden durch entsprechende Softwarelösungen automatisch und nicht mehr zu fest vorgegebenen Zeiten vollständig oder teilweise gesichert. Ideal ist die synchrone Sicherung nach jeder Änderung in einer Datei in Form von einzelnen Ständen, d. h. einzelnen Snapshots. Das Risiko eines Datenverlustes durch die kontinuierliche Datensicherung,die Continous Data Protection (CDP),in Echtzeit wird deutlich verringert. Im Fall eines Angriffs durch Schadprogramme auf die IT-Systeme – wie einen Virus oder einen Trojaner – kann es trotz optimaler Sicherheitsvorkehrungen durchaus eine gewisse Zeit dauern, bis die Infizierung überhaupt registriert wird. Dank der kontinuierlichen Sicherung der Daten sowie deren Rücksicherung durch regelmäßige Snapshots ist es möglich, die zuletzt gespeicherte,„saubere“ Version der angegriffenen Datei wiederherzustellen. Die vorgestellten Methoden konzentrieren sich bisher fast ausschließlich auf die Grenze der vertrauenswürdigen Seiten des Speichernetzes, den Zugriff aus anderen Netzwerken und den Server, auf dem die Applikation gehostet ist. Wann auch immer eine neue Dienstleistung oder ein neuer User benötigt wird,so müssen diese bei der Sicherheitsbarriere freigeschaltet werden. Nur wenn sie richtig kon-

278

7 Sicherheit

figuriert wurden, genehmigt die Firewall und die definierten Zugriffsrechte jenen den Zugang, die ins geschützte Netz gelangen dürfen. Das Regelwerk einer Firewall ist jedoch sehr schnell sehr anspruchsvoll und bedarf einer kontinuierlichen Pflege, wie dies nur in wenigen Unternehmen der Fall ist. Zu Anfang wird meist noch der Grundsatz umgesetzt, dass alles, was nicht ausdrücklich erlaubt wird, verweigert wird. Jedoch wird meist schon nach kurzer Zeit von den Firewall-Administratoren auf Zuruf freigeschaltet und danach oftmals das Schließen beim Entfallen des Grundes vergessen. Bei der Isolierung des Speichers muss der Grundsatz lauten, wenn eine Verbindung der Speicherumgebung mit dem Internet ermöglicht wird, dann dürfen Daten nicht im Klartext verteilt werden. Daten sollten hier auch bei der Lagerung nur verschlüsselt aufbewahrt werden.

7.3

Klassische Sicherheitskonzepte in einer verteilten Speicherumgebung

Zentrale Datenspeicherinfrastrukturen, die nur über ein sicheres Netzwerk einen Zugriff erlauben, decken meist nicht die Anforderungen an einen modernen Informationsservice ab. Größere Speicherzugänglichkeit heißt, dass mehr Zugang auf die Daten existiert. Dies schließt LAN, Campus, MAN (Metropolitan Area Network – ein Datennetz mit mittlerer geografischer Ausdehnung; maximal mehrere 100 Kilometer), WAN und drahtlosen Zugang für NAS- und SAN-Netze ein. Mehr Zugangspunkte heißen auch, dass mehr Aufmerksamkeit in Form erhöhter Sicherheitsanforderungen gezahlt werden muss.

7.3.1

Ergänzende Maßnahmen

In Ergänzung zu den Sicherheitsinstrumenten einer zentralen Datenhaltung sind, bedingt durch die veränderte Bedrohungslage, weitere Maßnahmen notwendig. Ein wichtiges Instrument zum Aufbau einer sicheren Umgebung sind neben den bereits vorgestellten Zugangskontrollisten die Edge Switch Access Control List (ACL). Die ACL findet Anwendung im Rahmen der MPLS-Technologie (Multiprotocol Label Switching), die von Cisco Systems unter dem Namen „Tag Switching“ entwickelt wurde. Später wurde es durch die IETF als offener Standard definiert und in „Label Switching“ umbenannt. Der Zusatz „Multiprotocol“ beschreibt, dass MPLS unterhalb des IP-Layers angesiedelt ist und somit beliebige Protokolle darauf aufsetzen können. Insbesondere die weit reichenden Traffic Engineering-Fähigkeiten und Quality of Service (QoS) gehören zu den großen Vorteilen von MPLS. Als Einsatzgebiete eignen sich hierbei vor allem die großen Carrier-Backbone-Netze. Der eingehende Router eines MPLS-Tunnel wird Ingress Router genannt, der ausgehende Router hingegen Egress Router. Beide Router werden als Edge Label Switch Router (ELSR) bezeichnet, da sie die Grenze des MPLS-Netzwerkes darstellen. Router zwischen den ELSRs – also Router im Inneren des MPLS-Netzwerkes – werden als Label Switch Router (LSR) bezeichnet. Nach Eintreffen eines Paketes am Ingress Router wird das entsprechende Paket

7.3 Klassische Sicherheitskonzepte in einer verteilten Speicherumgebung

279

mit einem (oder mehreren) Label(s) versehen und anschließend an den nächsten Router des MPLS-Tunnels weitergeleitet. Wird ein mit einem Label versehenes Paket von einem LSR empfangen, wertet dieser das oberste Label aus. Nachdem der Austausch des Labels vorgenommen wurde, kann das Paket an den nächsten Router des Tunnels weitergeleitet werden. Zudem ist es möglich, ein weiteres Label hinzuzufügen, was auch „Encapsulation“ genannt wird und über eine PushOperation realisiert wird. Genauso kann auch ein Label durch eine Pop-Operation entfernt werden und ein darunterliegendes Label zum Vorschein bringen, was als „Decapsulation“ bezeichnet wird. Diese Vorgehensweise erlaubt ein hierarchisches Routing von MPLS-Paketen.Während der Operationen wird der Inhalt des Paketes außerhalb des MPLS-Label-Stack nicht beachtet.

7.3.2

Port Based Network Access Control

Seit 2001 gibt es den Standard 802.1x, der Port Based Network Access Control bei Netzwerken nachrüstet. Diese können drahtlos (WLANs) oder drahtgebunden sein. Die Authentifizierung der Benutzer erfolgt dabei über das Extensible Authentication Protocol (EAP). Zwischen Client und Basisstation werden über EAP die Authentifizierungsdaten ausgetauscht. Die Überprüfung der Daten erfolgt aber nicht durch die Basisstation, sondern durch einen Radius-Server im Hintergrund.

7.3.3

Mandatory Access Control

Zur Erhöhung des Sicherheitslevels insbesondere bei Speichernetzwerken wurde das Konzept der Mandatory Access Control (MAC) entwickelt.MAC ist ein Konzept für die Kontrolle und Durchsetzung von Zugriffsrechten auf IT-Systeme, bei der die Entscheidung über Zugriffsberechtigungen nicht aufgrund der Identität des Akteurs (Benutzers, Prozesses) und des Objektes (Datei, Gerät) gefällt wird, sondern aufgrund allgemeiner Regeln und Eigenschaften des Akteurs und Objektes. Auch erhalten häufig Programme eigene Rechte, die die Rechte des ausführenden Benutzers weiter einschränken. Voraussetzung ist, dass Akteure niemals direkt, sondern nur durch einen Referenzmonitor auf Objekte zugreifen können. Modelle der Mandatory Access Control sind vor allem dazu geeignet, die Vertraulichkeit und Konsistenz von Daten zu sichern. Sie dienen also dazu, den Informationsfluss zu kontrollieren, und so das „Abfließen“ geschützter Information zu verhindern, sowie zu gewährleisten, dass sich die Daten immer in einem konsistenten Zustand befinden.

7.3.4

Role Based Access Control

Role Based Access Control (RBAC) ist in Mehrbenutzersystemen oder Rechnernetzen ein Verfahren zur Zugangskontrolle auf Dateien oder Dienste. Bei der Role Based Access Control werden die Benutzer des Computers oder Netzwerks in Gruppen eingeteilt. Benutzer können dabei mehreren Gruppen angehören. Je nach Gruppenzugehörigkeit erteilt oder sperrt das System dann das Zugriffsrecht auf

280

7

Sicherheit

Ressourcen. Häufig werden vor allem Lesen, Schreiben und Ausführen von Dateien mittels RBAC kontrolliert, das Verfahren ist jedoch nicht darauf beschränkt. Eine Gruppe wird als „Role“ (Rolle) bezeichnet. Der Grund dafür ist, dass sich die Unterteilung der Benutzer danach richtet, in welcher Rolle, also in Ausübung welcher Aufgaben, sie auf den Computer zugreifen. Das englische Wort„Role“ wird im IT-bezogenen deutschen Sprachgebrauch unter anderem für Webmaster, Postmaster, Newsmaster, Netzwerkadministratoren, Systemadministratoren und ähnliche Funktionen verwendet und soll verdeutlichen,dass es sich nicht zwangsläufig um verschiedene Personen handelt, sondern dass zum Beispiel ein und dieselbe Person mal in der Rolle des Webmasters Webseiten aktualisiert, dann in der Rolle des Postmasters Beschwerden über sein offenes Mail-Relay liest und als Nächstes in der Rolle des Systemadministrators Software installiert. Wegen der zweistufigen Gliederung in Benutzer einerseits und „Rollen“ bzw. Gruppen andererseits ist es möglich, Zugriffsrechte nicht nur individuell für einzelne Benutzer, sondern auch für ganze Gruppen freizugeben oder zu sperren.

7.3.5

Management der Speicherinfrastruktur

Ein weiterer wichtiger Punkt in einem Sicherheitskonzept betrifft das Management der Speicherinfrastruktur. Leider ist ein ständiger Zugriff auf die heutigen Speichersysteme notwendig, sei es im Rahmen vorbeugender Wartung, sei es im Rahmen von Microcode-Changes,sei es bei der Einrichtung und/oder Erweiterung von Speicher. Die Managementschnittstelle stellt sich allein aufgrund der Anzahl von möglichen Zutrittspunkten, einschließlich der illegalen Konten, als ein hohes Sicherheitsrisiko dar.Aufgrund ihrer Fähigkeit, die Verbindung mit der Umgebung zu unterbrechen, Kopierdaten zu einem illegalen Empfänger zu transferieren und die Daten durch eine einzige Operation als Ganzes zu löschen, führt dies für sie zu einer hohen Bewertung der Kritikalität aus Sicht der Sicherheit. Die Managementzugangspunkte und die Personen, die sie benutzen dürfen, müssen deshalb besonders geschützt werden. In der Tat ist es insbesondere die Menge der Managementschnittstellen, die die Verwundbarkeit erhöht. Erst sie ermöglichen einen absichtlichen oder unabsichtlichen Zugang und eröffnen damit die Möglichkeit zur Änderung von Daten von innerhalb (vertrauenswürdig) oder außerhalb (nichtvertrauenswürdig). Die hier gemachten Änderungen können den Zugang zu Auskunft verhindern (eine Form von DoS oder die Ablehnung von Dienstleistungen), den Zugang eines Eindringlings verbergen oder sich Zugang auf Basis eines legalen Profils verschaffen, Daten verfälschen oder total verändern und abschließend die Anwesenheit des Besuchers durch Ausradierung in den Revisionsbaumstämmen löschen. Fehlende spezifische Sicherheitsvorgaben insbesondere beim Thema Speichermanagement haben z. B. dazu geführt, dass im Rahmen des beschriebenen Migrationsprojekts ein neues Teilprojekt gestartet wurde, das die Aufgabe hatte, insbesondere das Sicherheitsmanagement im Bereich Speicheradministration zu verbessern.

7.4 Security-Management-Planung im Bereich Speicheradministration

7.4

281

Security-Management-Planung im Bereich Speicheradministration

Auch bei ILM besteht die Notwendigkeit, dass die Unternehmen ihre Datenbestände in den Griff bekommen. Mit ILM steht bei Investitionen im Speicherbereich nicht mehr der Aufbau von Kapazität im Vordergrund, sondern ein besseres Management der gespeicherten Daten. An ein explosionsartiges Wachstum der klassisch zu speichernden Datenmengen glauben deshalb einer Studie der HitachiTochter Hitachi Data Systems (HDS) zufolge immer weniger IT-Verantwortliche. Die großen Anbieter setzen deshalb verstärkt auf Speichermanagement. Die Anbieter von Speicher zeigen so dem Kunden, wie sie effizienter mit dem Equipment arbeiten können, das sie bereits haben. Massive Infrastruktur-Investitionen zusammen mit steigenden Datenvolumen sind durch ILM nicht mehr nötig. Insbesondere beim Speichermanagement ist Sicherheit eine zentrale Komponente. Sicherheit beim Speichermanagement erfolgt gemäß der Beschreibung im Sicherheitsplan. Die Erklärung der verwendeten Abkürzungen befindet sich am Ende des Kapitels.

7.4.1

Maßnahmenkatalog Infrastruktur (M 1)

Maßnahme

xx

M 1.28; G; R M 1.29; U; G; T M 1.31; G

OK

M 1.46; M

7.4.2

TS

xx = Bemerkungen, TS = Standardisierungsstatus

OK

Lokale unterbrechungsfreie Stromversorgung

OK

Geeignete Aufstellung eines IT-Systems

OK

Fernanzeige von Störungen; xx: nur bei Speicher

OK

Einsatz von Diebstahl-Sicherungen

Maßnahmenkatalog Organisation (M 2)

Maßnahme

xx

TS

xx = Bemerkungen, TS = Standardisierungsstatus

Maßnahme

xx

TS

xx = Bemerkungen, TS = Standardisierungsstatus

M 2.1; O

OK

OK

Festlegung von Verantwortlichkeiten und Regelungen für den IT-Einsatz

M 2.2; O; M

OK

Betriebsmittelverwaltung

M 2.3; M; U; G

OK

Datenträgerverwaltung Regelungen für Wartungs- und Reparaturarbeiten

M 2.4; O; U; G

OK

OK

M 2.5; O

OK

OK

Aufgabenverteilung und Funktionstrennung

OK

Vergabe von Zutrittsberechtigungen

M 2.6; O M 2.7; O M 2.8; O M 2.9; V; T; U; W

OK

i.B.

Vergabe von Zugangsberechtigungen

i.B.

Vergabe von Zugriffsrechten; xx: im Rahmen der Abnahme Nutzungsverbot nicht freigegebener Software

282

7 Sicherheit

Maßnahme M 2.10; V; M; U; G; W

xx OK

TS OK

xx = Bemerkungen, TS = Standardisierungsstatus Überprüfung des Software-Bestandes

M 2.11; M

OK

OK

Regelung des Passwortgebrauchs

M 2.12; M

OK

OK

Betreuung und Beratung von IT-Benutzern

OK

Ordnungsgemäße Entsorgung von schützenswerten Betriebsmitteln

M 2.13; O; U; G M 2.14; O

OK

Schlüsselverwaltung

M 2.22; U; G; B

i.B.

i.B.

Hinterlegen des Passwortes

M 2.25; U; G;T; I; B

OK

OK.

Dokumentation der Systemkonfiguration

M 2.26; U; G

i.B.

Ernennung eines Administrators und eines Vertreters

M 2.30; M; U; G

i.B.

Regelung für die Einrichtung von Benutzern / Benutzergruppen

M 2.31; U; G; B

i.B.

Dokumentation der zugelassenen Benutzer und Rechteprofile

M 2.32; U; G

i.B.

Einrichtung einer eingeschränkten Benutzerumgebung

M 2.34; U; G; B

OK

OK

Dokumentation der Veränderungen an einem bestehenden System

M 2.35; V; K; U; G; W

i.B.

i.B.

Informationsbeschaffung über Sicherheitslücken des Systems

M 2.38; G

i.B.

Aufteilung der Administrationstätigkeiten

M 2.39; O; K

OK

Reaktion auf Verletzungen der Sicherheitspolitik

OK

Verpflichtung der Mitarbeiter zur Datensicherung

M 2.41; D

OK

M 2.46; K

OK

Geeignetes Schlüsselmanagement

OK

Software-Abnahme- und Freigabe-Verfahren; xx: aktuell nur für . . .

M 2.62; M

OK

M 2.64; M

OK

M 2.82; W

OK

OK

Entwicklung eines Testplans für Standardsoftware; xx: aktuell nur für . . .

i.B.

Testen von Standardsoftware

M 2.85; W

OK

OK

Freigabe von Standardsoftware

M 2.86; W

OK

OK

Sicherstellen der Integrität von Standardsoftware

M 2.87; W

i.B.

i.B.

Installation und Konfiguration von Standardsoftware

M 2.88; W

OK

OK

Lizenzverwaltung und Versionskontrolle von Standardsoftware

i.B.

Deinstallation von Standardsoftware Überprüfung der Lieferung

M 2.83; W

M 2.89; W

Kontrolle der Protokolldateien; xx: Voraussetzung in ECC gegeben; aktuell keine Umsetzung

M 2.90; W

OK

OK

M 2.110; M

OK

OK

Datenschutzaspekte bei der Protokollierung

M 2.111; M; B

OK

OK

Bereithalten von Handbüchern

M 2.125; B

OK

OK

Installation und Konfiguration einer Datenbank

7.4 Security-Management-Planung im Bereich Speicheradministration

283

Maßnahme M 2.126; B

xx OK

TS OK

xx = Bemerkungen, TS = Standardisierungsstatus Erstellung eines Datenbanksicherheitskonzeptes; xx: macht . . . automatisch

M 2.127; B

OK

OK

Interverenzprävention; xx: macht . . . automatisch

M 2.128; B

OK

Zugangskontrolle einer Datenbank

M 2.129; B

i.B.

OK

Zugriffskontrolle einer Datenbank; xx: . . . hat keine userbezogene Accounts

M 2.130; B

OK

OK

Gewährleistung der Datenbankintegrität; xx: macht . . . automatisch

M 2.131; B

OK

Aufteilung von Administrationstätigkeiten bei Datenbanksystemen

M 2.132; B

OK

Regelung für die Einrichtung von Datenbankbenutzern/benutzergruppen

M 2.133; B

OK

Kontrolle der Protokolldateien eines Datenbanksystems

M 2.134; B

OK

Richtlinien für Datenbank-Anfragen

M 2.135; B

OK

Gesicherte Datenübernahme in eine Datenbank

M 2.137; D

OK

Beschaffung eines geeigneten Datensicherungssystems

M 2.138; M; G

OK

Strukturierte Datenhaltung

M 2.143; T

i.B.

Entwicklung eines Netzmanagementkonzeptes

M 2.144; T

i.B.

Geeignete Auswahl eines Netzmanagement-Protokolls

M 2.154; V

i.B.

Erstellung eines Computer-Virenschutzkonzepts

M 2.155; V

i.B.

Identifikation potentiell von Computer-Viren betroffener IT-Systeme

M 2.156; V

i.B.

Auswahl einer geeigneten Computer-VirenschutzStrategie

M 2.157; V

i.B.

Auswahl eines geeigneten Computer-VirenSuchprogramms

M 2.158; V

i.B.

Meldung von Computer-Virusinfektionen

M 2.159; V

i.B.

Aktualisierung der eingesetzten Computer-VirenSuchprogramme

M 2.160; V

i.B.

Regelungen zum Computer-Virenschutz

M 2.167; M

OK

OK

Sicheres Löschen von Datenträgern

M 2.177; O

OK

OK

Sicherheit bei Umzügen

M 2.182; M

OK

OK

Regelmäßige Kontrollen der IT-Sicherheitsmaßnahmen

i.B.

Verhinderung ungesicherter Netzzugänge

M 2.204; M; G M 2.215; M

OK

OK

Fehlerbehandlung

M 2.216; M

OK

OK

Genehmigungsverfahren für IT-Komponenten

M 2.220; M

OK

OK

Richtlinien für die Zugriffs- bzw. Zugangskontrolle

M 2.221; M

OK

OK

Änderungsmanagement

M 2.222; M

OK

OK

Regelmäßige Kontrollen der technischen IT-Sicherheitsmaßnahmen

i.B.

Zuweisung der Verantwortung für Informationen, Anwendungen und IT-Komponenten

M 2.225; O

284

7 Sicherheit

Maßnahme M 2.226; M

xx OK

TS OK

xx = Bemerkungen, TS = Standardisierungsstatus Regelungen für den Einsatz von Fremdpersonal

M 2.227; I

OK

OK

Planung des Windows 2000 Einsatzes

M 2.228; I

OK

OK

Festlegen einer Windows 2000 Sicherheitsrichtlinie

M 2.229; I

i.B.

Planung des Active Directory

M 2.230; I

i.B.

Planung der Active Directory-Administration

M 2.231; I

i.B.

Planung der Gruppenrichtlinien unter Windows 2000

M 2.232; I

i.B.

Planung der Windows 2000 CA-Struktur

M 2.233; I

i.B.

Planung der Migration von Windows NT auf Windows 2000

Weitere Maßnahmen sind entsprechend den folgenden Katalogen zu erstellen (dies ist dringend erforderlich, würde jedoch in dieser Darstellung den Umfang des Buches sprengen; ca. 150 Einzelmaßnahmen sind zu definieren und ihre Umsetzung zu veranlassen). • • • •

Maßnahmenkatalog Personal (M 3) Maßnahmenkatalog Hard- und Software (M 4) Maßnahmenkatalog Kommunikation (M 5) Maßnahmenkatalog Notfallvorsorge (M 6)

Abkürzungserklärung: Abkürzung OK: Arbeitspunkt ist bis zum nächsten Audit erledigt O = Kapitel 3.1 P = Kapitel 3.2 N = Kapitel 3.3 D = Kapitel 3.4 V = Kapitel 3.6 K = Kapitel 3.7 S = Kapitel 3.8 M = Kapitel 3.9 U = Kapitel 5.2 G = Kapitel 6.1 R = Kapitel 6.2 T = Kapitel 6.3 I = Kapitel 6.9 W = Kapitel 9.1 B = Kapitel 9.2

Erklärung i.B.: Arbeitspunkt ist aktuell in der Bearbeitung, Organisation Personal Notfallvorsorge-Konzept Datensicherungskonzept Computer-Virenschutzkonzept Kryptokonzept Behandlung von Sicherheitsvorfällen Hard- und Software-Management (USy) Unix-System (SN) Servergestützte Netzwerke (USe) Unix Server (NSM) Netz- und Systemmanagement (WS) Windows Server 2000 (SW) Standardsoftware (DB) Datenbanken.

7.5 SAN-Zoning und LUN-Masking

7.5

285

SAN-Zoning und LUN-Masking

Eine zusätzliche Verbesserung der Sicherheit durch SAN-Zoning und LUN-Masking ist möglich. SANs werden mit Hilfe von Fibre-Channel-Switches aufgebaut, die als intelligente Schalteinheiten Server und Speicher miteinander verbinden. Angelehnt an die virtuellen LANs (VLANs) im LAN-Switch findet sich im FibreChannel-Switch eine ähnliche Funktionalität, genannt Zoning. Zoning definiert voneinander abgegrenzte Teilnehmergruppen, die aufgrund von physikalischen Portnummern (Hard-Zoning) oder aufgrund der Adressinformationen im Datenfeld (Soft-Zoning) gebildet werden. Im Kern geht es beim SANZoning und LUN-Masking darum, der Applikation nur die Speicherbereiche sichtbar zu machen, die sie für die Durchführung ihrer Aufgaben braucht, und damit durch Segmentierung den allgemeinen Zugriff auf spezifische Speicherbereiche zu unterbinden. SAN-Zoning beschreibt die Unterteilung eines Netzes in virtuelle Subnetzwerke, die sich überlappen können. Server einer Zone können normalerweise nicht auf Speichersysteme einer anderen Zone zugreifen – eine wichtige Sicherheitsmaßnahme gegen Attacken. Es gibt zwei Methoden des Zonings in einer FabricUmgebung, d. h. einem Speichernetzwerk: Diese sind Port-Zoning und WWNZoning. Port-Zoning nutzt Zonen auf Basis physikalischer Ports und ist daher sehr sicher.Dies bedeutet,dass der Zugriff auf die einzelnen Speichersegmente einem fest definierten Port zugeordnet wird. Die Applikation hat nur Zugriff auf dezidierte Ports und kann demzufolge nur auf die definierten Speicherbereiche zugreifen. Beim WWN-Zoning (WWN – World Wide Name) wird der Name des Servers im Switch dazu genutzt, den Zugriff zu einzelnen WWNs in der Fabric zu erlauben oder zu blockieren. Ein WWN ist eine 64-Bit-Kennung für eine Fibre-ChannelKomponente, die weltweit eindeutig ist.WWN-Zoning ist aufgrund seiner deutlich höheren Flexibilität sehr verbreitet, obwohl WWN-Zoning einen deutlich geringeren Sicherheit-Level darstellt.Insbesondere eröffnet das WWN-Zoning den Zugriff in Form eines Bypasses,falls einem Hacker die IEEE-Adresse des Adapters bekannt ist. Es erlaubt ihm den Access direkt zum Knoten und damit zu den Daten. Das SCSI-Protokoll und dessen Ableger wie Fibre Channel Protocol (FCP) und iSCSI adressieren Teilkomponenten eines Gerätes (Target) mittels der Logical Unit Number (LUN). Es hat sich eingebürgert, auch diese Teilkomponenten als LUN zu bezeichnen. LUNs sind von einem Disksubsystem exportierte physikalische oder virtuelle Festplatten sowie die Bandlaufwerke und der Roboter einer Tape-Library. LUN-Zoning ist die alternative Bezeichnung für LUN-Masking und bedeutet das Zoning im SCSI-Protokoll. Unterstützt wird das LUN-Masking oftmals noch durch die LUN-Sicherheit der Disk-Arrays. Eine LUN ist eine logische Platteneinheit in einem intelligenten Disk-Array. Unter LUN-Sicherheit fallen die Begriffe LUNBinding und LUN-Masking.Das LUN-Masking wird verwendet,um das Zoning auf Basis von LUNs durchzuführen. LUN-Masking schränkt die Sichtbarkeit von Festplatten ein und ist primär im HBA (Host-Bus-Adapter) implementiert. Sie sollen damit verhindern, dass unberechtigte Teilnehmer im SAN Zugriff auf die LUNs

286

7 Sicherheit

erhalten. LUN-Binding erlaubt die Adressierung der LUNs nur über bestimmte Netzeingänge des Plattensystems. LUN-Masking definiert darüber hinaus noch Zugriffstabellen, in denen die WWN-Adressen der zugriffsberechtigten Server hinterlegt sind. Jeder Server sieht somit nur die Festplatten, die ihm zugewiesen sind. LUN-Masking wird als Filter zwischen den vom Disksubsystem exportierten Festplatten und den zugreifenden Servern etabliert. Auch einige Speicher Controller unterstützen LUN-Masking. Es gibt unterschiedliche Methoden von „LUNMasking“, um den Zugriff (schreibend und/oder lesend) auf einzelne LUNs in einem Array zu blockieren. Einige Methoden benutzen „Agenten“ auf den Servern, um den Zugang zu besonderen LUNs zu sperren. Wenn ein solcher Agent nicht eingesetzt wird oder missbräuchlicherweise etabliert wird, existiert mit hoher Wahrscheinlichkeit ein ungesicherter LUN-Zugang von jenem Knoten. Aus Sicherheitsgründen sollte besser Firmware verwendet werden, um den Zugang zu besonderen LUNs durch die Benutzung des WWN zu ermöglichen bzw. bei Nichterfüllung zu verhindern. Das Arrary speichert die Zugangsliste für den HostAccess in NV-RAM und im Memory. LUN-Masking ist insbesondere beim Einsatz von Windows-Server wichtig, da hier ein uneingeschränkter Zugriff zu allen sichtbaren LUNs erfolgen kann. So wichtig die beschriebenen allgemeinen Sicherheitsmaßnahmen und insbesondere die spezifischen Sicherheitsmaßnahmen im SAN mit Zoning und Masking für eine funktionierende SAN-Infrastruktur auch sind, sie erhöhen aber die Komplexität des Speichermanagements. Insbesondere bei der dynamischen Speicherprovisionierung (Storage-on-Demand) im SAN. Liegen z. B. freie Plattenkapazitäten eines Speicherpools in einer anderen Zone, so muss zuerst der FC-Switch umkonfiguriert werden. Weiterhin sind die LUN-Zugriffstabellen anzupassen, sonst kann ein Server die neuen Speicherbereiche nicht nutzen. Sämtliche Verwaltungsfunktionen im SAN dürfen nur von unbedingt vertrauenswürdigen Instanzen durchgeführt werden. Entsprechend hoch ist der Aufwand bei der Sicherung der zahlreichen Zugangspunkte für das Management der Speicher- und Netzkomponenten. Zudem zeigt die tägliche Praxis, dass häufig die Administratoren nicht das spezifische Know-how und die notwendige Routine haben, die Aktivitäten in der richtigen Reihenfolge und ohne Fehler durchzuführen. Ist der Managementzugang zudem nur unzureichend abgesichert, so hat man potenziellen Angreifern von innen und außen Tür und Tor geöffnet.

7.6

Anforderung an die Organisation und die Betriebsführung

Die Analyse von SNIA zeigt, dass ein funktionierendes Sicherheitskonzept zu mindestens 80 Prozent auf einer durchgängigen Organisation und einer konsequenten Betriebsführung beruht. Die eigentliche Sicherheitstechnologie macht demzufolge nur 20 Prozent des Sicherheitskonzeptes aus.82 82

SNIA-Sicherheit, www.snia.org.

7.6 Anforderung an die Organisation und die Betriebsführung

287

Die beschriebenen Einzelmaßnahmen bei den traditionellen Sicherheitskonzepten bei der zentralen und insbesondere bei der dezentralen Datenspeicherung lösen somit nicht die spezifischen Sicherheitsanforderungen im Generellen und von ILM im Besonderen. Vor allem ein unternehmensweites ILM erfordert ein Sicherheitskonzept, das aufsetzend auf den generellen Sicherheitsanforderungen die effizienten Einzelmaßnahmen zu einem wirkungsvollen Gesamtschutz verschweißt.

7.6.1

Das Sicherheitsmanagement

Der ISMS-Standard ISO/IEC 27001:2005 wurde am 15. Oktober 2005 von ISO veröffentlicht! Er basiert auf BS 7799-2:2002 und wurde in ISO/IEC JTC1 SC 27 (dies ist das Komitee, das auch für ISO/IEC 17799 verantwortlich ist) entwickelt. Dieser ISMS-Standard beschreibt die Anforderungen an ein ISMS (Information Security Management System) und ist, genau wie ISO 9001, ein Managementsystemstandard, nach dem auch zertifiziert werden kann. Zusätzlich zu der Entwicklung von ISO/IEC 27001 arbeitet ISO/IEC JTC1 SC 27 an weiteren Standards, die alle in der 27000-Serie zusammengefasst werden – in Analogie zu anderen Managementsystemen, wie zum Beispiel ISO 9000. Die Standards in 27000 ISO sind: • ISO/IEC 27000: Information security management system fundamentals and vocabulary (in Entwicklung) • ISO/IEC 27001: Information security management system – Requirements (veröffentlicht) • ISO/IEC 27003: Information security management system implementation guidance (in Entwicklung) • ISO/IEC 27004: Information security management measurement (in Entwicklung) • ISO/IEC 27005: Information security risk management (in Entwicklung) Andere Standards in der 27000-Serie werden auf dem nächsten SC-27-Meeting diskutiert werden. Über die Aufnahme von ISO/IEC 17799:2005 in diese 27000-Serie wird im Frühjahr 2007 entschieden werden; ein Vorwort in ISO/IEC 17799:2005 weist darauf hin, und wenn ISO/IEC 17799:2005 in die 27000-Serie integriert wird, wird der Standard die Nummer ISO/IEC 27002 erhalten. ISO/IEC 27001:2005 spezifiziert die Anforderungen an ein ISMS (Information Sicherheit Management System). ISO/IEC 27001 basiert auf BS 7799-2:2002 und ist mit anderen Managementstandards, namentlich ISO 9001:2000 und ISO 14001:2004, harmonisiert. Dadurch ist es möglich, konsistente und integrierte Managementsysteme zu implementieren. ISO/IEC 27001 beinhaltet außerdem das Plan-Do-Check-Act (PDCA) Model als Teil des Managementsystemansatzes zur Entwicklung, Umsetzung und kontinuierlichen Verbesserung des ISMS. Die Umsetzung des PDCA-Modells spiegelt auch die Prinzipien wider, die in den OECD-Guidelines (OECD Guidelines for the Security of Information Systems and Networks, 2002) zur Regelung der Sicherheit von Informationssystemen und

288

7 Sicherheit

Netzwerken beschrieben sind. Insbesondere liefert der Standard ISO/IEC 27001 ein robustes Modell zur Implementierung der Prinzipien dieser Richtlinien, die sowohl die Risikoanalyse, das Design und die Implementierung von Sicherheit, als auch das Sicherheitsmanagement und dessen Überprüfung beschreiben.

7.6.2

Management des kontinuierlichen Geschäftsbetriebs

Es sind korrigierende und vorbeugende Maßnahmen gegen Unterbrechungen von Geschäftsaktivitäten und Schutz der kritischen Geschäftsprozesse vor den Auswirkungen großer Ausfälle oder Katastrophen zu treffen. • Einhaltung der Verpflichtungen: Im letzten Steuerbereich von ISO 17799 wird die Vermeidung von Verletzungen von Gesetzen des Straf- oder Zivilrechts, gesetzlicher, behördlicher oder vertraglicher Verpflichtungen und jeglicher Sicherheitsanforderungen angesprochen. Weiter ist die Erfüllung organisationseigener Sicherheitspolitiken und Normen durch Systeme sicherzustellen. Audits des ISMS sind zu planen und zu vereinbaren, um das Risiko von Störungen der Geschäftsprozesse zu minimieren. • Der Aufbau des Managementrahmens: Mit der Übernahme des British Standard BS 7799 in die ISO 17799 wurde nur der erste Teil des BS 7799 „Leitfaden zum Management von Informationssicherheit“ auf die internationale Ebene gehoben. BS 7799 besitzt dagegen einen zweiten Teil „Spezifikation für Informationssicherheitsmanagementsysteme“, der einige ergänzende Informationen enthält. Die bedeutendste ist sicherlich der Abschnitt zur Schaffung des Managementrahmens. Grundsätzlich ist dabei anzumerken, dass dieser Managementrahmen nichts anderes ist als das Risikomanagementsystem, das jede Organisation besitzen sollte, um dem Phänomen der Unsicherheit zu begegnen. In Bezug auf das Management von Informationssicherheit werden im BS 7799, Teil 2, sechs Stufen angeführt. 7.6.2.1 Definition der Sicherheitspolitik Wie jedes Managementsystem benötigt auch der Managementrahmen des ISMS eine Sicherheitspolitik, um Ziele, Zwecksetzungen,Absichten und Hauptverantwortlichkeiten zu definieren. 7.6.2.2 Definition des Umfangs des ISMS Hier sind die Grenzen hinsichtlich der Merkmale der Organisation,ihres Standorts, ihrer Werte und ihrer Technologie festzulegen. 7.6.2.3 Risikoidentifikation und -analyse In diesem Schritt werden die Bedrohungen der Werte, die Schwachstellen und Auswirkungen auf die Organisation identifiziert und das Ausmaß des Risikos bestimmt (typischerweise als Wahrscheinlichkeit des Eintritts und Auswirkung im Fall des Eintritts).

7.6 Anforderung an die Organisation und die Betriebsführung

289

7.6.2.4 Risikomanagement Basierend auf dem notwendigen Bedarf an Sicherheit sind die Risikobereiche zu identifizieren. 7.6.2.5 Auswahl von Steuerungszielen und -maßnahmen Für die im Risikomanagement identifizierten Risikobereiche sind geeignete Zielvorgaben zu machen und entsprechende Maßnahmen zu treffen. 7.6.2.6 Erklärung der Anwendbarkeit Die ausgewählten Sicherheitsziele und Maßnahmen sowie die Gründe für ihre Auswahl sind in der Erklärung zur Anwendbarkeit zu dokumentieren.

7.6.3

Anforderungen an die Organisation und die Standards

Die Aufnahme des Aspektes Sicherheit in die Unternehmensorganisation sollte eine strategische Entscheidung sein. Das Design und die Implementierung von Sicherheit innerhalb der Organisation werden durch geschäftliche Anforderungen und Ziele bestimmt. Ebenso resultieren daraus Sicherheitsanforderungen, die eingesetzten Prozesse und die Struktur der Organisation. Es ist zu erwarten, dass sich diese sowie deren unterstützende Systeme im Verlauf der Zeit verändern. Einfache Situationen erfordern einfache Sicherheitslösungen. Die Komplexität des Unternehmens soll auch bei der Sicherheit gespiegelt werden. Die Sicherheitskultur muss sowohl als Attribut der Unternehmenskultur wie auch als Attribut des Sicherheitsmanagements angesehen werden und wird von letzterem angetrieben. ISO 17799 und ISO 27000 machen eindringlich deutlich, dass es ohne ein systematisches Management der Informationen keinen wirksamen Schutz gibt. Mit der ISO 17799 und ISO 27000 gibt es internationale Standards, die als Basis für eine „Best Practice“ dienen können und global kommunizierbar sind. Die Zertifizierung nach BS 7799, Teil 2 und ISO 27000 wird insbesondere Organisationen helfen, die Kunden und anderen Stakeholdern darlegen möchten, dass Vertraulichkeit, Integrität und Verfügbarkeit von Informationen stets gewährleistet sind. Der Vorteil des internationalen Standards wird jedoch durch die fehlenden Festlegungen im operativen Maßnahmenbereich mehr als kompensiert. Für den Betrieb einer IT-Infrastruktur fehlen vollständig die operativen Sicherheitsmaßnahmen für die aktuellen Betriebssysteme, das komplette Systemmanagement, der gesamte Bereich des Speichermanagements sowie die gesamte Speicherinfrastruktur mit SAN und NAS einschließlich der dort eingesetzten Switches. Im Schwerpunkt der folgenden Ausarbeitungen zu spezifischen Sicherheitsmaßnahmen stehen die Aktivitäten der Planung und der Betriebsführung, die für die Sicherheit eine herausragende Bedeutung haben!

290

7.7

7 Sicherheit

Allgemeine Sicherheitsanforderungen an eine verteilte Infrastruktur

Backup, Archivierung und Speichernetz sind so unsicher wie jedes andere ungeschützte System. Dieser Satz muss nach den Erfahrungen der vergangenen Jahre jedem IT-Leiter Angst einjagen, wenn man bedenkt, dass jedes Unternehmen zur Existenz notwendige Informationen auf Datenträgern abgelegt hat, die sehr einfach eingesehen und gestohlen werden können. Nicht nur, dass Disaster Recovery und Datenklau keine extremen Herausforderungen darstellen,jetzt drohen weitere Gefahren durch Viren und Würmer. Dies gilt insbesondere für Speichernetzwerke wie SAN und NAS, die in Form von Campus-, MAN- (MAN – Metropolitan Area Network) und WAN- (WAN – Wide Area Network)Netzwerken betrieben werden. Es ist zu vermuten, dass das Speichernetz die gleiche Lernphase wie das klassische Unternehmensnetz durchläuft mit DoS-Attacken (Denial of Service) und Einbrüchen ins Firmennetz.

7.8

Backup als Bestandteil einer Sicherheitsstrategie

Traditionelle Datenspeicherungs- und Backup-Lösungen machen keinen Unterschied zwischen Datentypen. Sie repräsentieren eine Art Einheitslösung, die Speicherung, Replizierung, Backup und Datenlöschung exakt gleich behandelt. Der erste Schritt ist die Klassifizierung der Daten nach ihrem Typ und die Zuordnung dieser Klassifizierungen auf die korrespondierenden primären und sekundären (Backup)-Speicherklassen in Abstimmung mit den geschäftlichen Anforderungen. Es wird dabei unterschieden, ob es sich um die dauerhafte Aufbewahrung von Compliance-Daten handelt, um ökonomischen Online-Zugriff auf Speicher oder um das Löschen von Daten. Noch wichtiger ist die kontinuierliche Neubewertung der Daten,da ihr Wert in Abhängigkeit von den jeweiligen Geschäftsanforderungen im Lauf der Zeit schwankt. Um die Daten möglichst automatisiert dem passenden Speicher zuordnen zu können, muss einerseits eine Datenklassifizierung gemäß Typ, Besitzer, Größe, Zeitpunkt der letzten Änderung und Compliance-Bedarf erfolgen. Die Aufgabe des Backups auch im Rahmen eines ILM-Konzeptes ist der Schutz der Informationen. Hierzu werden definierte Datenbereiche, die so genannten Informationsobjekte, aufgrund der definierten geschäftspolitischen Policies gesichert und im Mittelfristzeitraum gemäß SLA bereitgestellt.Technologische Basis für eine ILM-konforme Backup-Umgebung ist daher eine vernetzte, mehrstufige Speicherlandschaft,die je nach Bedarf Konzepte wie Storage Area Networks (SANs), Network Attached Speicher (NAS) oder Content Addressed Storage (CAS) einschließt. Auch Bereiche wie ECM (Enterprise Content Management) und HSM (Hierarchical Storage Management) können Bestandteile eines ILM-Konzepts sein. In der Praxis muss eine ILM-Lösung vier Kriterien erfüllen: • Die intelligente Klassifizierung der Daten. • Die intelligente Zuordnung der jeweiligen Datenklasse auf die passende Speicherklasse.

7.8 Backup als Bestandteil einer Sicherheitsstrategie

291

• Der notwendige Schutz der jeweiligen Datenklasse in Form einer auf die Speicherklasse passenden Backup-Policy. • Eine offene Architektur, die ILM-Elemente aus Enterprise-Content-Management, Data-Movement und primärem/sekundärem Speicher kombinieren kann. Eine entsprechende primäre und sekundäre Speicherplattform sollte einen offenen Ansatz pflegen und die verschiedenen Speicherklassen konsolidieren. Sie sollte einen sicheren Zugriff bieten und Backup-, Restore- und Disaster-RecoveryAnforderungen beachten. Damit haben Unternehmen die freie Wahl der Komponenten, die ihre Anforderungen am besten abdecken. Wie bereits beschrieben, gibt es viele Sicherheitsaspekte, die im Umfeld von ILM zu beachten sind. Daher sollte Teil eines ILM-Konzepts immer auch eine Betrachtung nach Sicherheitsaspekten und Sicherheitsstandards sein. Die Verwaltung von Speicher und Backup ist eine komplexe Materie, die sich jedoch mit der richtigen Information-LifecycleManagement-Strategie vereinfachen lässt. Die jeweils optimale Balance zwischen Speicherressourcen und Sicherung der Daten setzt die individuelle Definition von Daten-, Speicher- und Backup-Klassen voraus, in die Faktoren wie Kosten, Produktivität, Geschäftsziele, Regulierungen, Sicherheit oder Performance einfließen sollten (siehe Klassifizierungsmodelle). Darauf aufbauend folgt die automatische Klassifizierung bestehender und neuer Daten, deren Ergebnis über weitere Schritte wie etwa Sichern, Verschieben oder Löschen entscheidet und die regelbasiert kontinuierlich wiederholt wird.Auf diese Weise erhalten die Daten während ihres gesamten Lebenszyklus das richtige Maß an Schutz und Verfügbarkeit. Ihr Nutzwert für das Unternehmen steigt, und die damit verbundenen Speicherkosten sinken, da Ressourcen besser ausgelastet und zielgerichtet eingesetzt werden können. Für die Umsetzung einer ILM-Strategie müssen für jeden der drei Bereiche • Speicherressourcenmanagement, • Compliance/Datensicherheit und • Migration die optimalen Lösungen ausgewählt werden.Die Kompatibilität der einzelnen Bausteine kann nicht groß genug eingestuft werden.

7.8.1

SLA als Kernforderung für den Backup- und Wiederherstellprozess

Nur das SLA (Service Level Agreement) definiert die spezifischen Anforderungen an das Backup im Allgemeinen, an die Backup-Klassen im Spezifischen und den darauf aufbauenden Wiederherstellungsprozess im Bedarfsfall.Applikationen werden im Allgemeinen in solche mit wahlfreien oder sequenziellen Zugriffsmustern unterschieden. Randomisierter Datenzugriff wird in I/O pro Sekunde (IOPS) beschrieben bzw. gemessen und findet sich vor allem bei Applikationen wie OLTP (Online Transaction Processing) und DS (Decision Support). Sequenzieller Daten-

292

7 Sicherheit

zugriff wird in MByte/s gemessen und ist bei bandbreitenintensiven Applikationen wie Media-Streaming und der Verarbeitung seismischer Daten zu finden. Diese beiden Profile unterscheiden sich erheblich in ihren Anforderungen an das Speichersystem. Während Controller und Firmware eine sehr wichtige Rolle spielen, sollte die Bedeutung des Laufwerks nicht unterschätzt werden.

7.8.2 Wiederherstellungsprozess Bei der obigen Umfrage zum Thema der Wiederherstellung verlorener Daten gingen die Meinungen auseinander: 47 Prozent der deutschen IT-Experten würden zwei Stunden als Limit für die Wiederherstellung ihrer Daten akzeptieren, 43 Prozent geben sich sogar mit einem Tag Wiederherstellzeit zufrieden. 10 Prozent hätten ihre Daten gerne binnen fünf Minuten wieder zurück – ebenso wie je 4 Prozent der Schweizer und Österreicher. Über die Dauer der Rücksicherung entscheidet auch die Art des Datenspeichers. Sicherheitskopien von Daten auf Festplatten werden traditionell auf Magnetbandkassetten gespeichert. Die Umfrage ergab, dass sich 22 Prozent der deutschen Teilnehmer nicht mehr ausschließlich auf die klassische Bandsicherung verlassen und zusätzlich auch Festplatten für das DatenBackup nutzen. Beim Einsatz der Festplatte als Backup-Medium bilden deutsche Firmen hier übrigens das Schlusslicht: Während bei den Österreichern 37 Prozent beide Speichermedien nutzen, sind es bei den Schweizern bereits 60 Prozent.„Die Einschätzung des Grads an Datensicherheit entspricht keineswegs dem heutigen Stand der Speichertechnik“, so Manfred Reitner, Area Vice President Germany bei Network Appliance. „Das ist wie bei einer gefühlten Temperatur, die selten mit der Anzeige des Thermometers übereinstimmt.Als Hersteller von Datenspeichern wissen wir sehr gut, was technisch machbar ist. Das Wiederherstellen einer fast beliebigen Menge Daten ist heute eine Sache von Sekunden und eine mehrstufige Backup-Strategie aus Festplatte und Band sichert gegen Datenverlust ab. Manch ein Datensicherheitskonzept kann mit Sicherheit noch verbessert werden.“83 Auch diese Ergebnisse sind erschreckend, da erst garantierte Wiederherstellzeit, hohe Netzverfügbarkeit und QoS-Parameter (Quality of Service) auf Basis individueller Vereinbarungen (SLAs) mit dem Kunden hohe Effektivität und Wirtschaftlichkeit der Geschäftsabläufe sichern.Nur eine Datenklassifizierung im Rahmen von ILM schafft die Voraussetzung, zeitkritische Anwendungen z. B. aus einem Trader-Bereich, Sprach- oder Videodaten gegenüber zeittoleranten Daten wie E-Mail-Anwendungen bevorzugt bei Verlust der Daten wiederherzustellen. Eine zügige Wiederherstellung gelingt jedoch nur dann zuverlässig, wenn u. a. folgende Bedingungen erfüllt sind: • Das Wiederherstellen des Systems muss ohne weitreichende Kenntnisse über die Interna dieses Systems durchführbar sein. • Die Wiederherstellung sollte nicht zu stark von einer bestimmten Hardwarekonfiguration abhängen. 83

Network Appliance, www.drchip.de/html/bis 12 september 2006.html.

7.8 Backup als Bestandteil einer Sicherheitsstrategie

293

• Das Recovery sollte ohne Benutzerinteraktion – und somit mit weniger Fehlermöglichkeiten – ablaufen. Jeder Datenverlust bedeutet, dass ein IT-Service nicht in der notwendigen Qualität bereitgestellt werden kann. Dem Online-Datenschutz kommt daher eine Schlüsselfunktion zu, die überwacht werden muss, um einen unterbrechungsfreien Betrieb sicherzustellen. Er ist besonders wichtig, um den Geschäftsbetrieb in dem Zeitraum aufrechtzuerhalten, der für die Wiederherstellung nach einem Datenverlust benötigt wird. Dies ist annähernd ebenso wichtig wie die Band-Backups selbst. Gemäß der hohen Bedeutung der Datenverfügbarkeit im Rahmen einer ILM-Strategie muss für jede der definierten Backup-Klassen eine eigene Strategie entwickelt werden, die sich aus der Kombination der Medien Festplatte und Band zusammensetzt.

7.8.3

Backup Medium Festplatte

SATA- und FC-Laufwerke weisen vollkommen unterschiedliche Leistungsprofile auf. FC-Platten wurden für höchste IOPS und MByte/s-Leistungsraten entwickelt. Sie integrieren moderne Technologien, um Rotationsgeschwindigkeiten und Datenübertragungsraten zu maximieren und zeitgleich Suchzeiten sowie Latenz zu mindern. Darüber hinaus ist die FC-Schnittstelle robust genug, parallel und bidirektional viele I/O-Operationen unterschiedlichster Größe abzuarbeiten. Der langsamere Laufwerksmechanismus von SATA und eine limitierte Schnittstellenfunktionalität führen zu einer geringeren IOPS und Datentransferrate imVergleich zu FC. Während diese Einschränkungen SATA für die meisten leistungsorientierten, transaktionsbasierten (IOPS) Applikationen ausschließen, spielen diese in bandbreiteorientierten Anwendungen eine weitaus geringere Rolle – hier ist SATA in vielen Fällen die richtige Wahl. Ein letztes Kriterium ist die Zugriffshäufigkeit. Auf den ersten Blick erscheinen Implementationen von Sekundärspeichern, die randomisierten Datenzugriff generieren, nicht SATA-geeignet. Allerdings wird auf fixe und Referenzdaten nur sporadisch,dann aber umfangreich zugegriffen.Kosten werden hier pro GByte und nicht nach Leistung betrachtet.Wichtig ist die korrekte Nutzung der SATA-Platten. Lebensdauer und Ausfallquoten werden immer mit Bezug zu einem Duty-Cycle angegeben. Er legt fest, von welcher Nutzung bei einer Harddisk ausgegangen wird. Alle weiteren Parameter sind nur bei diesem Duty-Cycle gültig. Die Zahl gibt mitnichten den empfohlenen Anteil der Laufzeit auf 24 Stunden gerechnet an. Mit Duty-Cycle wird der Anteil der Plattenzugriffe über 24 Stunden definiert, bei dem sich die Mechanik des Laufwerks bewegt, also Such-, Lese- und Schreibzugriffe. Die Zeit, in der das Drive unbenutzt rotiert, zählt nicht dazu. Das führt zu Anwendungen, für die SATA-Platten besonders geeignet sind, und andere, die besser mit FC- und SCSI-Festplatten abgedeckt werden. Dies gilt insbesondere für alle Applikationen, die mit einer hohen Zahl von nicht sequenziellen Zugriffen ablaufen. Die große Menge an mechanischen Zugriffen beim ständigen Neupositionieren der Köpfe treibt den Duty-Cycle in die Höhe. Auch die Drehzahl spricht

294

7 Sicherheit

Abb. 7.1. Festplatten und Tapes im Vergleich84

bei transaktionsintensiven Anwendungen für FC oder SCSI. Diese Platten erreichen in der Regel 10.000 oder 15.000 U/min, während SATA-Disks meist nur mit 7.200 Umdrehungen betrieben werden.

7.8.4

Backup-Medium Band

Allein aufgrund des Kostenvorteils sind im Backup-Bereich häufig Bandsysteme im Einsatz. Der primäre Vorteil eines Bands im Vergleich zu einer Festplatte liegt neben den Kosten in der Möglichkeit, sie sehr einfach zu transportieren. Dieser Vorteil verliert jedoch bei den zunehmenden Möglichkeiten, sehr kostengünstig Daten online über weite Distanzen zu spiegeln, schnell an Bedeutung.

7.8.5 Verschlüsselung des Backups als Bestandteil einer Sicherheitsstrategie Die Notwendigkeit zur Verschlüsselung der Daten, insbesondere auf den BackupMedien, haben alle Beispiele bereits untermauert. Nur wenn die Backup-Daten sicher verschlüsselt sind, ist der Diebstahl des Mediums oder der Versuch einer Manipulation aus dem Unternehmen heraus sicher ohne Folgen. Dank der 84

SNW, a.a.O.

7.8 Backup als Bestandteil einer Sicherheitsstrategie

295

Verschlüsselung kann der Inhalt nicht mehr gelesen werden. Datensicherheit für Backup-Vorgänge ist nur über Verschlüsselung der Daten möglich.Viele Unternehmen schrecken jedoch vor dem Verschlüsseln der Daten zurück, da sie den hohen Administrationsaufwand und unverhältnismäßige Eingriffe in die Sicherungsabläufe fürchten. Bedenken, ob die chiffrierten Daten tatsächlich sicher sind, werden ebenfalls häufig geäußert. 7.8.5.1 Sicheres Verschlüsselungsverfahren Der seit einigen Jahren etablierte Advanced-Encryption-Standard (AES) gilt als besonders sicher. AES ist eine Blockchiffre, das heißt, die Daten werden vor der Verschlüsselung in Blöcke unterteilt.Jeder Block wird in verschiedenen Runden mit dem Schlüssel chiffriert, wobei sich die Anzahl der Runden aus Schlüssellänge und Blockgröße ergibt. Diese Werte sind voneinander unabhängig und können jeweils 128, 192 und 256 Bit betragen. Bei 128-Bit-Schlüsseln und 128-Bit-Blöcken gibt es zehn Runden, bei 256-Bit-Schlüsseln und 192-Bit-Blöcken 14. Beim Entschlüsseln werden die Operationen der einzelnen Runden in umgekehrter Reihenfolge durchgeführt. 7.8.5.2 AES-Algorithmus II Da der dem AES-Verfahren zugrunde liegende Riijndael-Algorithmus bislang keine mathematischen Lücken offenbart hat, lässt er sich nur über Brute-ForceAngriffe knacken, das Ausprobieren aller möglichen Buchstaben- und Zahlenkombinationen. Ist der Schlüssel 128 Bit lang, würde ein Rechner selbst bei elf Tera-Versuchen pro Sekunde (11 × 1012) – dem aktuellen Leistungsvermögen der Dechiffrier-Maschine „Deep Crack“ – 1018 Jahre benötigen, um alle Varianten durchzuspielen. Selbst wenn die richtige Kombination ein paar Jahre früher gefunden wird, ist der Algorithmus nach menschlichem Ermessen sicher. 7.8.5.3 Verschlüsselung am besten in der Virtual-Tape-Library Es bleibt der andere häufig geäußerte Vorbehalt, dass Datenverschlüsselung die Performance der Backup-Vorgänge übermäßig strapaziert. Sicher kostet es CPULeistung, wenn alle Daten vor dem Transfer durch den Krypto-Algorithmus geschickt werden. Moderne CPUs sind dem Rechenaufwand zwar gewachsen, aber nur, wenn sie keine anderen Aufgaben parallel abarbeiten müssen. Das ist aber keine hinreichende Begründung, ganz auf die Verschlüsselung bei Backup-Prozessen zu verzichten. Die Frage ist vielmehr, wo sie am besten durchgeführt wird. In Backup-Architekturen mit Virtual-Tape, die immer mehr Verbreitung finden, bietet sich dafür die VTL-Instanz selbst an. Eine Virtual-Tape-Library (VTL) kombiniert die Vorteile von Tape- und Disk-Backup, indem sie beliebige Datensicherungsumgebungen als virtuelle Backup-Volumes auf Festplattensystemen konsolidiert. Die Disks präsentieren sich den Backup-Hosts dabei als flexibel verfügbare Tapedrives. Entsprechende Lösungen lassen sich in der Regel ohne größere Eingriffe in vorhandene Sicherungsstrukturen integrieren und sind für alle gän-

296

7 Sicherheit

gigen Third-Party-Backup-Applikationen und Policies transparent. Ein weiteres Plus ist die Leistungsstärke: VTL-Lösungen bringen heute Durchsatzraten mit, die ein Vielfaches über denen traditioneller Bandbibliotheken liegen. Verschlüsselungsprozesse können diese hohe Leistungsfähigkeit nicht so verringern, dass die regulären Backup-Vorgänge ernsthaft beeinträchtigt werden. FalconStor hat seine Verschlüsselungsfunktion Secure Tape Transport Service (STTS) direkt in das Export/Import-Subsystem seiner VTL-Lösung integriert. Damit werden die Backup-Produktivsysteme nicht mit den Chiffriervorgängen belastet. 7.8.5.4 Authentizität der Daten Bei der Verwendung eines asymmetrischen Verfahrens kann zusätzlich die Authentizität der Daten sichergestellt werden. Bei asymmetrischen Kryptosystemen besitzt der Anwender zwei Schlüssel. Der erste Schlüssel, der öffentliche Schlüssel, dient dazu, die Daten zu verschlüsseln. Erst mit dem zweiten Schlüssel, dem geheimen Schlüssel, können die Daten im Bedarfsfall wieder gelesen werden. Diese Tatsache wird u. a. bei der elektronischen Unterschrift genutzt, da nur der Besitzer des geheimen Schlüssels einen Hash-Wert, der das Dokument identifiziert, chiffrieren kann. Der Hash-Wert des Dokumentes wird vom Empfänger der Nachricht errechnet und mit dem chiffrierten Hash-Wert, der mit dem öffentlichen Schlüssel dechiffriert werden kann, auf Übereinstimmung geprüft. Sind beide Hash-Werte gleich, ist sichergestellt, dass der Ersteller des Backups im Besitz des geheimen Schlüssels ist und das Backup nicht manipuliert wurde. 7.8.5.5 Schlüsselverwaltung Die Daten zu verschlüsseln ist eine Sache, die Schlüssel zu verwalten eine andere. Dieser Punkt bereitet Administratoren in der Regel das meiste Kopfzerbrechen, und das hat zwei Gründe: die Anzahl der Schlüssel und die Schlüsselübertragung. Im Fall der Chiffrierung von Backup-Daten spielt der erste Faktor allerdings eine geringere Rolle, denn da die Kommunikation beim Backup auf eine überschaubare Zahl „Teilnehmer“ beschränkt ist – die Speicherorte, zwischen denen die Daten transportiert werden – , hält sich die Menge der zu administrierenden Schlüssel in Grenzen. Beim Schlüsseltransport dagegen ist einiges mehr zu beachten. Der sicherste Algorithmus ist wertlos,wenn der Schlüssel verloren geht oder ungeschützt über einen unsicheren Kanal übertragen wird. Gängige Transportwege wie LAN, WLAN und Internet bieten viele Möglichkeiten, von außen einzugreifen, etwa per Man-in-the-Middle-Attacke. Der Angreifer erlangt zum Beispiel die Kontrolle über einen Router und leitet den Datenverkehr um. Sind Angreifer und Opfer im gleichen lokalen Netz, kann die Umleitung auch über eine Modifikation der ARP-Tabellen erfolgen (Ethernet-Protokoll für die Zuordnung von Internet- und Hardwareadressen). Auch SSL-verschlüsselte Verbindungen sind nicht von Haus aus sicher. Ohne Austausch digitaler Zertifikate zwischen Sender und Empfänger kann ein Dritter bei der ersten SSL-Verbindung falsche Schlüssel unterschieben und den Datenverkehr mitlesen.

7.9 Disaster Recovery als Bestandteil einer Sicherheitsstrategie

297

Verschlüsselungskonzepte für Backup-Daten müssen also auch Vorkehrungen für die sichere Schlüsselübertragung enthalten. Eine sinnvolle Option ist ein spezielles Passwortsystem für die Schlüssel, das gängigen Angriffsmustern Stand hält, zum Beispiel einer Wörterbuch-Attacke. Sie fußt auf der Überlegung, dass die meisten Passwörter aus sinnvollen Zeichenkombinationen bestehen, die von der angreifenden Instanz nacheinander ausprobiert werden. Passwörter müssen also so „unlogisch“ zusammengesetzt sein, dass sie nicht auf einfache Weise geknackt werden können. Werden entsprechende Funktionen in die VTL-Lösung integriert, liefert sie nicht nur hohe Datenübertragungsraten beim Backup, sondern schafft auch die Voraussetzungen für den sicheren Export der Daten auf Magnetbänder und deren gefahrlosen Transport.

7.9

Disaster Recovery als Bestandteil einer Sicherheitsstrategie

Der geneigte Leser wird sich fragen, warum ist auch der Disaster-Recovery– oder Katastrophenfall für ILM so wichtig. Die Anforderungen für Disaster-Recovery (DR) müssen einen zentralen Bestandteil der IT-Strategie jedes Unternehmens bilden. Die Geschäftskontinuität muss gesichert werden. Die entsprechenden Strukturen sorgen dafür, dass die betrieblichen Abläufe nicht unterbrochen werden. Mit dem Eintreten des DR-Falls werden zudem nicht die vorgestellten Anforderungen aufgehoben, nein, sie sind auch weiterhin zu beachten. Erschwerend kommt hier hinzu, dass zusätzlich der Stress des Neustarts der IT-Services in der DR-Site zu bewältigen ist. Die Analyse der Abläufe in K-Fällen und der K-Fall-Übungen zeigt folgende Verfahrensschwierigkeiten, die ein Disaster Recovery verzögern: • Das Fehlen einer Führungsstruktur bei Disaster-Recovery-Vorgaben • Verwirrung und Zeitverlust durch Mängel bei der Übergabe zwischen den einzelnen Arbeitsschichten • Keine festgelegte Aufgabenliste, veränderte Aufgabenverteilung von Schicht zu Schicht • Keine Überwachung und Kontrolle von Veränderungen • Fehlende Dokumentation • Eine zu enge Sichtweise: Daten wurden nur auf Band gesichert, ohne Einsatz von Softwarelösungen für den Schutz von abhängigen Servern und Anwendungen • Keine automatisierten Verfahren für das Auffinden der Bänder • Probleme durch Veränderungen an bereits funktionierenden Systemen • Mangel an qualifizierten Ressourcen bei den Unternehmen • Mangelnde Führung (unpassende Anweisungen durch das Topmanagement erschwerten die Recovery-Bemühungen und übten zusätzlichen Druck auf das IT-Personal aus)

298

7 Sicherheit

• Kein dediziertes Dokument, das die Umgebung, Inhalte von Backups oder das Netzwerksetup beschreibt • In vielen Fällen ist kein Online-Datenschutz vorhanden Auf der Basis der obigen Erfahrungen lassen sich folgende wichtige Anforderungen an die Disaster-Recovery-Planung ableiten: • • • • • • • • •

Keine Systeme mit „Single Point of Failure“ einsetzen Verteilte Netzwerke bevorzugen Komplette und regelmäßige Tests aller Backup-Einrichtungen durchführen Dokumentation der Systemkonfigurationen erstellen Dokumentation der Disaster-Recovery-Prozeduren erstellen Dokumentation genauso penibel wie Daten schützen (ILM-konform) Dokumentation und Trecking der Bänder implementieren Geschäftskritische Systeme identifizieren und schützen Alle Softwareoptionen zum Schutz von Servern, Anwendungen und Bandmedien zusätzlich zu den Daten sichern

Die Entwicklung, der Einsatz und die Wartung von umfassenden Business-Recovery-Plänen verlangen ein hohes Maß an Einsatz und fordern die IT sowohl technologisch als auch in Sachen Management. Jede potenzielle Lösung verursacht natürlich Kosten für Implementierung und Betrieb. Für die Planung einer entsprechenden DR-Site hat sich das folgende Schema als sehr geeignet erwiesen: • • • • • • • • •

Disaster Tier 0: „No Disaster Recovery Plan“ Disaster Tier 1: „Backup and Data Security without a Hot Site“ Disaster Tier 2: “Backup and Protection by Hot Site – Server out of Pool“ Disaster Tier 3: “Backup and Data Protection based on Hot Site – Server displacement“ Disaster Tier 4: “Point-in-time Copies – Server exclusive/shared“ Disaster Tier 5: “Transaction Integrity – Server exclusive/shared“ Disaster Tier 6: “Zero or little Data Loss – Server exclusive/shared“ Disaster Tier 7: „High automated, business-integrated Solution – Server exklusive/shared“ Disaster Tier 8: „Twin location automated, business-integrated Solution“

7.10

Archivierung als Bestandteil einer Sicherheitsstrategie

7.10.1

Rechtliche Anforderungen an die Archivierung

Die Abbildung von Geschäftsprozessen und -unterlagen in elektronische Dokumente erfordert eine geeignete Ablage der entstehenden Daten für die spätere Verwendung, deren Wiederauffinden und Aufbereitung. Dies betrifft sowohl Datensätze als auch die elektronischen Repräsentationen papierner Geschäftsdokumente und Belege. Die dauerhafte und unveränderbare Speicherung von elektroni-

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

299

schen Dokumenten und anderen Daten wird als Archivierung bezeichnet. Nicht allein, dass steuerrelevante Dateien ggf. 10 Jahre und länger in revisionssicherer Form archiviert werden müssen. Hinzu kommt, dass die Geschäftsführung für die Sicherheit der betriebswichtigen Daten und Systeme persönlich haften kann. Eine geordnete, jederzeit verfügbare Aufbewahrung der elektronischen Geschäftspost ist aber auch aus Gründen der strategischen Rechtssicherheit unabdingbar, insbesondere um das Unternehmen für eine etwaige juristische Auseinandersetzung beweisrechtlich zu positionieren. Indessen greift die uneingeschränkte Archivierung der gesamten Kommunikation ohne geeignete betriebliche Regelungen schnell in die Rechte der Mitarbeiter ein. In diesem Spannungsfeld diametral gegenläufiger Interessen und Rechtspflichten geht der Überblick allzu leicht verloren. Das hat nicht selten die fatale Folge, dass Unternehmensführung und Belegschaft ohne erkennbare Organisation der elektronischen Geschäftsabläufe „vor sich hin wursteln“. Die Sanktionen für Verstöße gegen archivierungsrelevante Buchführungsund Datenschutzpflichten sind erheblich. Speziellere Gesetze und Richtlinien für die Datensicherung ergeben sich aus dem Handelsgesetzbuch und der Abgabenordnung in Verbindung mit den Grundsätzen ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS von 1995) und den Grundsätzen zum Datenzugriff und zur Prüfbarkeit originär digitaler Unterlagen (GDPdU von 2002), die von allen Buchungspflichtigen zu beachten sind. Die genannten Rechtspflichten betreffen somit die sichere Informationsverbreitung und Informationsaufbewahrung. Stets geht es um sensible Information in Datenform und ihre Verfügbarkeit in bestimmter Form für eine bestimmte Dauer, kurz – und um abermals im Jargon zu bleiben – um ILM. Gehaftet wird hier unter anderem für die technisch und rechtlich sichere Aufbewahrung und die jederzeitige Integrität und Verfügbarkeit solcher Daten. Die Haftungsfolge tritt ein bei Fehlen oder Ungeeignetheit eines auf ihren Schutz, notfalls auf ihre Wiederherstellung gerichteten Konzepts. Die im Rahmen der IT-Sicherheit geforderte Datensicherung betrifft insbesondere auch Lotus Notes. Deren Rechtsnatur kann vielfältig sein.

7.10.2

Lotus Notes und E-Mail als rechtsrelevante elektronische Erklärungen

Zum einen kann es sich um elektronische Erklärungen handeln, weshalb es im Geschäftsverkehr erforderlich ist, täglich seine Accounts zu überprüfen. Denn bereits der Zugang, d. h. die Abrufbarkeit vom Mailserver, kann aufseiten des unternehmerisch tätigen Empfängers (bzw. seiner Mitarbeiter) Rechtsfolgen auslösen, ohne dass es der tatsächlichen Kenntnisnahme vom Inhalt der Lotus Notes bedarf. Vorsicht ist daher geboten bei der Verwendung von Mailadressen auf Visitenkarten,im Internet oder auf Geschäftsbriefen. Geht etwa eine elektronische Rechnung oder Mahnung zu, werden hierdurch bereits Zahlungs- bzw. Verzugsfolgen ausgelöst. Und im Handelsverkehr zwischen Kaufleuten gilt, dass der Vertragspartner auf ein ihm unterbreitetes Angebot unverzüglich mit einem so genannten kaufmännischen Bestätigungsschreiben reagieren, also ggf. widersprechen muss. Tut er dies

300

7 Sicherheit

nicht, muss er sich an dem vom Vertragspartner bestätigten Vertragsinhalt festhalten lassen, auch wenn er von ganz anderen Abmachungen ausgegangen war. Sein Schweigen gilt hier kraft Handelsbrauchs als Zustimmung. Wer also bei seinem geschäftlichen Auftritt eine Erreichbarkeit über seine geschäftliche Mailadresse suggeriert, muss auch für die tägliche Kontrolle dieser Mailbox sorgen.

7.10.3

Lotus Notes und E-Mail als Beweismittel bei der Dokumentation betriebswichtiger Vorgänge

Über die vertragliche Komponente hinaus ist die Lotus Notes und E-Mail zum anderen auch Gegenstand notwendiger (oder zumindest kaufmännisch gebotener) Dokumentation. Gerade das Beispiel Lotus Notes und E-Mail zeigt besonders deutlich das Interesse des Unternehmens, zu seiner eigenen Rechtssicherheit und beweisrechtlichen Positionierung so viele Informationen wie möglich zu sammeln, abzuspeichern, auszuwerten und für die Zukunft verfügbar zu halten. Dies beinhaltet häufig den Wunsch, bis zur Auslastungsgrenze der Speicherkapazität sämtliche Geschäftskorrespondenz automatisiert zu erfassen und über einen längeren Zeitraum zu sichern. Denn in einem Prozess muss jede Partei die ihr günstigen Tatsachen darlegen und beweisen. Und wenngleich die Lotus Notes im Grundsatz keinen höheren Beweiswert hat als beispielsweise ein Ausdruck aus dem Internet, die Kopie eines Papierdokuments oder die Vorlage einer Fotografie (etwas anderes gilt nur für Lotus Notes, die mit einer qualifizierten elektronischen Signatur nach Signaturgesetz versehen sind) und daher als Gegenstand der freien Beweiswürdigung nur dem Augenschein des Gerichts unterliegt, bietet sie jedoch in der Regel einen beweisrechtlichen „Wettbewerbsvorteil“. Denn der Ausdruck einer Lotus Notes ist häufig das einzige Beweismittel, das dem Gericht zu seiner Entscheidungsfindung vorliegt. Sie schafft mithin Indizien für den Aussteller, den Empfänger, das Absende- und Zugangsdatum und die Richtigkeit des in ihr niedergelegten Inhalts. Darüber hinaus kann sie eine wertvolle Gedächtnishilfe für die Zeugenvernehmung bilden. Die jeweils andere Partei, die sich gegen den mit der Lotus Notes begründeten Sachverhalt wehren will,ist wegen ihrer prozessualen Wahrheitspflicht daran gehindert,die in der Lotus Notes dokumentierten Angaben pauschal zu bestreiten. Einwände, die Mail stamme nicht vom Aussteller, sei beim Empfänger nicht zugegangen, enthalte falsche Datumsangaben oder sei inhaltlich verfälscht worden, wären daher von der dies einwendenden Partei genauestens zu substantiieren.

7.10.4

Grenzen der Dokumentation: Lotus Notes und E-Mail versus Mitarbeiterschutz

Die Maximalschwelle solcher Vorsorge bildet hier, wie eingangs angedeutet, jedoch das Datenschutzrecht und das Fernmeldegeheimnis der Mitarbeiter. So gilt bei erlaubter oder geduldeter Privatmail im Grundsatz, dass ohne die Zustimmung der Mitarbeiter oder ihrerVertretung (Betriebsrat/Personalrat) eine Überwachung der Inhalte der Kommunikation unzulässig ist.Wichtig ist ferner,dass private Mail dem

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

301

Mitarbeiter gehört und von ihm herausverlangt werden kann, dies prinzipiell auch nach seinem Ausscheiden. Auch ist es problematisch, Privatmail durch Spamfilter zu unterdrücken oder gar zu löschen. Zur Überwindung dieser Interessenkonflikte sind rechtlich-organisatorische Maßnahmen letztlich unabdingbar. Gemeint sind individualvertragliche Vereinbarungen mit dem Arbeitnehmer, Betriebsvereinbarungen, Sicherheit- und User-Policies sowie fortwährende Schulungs- und Qualifizierungsmaßnahmen der Belegschaft.

7.10.5

Lotus Notes und E-Mail als Gegenstand der gesetzlich zwingenden Dokumentation von Geschäftsvorfällen

Wenig verbreitet ist die Erkenntnis, dass Unternehmen nach handelsrechtlichen und steuerrechtlichen Grundsätzen verpflichtet sind,ihre Geschäftskorrespondenz („Handels- oder Geschäftsbriefe“) aufzubewahren. Dies betrifft Unterlagen, die für die Übersicht über einen bestimmten Geschäftsvorfall (im Sinne von Vorbereitung, Durchführung, Rückgängigmachung) bedeutsam sein können, gleichgültig in welcher Form (Briefe, Telefaxe, Lotus Notes) diese vorliegen. Gemeint sind also bspw. Aufträge und deren Bestätigung, Lieferpapiere, Rechnungen und Rechnungskopien, Reklamationen samt dazugehöriger Stellungnahmen, Gutschriften und Zahlungsbelege, Kontoauszüge, Bescheide über Steuern oder Gebühren, Kassenunterlagen, Produkt- und Preislisten (inkl. entsprechender Rundmailings zur Kundeninformation),Verträge, Gehaltsunterlagen etc. Hintergrund dieser weit reichenden Verpflichtung sind die Erfordernisse der Transparenz und Revisionssicherheit, d. h. die Archivierung aller Belege und Dokumente, die für eine betriebliche Überprüfung, aber auch vor den ordentlichen Gerichten Bedeutung erlangen können.

7.10.6

Zulässige Archivierungsformen

Nach den Bestimmungen des Handels- und Steuerrechts können die empfangenen und abgesandten Geschäfts- und Handelsbriefe und die Buchungsbelege auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn dies den Grundsätzen ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS) entspricht und sichergestellt ist, dass die Wiedergabe oder die Daten mit den empfangenen Handelsbriefen und den Buchungsbelegen bildlich und mit den anderen Unterlagen inhaltlich übereinstimmen, wenn sie lesbar gemacht werden, • dass sie während der Dauer der Aufbewahrungsfrist verfügbar sind und • dass sie jederzeit innerhalb angemessener Frist lesbar gemacht und für die Besteuerung maschinell ausgewertet werden können. Handels- und Steuerrecht verlangen vom Unternehmer mithin Transparenz sowie Revisions- und Datensicherheit. Die GoBS bilden dabei den Regelungsrahmen für die handelsrechtlichen Grundsätze der Ordnung, Nachvollziehbarkeit und Fälschungssicherheit, während die im Zuge der Abgabenordnungsänderung entstan-

302

7 Sicherheit

denen GDPdU diese Grundsätze letztlich auf alle originär hergestellten digitalen Unterlagen von steuerrechtlicher Relevanz erstrecken. Neben geeigneten Sicherheitsvorkehrungen gegen die unberechtigte Kenntnisnahme, Unauffindbarkeit,Vernichtung und den Diebstahl von gesicherten Programmen und Datenbeständen stellen GoBS und GDPdU insbesondere Vorschriften für die Archivierung digitaler Dokumente und für den Zugriff auf diese Dokumente im Rahmen von Betriebsprüfungen auf. Dabei muss die Prüfbarkeit und Belegbarkeit sämtlicher Geschäftsvorfälle, die Nachvollziehbarkeit etwaiger Stornierungen und Änderungen, die Datensicherheit, die interne Kontrolle und die Einhaltung der gesetzeskonformen Aufbewahrungsfristen gewährleistet sein. Notwendig ist ferner eine umfassende Verfahrensdokumentation dieser Abläufe, die nachvollziehbar beschreibt, wie die relevanten Informationen angelegt, geordnet, gespeichert, indiziert und geschützt wurden und später wieder gefunden und verlustfrei reproduziert werden können. Die archivierten Daten müssen in wiedergabefähiger, maschinell lesbarer und auswertbarer Form zur Verfügung gestellt werden können. Ihre periodengerechte Auswertung durch die jeweils aktuelle Prüfsoftware der Finanzverwaltung muss gewährleistet sein. Der Steuerpflichtige ist zur Kooperation verpflichtet. Bei der Archivierung von Lotus Notes ist außerdem darauf zu achten, dass auch die Attachments und – im Falle der Signierung und Verschlüsselung – auch die verschlüsselten und entschlüsselten Dokumente nebst Schlüsseln mit aufbewahrt werden. Betroffen sind zum einen alle steuerrelevanten Unterlagen, also sämtliche Informationen, die für eine steuerliche Veranlagung im Sinne von Entstehen, Entfallen oder Minderung einer Steuerlast Bedeutung erlangen können. Andererseits geht es bei den Aufbewahrungspflichten freilich – wie bereits dargestellt – nicht allein um die im engeren Sinne steuerrelevanten Unterlagen. Gemeint sind darüber hinaus die nach Handelsrecht aufbewahrungspflichtige „bloße“ Geschäftskorrespondenz und die einschlägigen Organisationsunterlagen des Unternehmens (beispielsweise Gründungsprotokolle, Prüfberichte, Aufsichtsratsbeschlüsse, ferner aber auch die Arbeitsverträge, Lohn- und Sozialversicherungsunterlagen der Arbeitnehmer oder die im laufenden Geschäftsbetrieb abgeschlossenen Verträge mit der in diesem Zusammenhang angefallenen Korrespondenz, gleichgültig in welcher Form).

7.10.7

Folgen einer Verletzung der Archivierungspflicht

Werden jedoch, wie in der Praxis häufig anzutreffen, die Ordner und Mailboxen in regelmäßigen Abständen „auf eigene Faust“ analysiert, Altbestände in Archivordner verschoben und Mails, die für überholt (und daher nicht mehr geschäftsrelevant) gehalten werden, gelöscht, steht dies häufig im Gegensatz zu den oben genannten Vorschriften. Verstöße sind mit Zwangsmaßnahmen, Schätzung, straf- und bußgeldrechtlicher Ahndung und der Versagung gesetzlicher Steuervergünstigungen sanktioniert.

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

7.10.8

303

Archivierungsprozess

Die für das Unternehmen entwickelte Speicherlösung mit großen kostengünstigen Speicherkapazitäten schafft neue Möglichkeiten in der Archivierung und vor allem in der Auswertung von Archivdaten. Gleichzeitig findet eine Annäherung der Datenhaltungssysteme (Produktivdaten) und Datenarchivierungssysteme (Langzeit-Archivdaten) statt. Diese Entwicklung eröffnet neue Möglichkeiten bei der Definition von Archivierungsprozessen, welche durch die neuen gesetzlichen Rahmenbedingungen grundsätzlich unterstützt werden. Die Archivierungsprozesse müssen in einem größeren Kontext gesehen werden. Außer einer reinen Umstellung der Archivierung vom bewährten Papierarchiv zu elektronischen Archiven besteht noch bedeutend mehr Optimierungspotenzial. Ein moderner und effizienter Archivierungsprozess beginnt bereits bei der Erfassung der Daten und nicht erst mit der Notwendigkeit, Daten aus Systemen zu räumen, wenn die Speicherkapazitäten an ihre Grenzen gelangen. Die erfassten Daten werden zuerst im Produktivsystem genutzt und anschließend elektronisch ins Datenarchivierungssystem überführt. Die hohen technischen und organisatorischen Anforderungen für die Archivierung mittels elektronischer Informationsträger zielen auf eine hohe Fälschungssicherheit und Integrität der gespeicherten Informationen ab. Beim unveränderbaren Informationsträger müssten diese Eigenschaften bereits durch das Produkt selbst erfüllt sein. Artikel 3, 4 und 9 GeBüV (Geschäftsbücherverordnung) verlangen, dass gewisse Fälschungsrisiken mittels angemessener unternehmensspezifischer organisatorischer Maßnahmen zu minimieren sind (z. B. Prozessmanagement, Protokollierung). Beim Einsatz veränderbarer Informationsträger für die Archivierung ist die Integrität der gespeicherten Informationen von Gesetzes wegen auch mittels technischerVerfahren zu gewährleisten.Als geeignete Maßnahme werden in der GeBüV die digitalen Signaturverfahren genannt. Die Herausforderung bei den digitalen Signaturverfahren liegt jedoch in der Verhältnismäßigkeit der dazu erforderlichen Aufwendungen. So ist es kaum praktikabel, z. B. bei einem Transaktionssystem, jede einzelne Transaktion digital zu signieren. Verzichtet ein Unternehmen auf die (nur beispielhaft genannten) elektronischen Signaturverfahren, sind andere angemessene technische Verfahren zu evaluieren und anzuwenden. Der Zeitpunkt der Speicherung der Informationen auf veränderbaren Informationsträgern muss unverfälschbar nachweisbar sein. Als geeignetes Verfahren nennt der Verordnungsgeber den Zeitstempel. In der Praxis sind die digitalen Zeitstempelungsverfahren allerdings vielfach an die Uhr des Betriebssystems gekoppelt, deren Einstellung relativ einfach änderbar ist. Es sind daher zusätzliche Kontrollen und Maßnahmen erforderlich. Das Unternehmen muss im Rahmen des Klassifizierungsprozesses festhalten, welches sein Verständnis bezüglich der organisatorischen und technischen Anforderungen für die Archivierung ist. Dazu muss beispielsweise bestimmt werden, • welche Geschäftsunterlagen aufbewahrt werden sollen/müssen (Form,Gründe, Dauer),

304

7 Sicherheit

• welche Speichersysteme und Speichermedien zum Einsatz kommen, • welches die Anforderungen an die Sicherheit und Lösungsansätze bezüglich Unverfälschbarkeit sind, • wie die Prozesse bezüglich Archivierung und Zugriff aussehen und in die operativen Geschäftsprozesse integriert werden sollen und • welche Kontrollen vorhanden sein müssen, um einen sicheren und vertraulichen Archivierungsprozess zu gewährleisten. Das noch aufzustellende Archivierungskonzept umfasst folgende Komponenten: • • • • • • • • • • •

Systemarchitektur, Gebäudekonzept, Prozess je Dokumentenart, Achivierungsform, Aufbewahrungsdauer, Technische Varianten, Organisation, Betriebskonzept, Sicherheitskonzept, Notfallplan, Pflichtenheft.

7.10.9

Archivierungsformate und Archivierungsformatanforderungen

Eine wichtige Anforderung an Archivierungsformate ist die Plattformneutralität, d. h. die Daten müssen auf allen Computersystemen verwendbar sein. Ebenso wichtig ist Herstellerunabhängigkeit, d. h. dass das Format nicht an Hard- oder Software eines einzigen Herstellers gekoppelt ist. Idealerweise handelt es sich um ein freies Format, dessen vollständige Dokumentation öffentlich zugänglich ist und das keinerlei lizenzrechtlichen Beschränkungen unterliegt. Auf das Format soll mit beliebigen Programmiersprachen zugegriffen werden können. Doch auch Daten, die auf allen Plattformen lesbar, öffentlich dokumentiert und lizenzrechtlich frei sind, lassen sich damit noch nicht notwendigerweise sinnvoll recherchieren oder in sinnvoller Weise in verschiedenen Medien ausgeben. Eine einfache Textdatei beispielsweise wird häufig den Anspruch der Systemunabhängigkeit erfüllen. Aber sie kann nur per einfacher Volltextsuche durchsucht und nur durch aufwendige manuelle Arbeit formatiert werden, da schon einfachste Gliederungselemente wie z. B. Überschriften nicht als solche in den Daten gekennzeichnet sind und damit nicht automatisiert verarbeitet werden können. Man kann also noch einen weiteren Anspruch an die Daten hinzufügen, nämlich die Möglichkeit, diese gemäß ihren spezifischen Inhalten und Strukturen automatisch auszuwerten. Es gibt mithin mehrere Gründe, in medienneutralen Daten nicht die Formatierung eines Dokumentes, sondern die Struktur und die Art des Inhalts eindeutig zu beschreiben. Der Wichtigste ist sicherlich, dass die Struktur eines Dokumentes mit seinem Inhalt verbunden ist, während die Formatierung nichts

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

305

Absolutes ist. Ein Dokument bestimmten Inhalts kann auf unterschiedlichste Weise formatiert werden, ohne dadurch seine Struktur zu verlieren. Wenn also der Text und seine formale wie inhaltliche Struktur eindeutig codiert sind, wird sich jede systematische Formatierung seiner Elemente daraus herstellen lassen. Die Struktur eines Textes in einer objektivierten und für den Rechner lesbaren Form im Dokument abzuspeichern,löst eine ganze Reihe Probleme.Zunächst wird der Text automatisiert weiterverarbeitbar, und zwar in beliebiger Typografie und für die unterschiedlichsten Ausgabeformen. Damit wird dem Anspruch auf Medienneutralität Rechnung getragen. Da die Struktur explizit in den Daten codiert ist, sind die Daten durch Suchanfragen erschließbar, die die Struktur mit berücksichtigen und so viel genauer formuliert werden können. Schließlich lassen sich in einem Text sehr viel mehr Informationen abspeichern, als zur rein typografischen Umsetzung benötigt werden, z. B. Verwaltungsinformationen.

7.10.10

Langzeitstabile Formate für textbasierte Informationen: SGML, HTML und XML

7.10.10.1 SGML Der Ursprung des ersten Standards lag im Bestreben der Publisher im Industrieund Verlagsbereich, ein Standarddatenformat für Textinhalte zu schaffen, das der Verwendung in verschiedenen Publikationssystemen (Print, elektronische Publikationen) ebenso entgegenkommt wie der Auswertbarkeit durch Rechnersysteme (z. B. für intelligente Suchanfragen). Solche Daten nennt man „medienneutral“. Medienneutrale Daten müssen in einer Form vorgehalten werden, die für alle gewünschten Publikationsformen als Quelldatenformat dienen kann. Ein erster medienneutraler Standard wurde 1986 mit der „Standard Generalized Markup Language“ (SGML) geschaffen. SGML ist eine Auszeichnungssprache, die als internationaler Standard alle textuell wiedergebbaren Inhalte strukturieren kann. Eine SGML-Datei stellt eine ganz normale Textdatei dar, die sich auf allen Plattformen und mit einfachster Software öffnen lässt. Die Auszeichnung oder Markierung (engl.Markup) der Inhalte mit weiter gehenden Informationen erfolgt ebenfalls in Textform, wobei die Auszeichnungen mit Begrenzungszeichen (engl. Delimiter) von den Inhalten abgegrenzt werden.Auszeichnungen in SGML können auch ganze Abschnitte umfassen, die z. B. als „kapitel“ oder „abschnitt“ markiert sind, wobei Abschnitte geschachtelt auftreten können, um so Unterabschnitte zu repräsentieren. Jeder Abschnitt kann wiederum seine eigene Überschrift tragen etc. Auszeichnungen in SGML können so gestaltet werden, dass sie selbsterklärend und auch ohne Software verständlich sind. Eine so aufgebaute SGML-Datei kann auch als Papierausdruck gelesen und verstanden werden. SGML-Software kann die Auszeichnungen verwenden, um den markierten Text z. B. in einem bestimmten Layout anzuzeigen oder spezifisch nach Textstellen in Überschriften zu suchen. SGML ist dabei nicht selbst eine Auszeichnungssprache (d. h. es werden keine bestimmten Auszeichnungen vorgegeben), sondern sie legt die Syntax fest, in

306

7 Sicherheit

der eigene Auszeichnungssprachen definiert werden können. Jede Art von Dokument soll entsprechend seiner Eigenart nach Inhalt und Struktur erschlossen werden können. SGML löst dieses Problem dadurch, dass keine Struktur und keine Elemente vorgegeben werden, sondern eine Sprache zur präzisen Beschreibung von Dokumentstrukturen bereitgestellt wird. So kann der Anwender selbst festlegen, welche Textelemente mit welchen Tags ausgezeichnet werden sollen. Diese Möglichkeiten werden von Anwendergruppen (Industriezweige,Verlagsverbünde) genutzt, die für ihre Inhalte passende Auszeichnungen definieren, um diese Inhalte leichter austauschen und automatisiert verarbeiten zu können. Allerdings hat SGML einen Vorteil, der in der Praxis zum Nachteil wird, nämlich seine extreme Flexibilität und Komplexität. SGML lässt dem Nutzer so viele Möglichkeiten und bietet so komplexe Konstruktionen an, dass es sehr aufwendig ist, Software zu programmieren, die den Standard voll umsetzt. Daher hat sich SGML nur begrenzt durchsetzen können. Anwendung findet SGML insbesondere dort, wo große Datenmengen codiert werden müssen und die finanziellen Ressourcen nicht zu knapp sind. 7.10.10.2 HTML SGML fand bisher über alle Nutzergruppen hinweg weltweite Verbreitung als Hypertext Markup Language (HTML), die Seitenbeschreibungssprache für InternetBrowser, festgelegt vom World Wide Web Consortium (W3C), dem Internet-Standardisierungs-Gremium. HTML ist also eine konkrete Anwendung von SGML – allerdings eine extrem beschränkte. Wenige festgelegte Auszeichnungen dienen dem einzigen Zweck, Text und Grafiken im Web-Browser zu formatieren bzw. zu positionieren und Webseiten mit Links zu verbinden. Mit HTML können medienneutrale oder inhaltlich orientierte Auszeichnungen nur sehr begrenzt vorgenommen werden. Diese Grenzen von HTML, die auch dem Datenaustausch im Internet zunehmend hinderlich wurden, führten dazu, dass das W3C 1998 mit der eXtensible Markup Language (XML) eine neue Auszeichnungssprache definierte. 7.10.10.3 XML XML ist wie SGML keine Sprache mit einem festen Repertoire von Auszeichnungen, sondern eine Sprache zur präzisen Beschreibung von Dokumentstrukturen mittels frei festlegbarer Auszeichnungen. XML ist also im Gegensatz zum ganz und gar vordefinierten HTML erweiterbar (extensible).Andererseits sind bei XML viele Merkmale, die bei SGML frei bestimmbar waren, konkret festgelegt. Während die ISO-SGML-Norm über 500 Seiten umfasst, kommt die Druckfassung des XMLStandards mit 26 Seiten aus. Durch die Vereinfachung der Programmierung von Anwendungssoftware entstand eine breite und kostengünstige Basis für die praktische Nutzung. Diese Basis hat zusammen mit der vergleichsweise einfachen Anwendbarkeit der Sprache XML zu ihrer enormen Verbreitung beigetragen. XML hat SGML de facto verdrängt, nur in wenigen Fällen wird SGML noch verwendet.

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

307

Der Vorteil der Verbreitung von XML wiegt die Einschränkungen gegenüber SGML leicht auf. Inzwischen arbeiten fast alle relevanten Anwendungen im Publishing-Bereich mit XML, angefangen mit Microsoft Office über Satzprogramme bis hin zu OnlinePublishing-Systemen. Aber XML ist nicht immer gleich XML – das XML, das in Microsoft Word verwendet wird, enthält wie schon HTML vorrangig Formatierungsinformationen, während die medienneutrale Verwendung Informationen über Inhalt und Struktur benötigt. Dennoch ist die XML-Fähigkeit der meisten Programme eine Voraussetzung für die breite Nutzung des Formats. Um beim Beispiel Microsoft Office zu bleiben – mit PlugIns kann man Microsoft Word nun auch dazu bringen, als Editor für inhalts- und strukturorientiertes XML zu dienen. Für die medienunabhängige Codierung von Textinhalten eignet sich XML in ausgezeichneter Weise. Es erfüllt dabei zugleich alle Kriterien, die an ein langzeitstabiles Datenformat gestellt werden können.

7.10.11

Langzeitstabile Formate für Pixelgrafiken: TIFF

TIFF (Tagged Image File Format) ist ein Datenformat zur Speicherung von Bilddaten. Es wurde ursprünglich von Aldus (1994 von Adobe übernommen) und Microsoft für gescannte Bitmapbilder entwickelt. Es ist eines der wichtigsten Formate zum Austausch von Daten in der Druckvorstufe. Die Dokumentation ist frei verfügbar. ISO-normiert sind die TIFF-Spezifikationen für Digitalfotografie (TIFF/EP; ISO 12234-2:2001) und die medienunabhängige Bildverarbeitung (TIFF/IT; ISO 12639:2004). Eine sehr große Verbreitung hat die Basisversion von 1992 (TIFF 6.0). TIFF ist plattformunabhängig. Software zur Erstellung und Verarbeitung von TIFF ist für alle Hard- und Softwareplattformen verfügbar, alle professionellen Grafik- und Satzprogramme akzeptieren TIFF-Dateien. TIFF eignet sich in besonderem Maße für den Druck, da es sowohl Farbmanagementinformationen, Farbseparation und den Beschneidungspfad für Bildmotive ohne Hintergrund speichern kann. Für die Archivierung ist die verlustfreie Qualität des TIFF-Bildes gefragt. TIFF berücksichtigt verschiedene Verfahren zur Datenkomprimierung. In einer TIFF-Datei können mehrere Bilder abgelegt werden. Das können verschiedene Versionen desselben Bildes sein, z. B. ein Vorschaubild (Thumbnail) und das Originalbild oder mehrere Bilder mit jeweils einem Vorschaubild. Dabei unterstützt es sowohl verlustlose als auch verlustbehaftete Kompressionsverfahren. Ein Nachteil des TIFF-Formates ist seine Komplexität,die dazu führt,dass es oft von Programmen mit einer fehlerhaften Implementierung nicht richtig verarbeitet wird. Die Vielfalt möglicher gültiger TIFF-Dateien kann zudem von keinem einzelnen Programm vollständig unterstützt werden. In der Spezifikation des Datenformats ist deswegen mit Baseline-TIFF eine Untermenge gültiger TIFF-Dateien definiert, die jedes TIFF-fähige Programm verarbeiten können sollte. TIFF-Dateien sind auf eine Größe von 4 GB beschränkt. Weiterhin können TIFF-Dateien nicht gestreamt werden, d. h., es muss vor einer Anzeige erst die ganze Datei oder ein erheblicher Teil davon geladen werden. Eine Dokumentation

308

7 Sicherheit

des Formats wird von Adobe kostenlos als PDF-Datei zur Verfügung gestellt. Die aktuelleVersion ist TIFF 6.0 vom 3.Juni 1992.Sie wird ergänzt durch TIFF Technical Notes. Dabei handelt es sich um Erweiterungen, die TIFF einzelne Fähigkeiten hinzufügen, u. a. das Deflate-Verfahren zur verlustlosen Datenkompression. Aufgrund seiner Verbreitung und Plattformneutralität ist TIFF als langzeitstabiles Datenformat geeignet, wobei aber die Baseline-Einschränkungen eingehalten werden sollten. Über die Baseline-Spezifikationen hinausgehend, sind folgende Einschränkungen zu beachten: • Farbbilder sind nicht als „Palette-color images“ (Pseudofarben) zu speichern, obwohl dies von Baseline-TIFF unterstützt wird. • Bilder sind immer und ausnahmslos unterVerwendung der verlustfreien (Fax-) Komprimierung Gruppe 4 (Standard der ehemaligen CCITT, heute ITU) zu speichern, obwohl dies technisch gesehen keine Baseline-Option ist. • Colormetrie-Informationen sollten wenn möglich mit gespeichert werden. • Für Farb- und Graubilder sollte die verlustfreie LZW-Kompression verwendet werden. Diese Option wird derzeit leider relativ selten unterstützt, weil potenziell Lizenzgebühren für die Software, die dieses Verfahren nutzt, anfallen. Da mit LZW-Kompression eine Reduktion der Datenmenge um bis zu 50 Prozent erreicht werden kann, sollte diese Option für Projekte mit großen Datenmengen dennoch in Erwägung gezogen werden.

7.10.12

Langzeitstabile Formate für Pixelgrafiken: PNG

Aufgrund seiner technischen Eigenschaften und seines Status als ISO-Norm (seit 2004) und W3C-Recommendation kommt auch das neue Format PNG (Portable Network Graphics) für die digitale Langzeitarchivierung in Frage. Bisher ist PNG jedoch noch nicht so weit verbreitet wie TIFF oder EPS.Die Tatsache,dass PNG und das von PNG verwendete Kompressionsverfahren im Gegensatz zu TIFF vollständig frei von Lizenzansprüchen ist, spricht für seine Verwendung als Datenformat für Archivierungszwecke. Technisch ist PNG ein plattformübergreifendes Datenformat und enthält einen verlustfreien Komprimierungsalgorithmus. PNG eignet sich sowohl für digitale Master als auch digitale Nutzungsformen. Wie auch GIF kann PNG Pixel aus einer Farbpalette mit bis zu 256 Einträgen verarbeiten. Für die Archivierung interessant ist aber eher die Unterstützung hoher Farbtiefen (16 Bit für Graustufenbilder und bis zu 48 Bit für Farbbilder gegenüber 8 Bit bei Graustufen und 24 Bit bei Farbe im Baseline-TIFF-Format). PNG kann Informationen zu Farbmanagement, Farbseparation und den Beschneidungspfad für Bildmotive ohne Hintergrund speichern (Gamma-Faktor, Alphakanal und K-Wert, ab Version 1.2 können auch ICC-Profile eingebettet werden, LAB-Fähigkeit). Anders als TIFF unterstützt PNG einen linearen und schrittweisen Bildaufbau (bereits bei 20-30 Prozent der übertragenen Bilddaten ist der Bildinhalt erkennbar). Damit ist es als Web-Format verwendbar. PNG ermöglicht das Abspeichern

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

309

zusätzlicher Informationen, wie zum Beispiel Autoren- und Urheberhinweise, in der Grafikdatei. Beim Einsatz von PNG für Archivzwecke sollte nur die verlustfreie Kompression verwendet, auf Palettenfarben verzichtet und so viele technische Bildinformation wie verfügbar mit gespeichert werden.

7.10.13

Langzeitstabile Formate für Pixelgrafiken: GIF, BMP, JPEG, JPEG 2000

Die weit verbreiteten Grafikformate GIF, BMP und JPEG sind nicht für die Langzeitarchivierung geeignet (Ausnahme: JPEG 2000). 7.10.13.1 GIF GIF (Graphics Interchange Format; Servicemarke der CompuServe Inc.) ist ein Format für die Bildschirmdarstellung von Pixelgrafiken und ermöglicht lediglich die Verwendung von maximal 256 Farben aus einer Palette. Sein Komprimierungsmechanismus ist lizenzrechtlich (bis 2003/2004) nicht frei. 7.10.13.2 BMP BMP (Bitmap) ist ein ursprünglich proprietäres Grafikformat von Microsoft Windows, das in verschiedenen Varianten vorliegt. Es ist auf die Bildschirmdarstellung von Pixelgrafiken beschränkt und bietet bei weitem nicht die Möglichkeiten der Prepress-Formate TIFF und PNG. Am weitesten verbreitet ist Version 3 (frühere gibt es nicht). Microsoft hat mit Windows 95 und Windows 98 die neueren Versionen 4 und 5 des BMP-Formates eingeführt, die Alphakanäle und Farbkorrektur ermöglichen und als Containerformat für PNG- und JPEG-Dateien verwendet werden können. Diese neuen Formate sind jedoch nur sehr selten als eigenständige Dateien anzutreffen und werden kaum von Anwendungen unterstützt; sie finden eher als internes Format in Windows-Programmen Verwendung. 7.10.13.3 JPEG JPEG (Joint Photographic Experts Group) verwendet eine verlustbehaftete Kompression, was ein Ausschlusskriterium für die Anwendung in der Langzeitarchivierung ist. 7.10.13.4 JPEG 2000 JPEG 2000 ist dagegen ein äußerst mächtiges Grafikformat, das auch als ISO-Norm vorliegt. Bei der Entwicklung von JPEG 2000 wurden ausdrücklich die Kriterien berücksichtigt, die die Langzeitarchivierung an ein Format stellt. Allerdings hat JPEG 2000 den Status eines tatsächlichen Standards noch nicht erreicht, seine Verbreitung und Akzeptanz ist noch gering. Sollte sich das ändern, ist JPEG 2000 ein starker Kandidat für die Langzeitarchivierung von Pixelgrafiken.

310

7 Sicherheit

7.10.14

Langzeitstabile Formate für Vektor- und kombinierte Grafiken: EPS

Neben TIFF ist EPS (Encapsulated Postscript; Adobe Systems) das zweite professionelle Standardformat für Grafiken in der Druckvorstufe. Als Austauschformat ist es seit vielen Jahren etabliert. Der Standard ist vom Hersteller vollständig dokumentiert und nicht lizenzbelastet. EPS ist eine Untermenge von Adobes ebenfalls frei dokumentierter Seitenbeschreibungssprache PostScript und Austauschformat für diese. Viele Grafik- und Layoutprogramme auf allen wichtigen Betriebssystemen unterstützen EPS. EPS dient zur Speicherung von Vektorgrafiken, Rastergrafiken mit Halbtönen, formatiertem Text und ganzen Seitenlayouts einschließlich Schriften. Verfügbare Farbmodi sind RGB, Lab, CMYK, Duplex, indizierte Farben und Graustufen. EPS arbeitet mit Farbtiefen von 1, 4, 8 und 24 Bit/Pixel. Im Gegensatz zu PostScript beschreibt EPS pro Datei immer nur eine Seite. Es sind daher einige PostScriptBefehle, insbesondere druckerspezifische, nicht zulässig. Durch die frei verfügbare Dokumentation, die große Verbreitung und die Systemunabhängigkeit ist EPS ebenso wie TIFF für die Langzeitarchivierung geeignet. Allerdings ist eine korrekte Darstellung und Bearbeitung nur über ein Programm möglich, das die Vektorinformationen in EPS verarbeiten kann, was aber mit allen professionellen Zeichenprogrammen möglich ist. Viele Bildbetrachtungsprogramme können das für die Druckausgabe konzipierte EPS aber nicht darstellen. Daher kann in EPS ein Vorschaubild integriert werden, wobei auch plattformspezifische Formate erlaubt sind, was allerdings dem Ziel der Plattformneutralität zuwiderläuft.Als Format für die schnelle Online-Übertragung ist EPS daher ebenfalls nicht geeignet. EPS enthält anders als TIFF auch keinen integrierten Komprimierungsalgorithmus. EPS hat gegenüber TIFF jedoch den Vorteil, dass enthaltene Vektorgrafiken und Schriften in der Größe skaliert werden können, ohne dass die Genauigkeit leidet. Texte und Grafiken können zudem aus EPS-Daten extrahiert werden. EPS ist daher besonders als Langzeitarchivierungsformat für Vektorgrafiken geeignet, vor allem wenn diese in Kombination mit Texten auftreten (z. B. Charts, Pläne). Bei der Erstellung von EPS sollte auf die folgenden Punkte geachtet werden: Alle notwendigen Daten wie z. B. Schriften müssen in die EPS-Datei eingeschlossen (inkludiert) werden. Auf die Abspeicherung von EPS-Daten in Form von Binärdaten (8-Bit-EPS) sollte verzichtet werden, stattdessen sollten sie als ASCII-EPS (7-Bit-EPS) gespeichert werden. Binäre EPS-Dateien sind zwar kleiner, können aber nicht mit allen Systemen gelesen werden. Auf die Einbindung eines Vorschaubildes sollte verzichtet werden, da hier je nach Plattform unterschiedliche Formate verwendet werden, was zu Problemen auf der jeweils anderen Plattform führen kann. (Die Einbindung von Vorschaubildern im EPS-spezifischen, plattformneutralen EPSI-Format wird leider von vielen Programmen nicht unterstützt und führt zudem zu einer deutlichen Vergrößerung des Speicherbedarfs.) Die Bounding-Box (das die Grafik umschließende Rechteck) muss korrekt angegeben werden. DSC-Kommentare sollten weitgehend genutzt werden (DSC –

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

311

Document Structuring Conventions; Angaben zu technischen Spezifika des EPS). Es sollten keine geräteabhängigen Optionen verwendet werden (Rastereinstellungen, Transferfunktionen, Überdruckvorschau, Schwarzaufbau, ICC als Gerätefarben). Da die Erzeugung von EPS-Daten mittels Druckertreibern oft zu Problemen führt, sollten stattdessen die EPS-Speicheroptionen professioneller Grafikprogramme verwendet werden. Bei der Wahl von langzeitstabilen Formaten sollte auch der Aspekt einer möglichst einfachen Nutzbarkeit eine Rolle spielen. Hier schneidet EPS aufgrund des Problems der fehlenden Darstellbarkeit durch Standardviewer nicht gut ab. PDF, das als ebenso mächtiges Format für skalierbare und extrahierbare Schriften und Vektorgrafiken in Frage kommt, kennt keine Viewer-Probleme und kann daher als flexiblere Alternative in Betracht gezogen werden (zu PDF und den damit verbundenen potenziellen Problemen siehe Abschnitt 7.10.16.4).

7.10.15

Langzeitstabile Formate für Vektorgrafiken: SVG

SVG (Scalable Vektor Graphics) ist eine auf XML basierende Auszeichnungssprache, die seit 2001 als W3C Recommendation vorliegt (seit 2003 als Version 1.1, 1.2 ist in Arbeit). Mit SVG können skalierbare Vektorgrafiken und Vektoranimationen auf der Grundlage von XML codiert werden. Als internationaler Standard und W3C-Norm kommt SVG auch als Format für die Archivierung von Vektorgrafiken in Frage. Auch Texte und Pixelgrafiken lassen sich einbinden. Die Orientierung von SVG auf die Nutzung im Internet bedeutet allerdings, dass SVG bei weitem nicht so viele Formatierungsmöglichkeiten bietet wie EPS oder PDF. Zudem hat SVG noch lange nicht den Verbreitungsgrad der etablierten Formate, ist aber auf dem Vormarsch. Solange es um Speicherung und Archivierung von Vektorgrafiken geht, die bereits als SVG vorliegen, spricht nichts gegen die Archivierung der SVG-Daten. Als Alternative bietet sich auch hier PDF an, das Vektorgrafiken und Schriften ebenfalls in skalierbarer und extrahierbarer Form speichern kann.

7.10.16

Langzeitstabile Formate für Seitenbeschreibung und beliebige Grafiken: PDF

PDF (Portable Document Format) ist ein Datenformat zur systemübergreifenden Seitenbeschreibung, das von Adobe Systems entwickelt wurde. Es ist neben PostScript der internationale De-facto-Standard für die Erzeugung von Druckvorlagen. PDF ist ursprünglich ein proprietäres Datenformat. Es basiert zu großen Teilen auf dem Seitenbeschreibungsformat PostScript, ebenfalls von Adobe Systems. Das Format ist im PDF Reference Manual von Adobe vollständig dokumentiert. Dadurch können durch Drittentwickler beliebige PDF-Werkzeuge bereitgestellt werden.

312

7 Sicherheit

7.10.16.1 PDF als ISO-Norm Seit 2001 hat die PDF-Variante PDF/X (X für exchange), die speziell dem Dokumentenaustausch dienen soll, den Status einer ISO-Norm (ISO 15930). PDF/X wurde seitdem beständig weiterentwickelt und liegt inzwischen als Version 3 vor (PDF/X-3; ISO 15930-6:2003).Eine weitere Variante speziell für Zwecke der Langzeitarchivierung (PDF/A) befindet sich auf dem Weg zur ISO-Norm, den sie 2006 erreicht haben soll (ISO/CD 19005-1 Electronic document file format for long-term preservation – Use of PDF 1.4 (PDF/A); Publication target date: 2006-09-01). 7.10.16.2 PDF als Web-Format Seinen hohen Verbreitungsgrad verdankt PDF vor allem dem Adobe Reader von Adobe, einem kostenlosen PDF-Viewer, der sich auch als Plug-In in InternetBrowser einbinden lässt und für alle Soft- und Hardwareplattformen zur Verfügung steht. Dadurch hat PDF weltweit eine herausragende Bedeutung bei der Publikation von formatierten Print-Inhalten über das Internet erhalten. Eine PDFDruckvorlage ist immer zugleich auch für die Web-Publikation verwendbar – lediglich die Dateigröße muss minimiert werden, was bei PDF unproblematisch ist, wenn man Qualitätsverluste etwa bei Pixelgrafiken in Kauf nimmt. Das Anzeigen von Printseiten auf einem PC-Bildschirm ist zwar nicht die optimale Lösung für Online-Publishing-Zwecke, aber kostengünstig und im Falle von PDF in der Darstellungsqualität (vor allem auch bei Ausdrucken) sehr zuverlässig. 7.10.16.3 PDF-Features PDF kann von einer Vielzahl von Layout- und Grafikprogrammen erzeugt werden; Dutzende von Tools ermöglichen die Herstellung von PDF aus den unterschiedlichsten Quellen. PDF-Dateien geben die Dokumente der Ursprungsprogramme einschließlich aller Schriften (auch nichteuropäische), Farben, Grafiken und Vektorgrafiken präzise wieder. Da PDF über effektive Komprimierungsmechanismen verfügt, sind PDF-Dateien meist deutlich kleiner als ihre Quelldateien. PDF-Dateien können beliebig viele Seiten Umfang haben, die maximale Seitengröße beträgt 4x4 Meter. Schriften und Vektorgrafiken können ohne Qualitätsverlust bis 6400 Prozent vergrößert werden. So finden auch extrem große Übersichten oder Pläne auf einer PDF-Seite den notwendigen Platz. Über die Textsuche im einzelnen Dokument oder die Volltextrecherche innerhalb einer PDFDokumentensammlung lassen sich sehr einfach Fundstellen auffinden. Textpassagen, Tabellen und Bilder aus PDF-Dokumenten können leicht in anderen Anwendungsprogrammen durch Kopieren und Einfügen der jeweiligen Elemente weiterverarbeitet werden. Es ist auch möglich, PDF-Dateien direkt zu bearbeiten, z. B. Texte zu ändern oder Grafiken zu verschieben. PDF ermöglicht die Anlage von Lesezeichen, mit deren Hilfe Anwendungen hierarchische Inhaltsverzeichnisse zur einfachen Navigation durch große Dokumente erzeugen können; ebenso gibt es die Möglichkeit, Links und Anker in PDF anzulegen. Schließlich

7.10 Archivierung als Bestandteil einer Sicherheitsstrategie

313

lassen sich in PDF auch Ton- und Filmdaten unterbringen sowie Formulare mit Skripting-Funktionen erstellen oder Kommentare „anheften“. Mittels des optionalen Dokumentenschutzes mit 40- oder 128-Bit-Verschlüsselung kann der Ersteller des Dokuments gezielt die Rechtevergabe des betreffenden Dokuments steuern. Er kann z. B. verhindern, dass Benutzer das Dokument abändern, ausdrucken oder Inhalte über die Zwischenablage kopieren können. PDF-Dateien können auch mit digitalen Signaturen „unterschrieben“ werden. PDF kann auch als Format zur verlustfreien Abspeicherung von einzelnen Grafiken verwendet werden, und zwar nicht nur von Pixelgrafiken, sondern wegen der Skalierbarkeit von Vektorgrafiken und Schriften auch als Alternative zu EPS und SVG. In der neuesten Version ermöglicht PDF als Tagged PDF die logische Strukturierung der abgespeicherten grafischen und Textinhalte auf eine ähnliche Weise, wie dies in XML geschieht, nämlich durch Tags. Tagged PDF ermöglicht so eine Erschließung der Inhalte, die über ihre rein grafische Repräsentation hinausgeht. Zum einen kann Tagged PDF dafür verwendet werden, die Inhalte je nach Ausgabegerät (Standardrechner, Handheld, Handy) anders zu formatieren, zum anderen können Inhalte besser durchsucht werden, und schließlich können sich Sehbehinderte Tagged PDF vorlesen lassen. Der letztere Punkt hat enorme Bedeutung, da seit 1998 in den USA gesetzlich vorgeschrieben ist, dass von Bundesbehörden veröffentlichte Inhalte auch für Behinderte voll zugänglich sein müssen (Accessibility Act).

7.10.16.4 PDF-Probleme PDF ist alles in allem eine extrem komplexe Technologie,was dazu führt,dass beim Austausch von PDF-Daten nicht immer bei allen Beteiligten und Ausgabegeräten das erwünschte Ergebnis zustande kommt. Schriften oder hochauflösende Grafiken müssen z. B. nicht zwingend in eine PDF-Datei eingebunden werden, sondern können auch lediglich referenziert werden, so dass die Datei von einem Rechner, auf dem die betreffende Schrift oder Grafik fehlt, nicht richtig dargestellt wird oder es bei der Druckausgabe zu Fehlern kommt.

7.10.16.5 PDF/X Diese Situation hat zu Bemühungen geführt, das PDF-Format wieder so weit einzuschränken, dass es für einen bestimmten Zweck zuverlässig nutzbar ist. Für die Druckvorstufe ist die ISO-Norm PDF/X (X für eXchange) eine solche Lösung. Neben dem Ausschluss von Ton-, Film- und Skripting-Komponenten sowie der Festlegung,dass alle benötigten Daten Bestandteil der PDF-Datei sein müssen,verlangt PDF/X die Einhaltung von Regeln bei Verarbeitungsanweisungen (Farbprofile, Bemaßung u.ä.). So kann man eine PDF-Datei auf PDF/X-Konformität prüfen und sichergehen, dass jeder andere, der PDF/X-konforme Software verwendet, auch das erwünschte Ergebnis erhält (Blind-Exchange-Fähigkeit).

314

7 Sicherheit

7.10.16.6 PDF/A PDF/A verfolgt das Ziel, den Aufbau und Inhalt von PDF-Daten so zu spezifizieren, dass sie die Ansprüche der Langzeitarchivierung erfüllen. Die US-amerikanischen Verbände „Association for Suppliers of Printing, Publishing and Converting Technologies (NPES)“ und die „Association for Information and Image Management International (AIIM International)“ arbeiten seit einigen Jahren auf dieses Ziel hin: Sie wollen mit PDF/A einen internationalen Standard für die digitale Archivierung von Schriftgut definieren. Wie schon oben erwähnt, soll PDF/A 2006 den Status einer ISO-Norm erhalten. Archive, Behörden und Verwaltungen sollen ebenso von diesem Standard profitieren wie Gerichte, Bibliotheken, Zeitungsverlage und Industrieunternehmen. PDF/A soll ein mehrseitiges Dokumentenformat definieren, das eine Mischung aus Texten, Bilddaten und Vektorgrafiken enthalten kann. Ebenso sollen die Eigenschaften und Fähigkeiten der Systeme definiert werden, die für das Lesen, Reproduzieren und die Volltextsuche verwendet werden. Ziel ist es sicherzustellen, dass PDF/A-Dateien alle zur Darstellung des Inhalts notwendigen Daten enthalten und dass diese Daten selbst wieder internationalen Standards entsprechen und unabhängig von Ausgabegeräten sind. Das trifft auch auf die Metadatenebene zu. PDF/A soll alle Metadaten enthalten können, die zur Beschreibung und Auswertung des Dokumentes notwendig sind. Dabei soll PDF/A noch konsequenter vorgehen als PDF/X. Eine Empfehlung für PDF als Format zur Langzeitarchivierung kann nur für die ISO-normierten Varianten PDF/X und das noch in Entwicklung befindliche PDF/A gegeben werden. PDF/X hat nicht primär die Langzeitarchivierung, sondern die Kompatibilität von Daten in der Druckvorstufe zum Ziel, die endgültige Form von PDF/A ist noch abzuwarten. Eine Empfehlung für diese PDF-Typen als Formate zur Langzeitarchivierung birgt zudem das Risiko in sich, dass die Einschränkung auf diese Sonderformen nicht hinreichend Beachtung findet.

8 ILM aus der Sicht der Anbieter

8.1

ILM und die Vollsortimenter

Als Vollsortimenter bezeichnen wir Hersteller im Speichermarkt, von denen über die notwendige Hardware auch die benötigte Software zur ILM-Implementierung komplett bezogen werden kann und die ILM als Marktstrategie aktiv betreiben. Diese Hersteller finden sich alle sowohl auf der Liste der führenden Hardware- als auch auf der der führenden Softwarehersteller wieder. So gehört EMC2 heute mit einem Jahresumsatz von über 600 Millionen US-Dollar allein im Softwareumfeld zu den Top Ten der Softwarehäuser weltweit. Dennoch sollen sie separat in diesem Abschnitt dargestellt werden, und nicht in dem Abschnitt über die Ansätze der Softwarehersteller, da sie in ihrem Softwareansatz klar ein gesamtes Produktportfolio adressieren. Diese Hersteller haben alle eine Gemeinsamkeit. Sie alle sind führende Mitglieder der SNIA und sind daher sehr früh in die Erkennung und Entwicklung der Trends im Speichermarkt involviert. Deshalb wird es nicht verwundern, wenn ihre Strategie bezüglich Information Lifecycle Management der Roadmap der SNIA folgt, die sie selbst massiv beeinflusst haben. Daher darf man hinsichtlich der ILM-Strategie keinerlei große Unterschiede zwischen diesen Unternehmen erwarten. In der Erreichung der SNIA-Standards greifen sie jedoch zu unterschiedlichen Methoden, die in den folgenden Abschnitten kurz angerissen werden sollen.

8.1.1

EMC2

EMC2 stellt wohl den Vollsortimenter mit dem komplettesten Produktportfolio im Speichermarkt dar: EMC2 ’s DMX-Speichersystemfamilie deckt die Klasse des Enterprise Speicher komplett ab. Die CLARiiON-Produktfamilie schließt nahtlos zur Abdeckung der Midrange-Klasse an. Die CENTERA CAS-Lösung ist eine gelungene Plattform zur Langzeitarchivierung von Daten. Außerdem bietet EMC2 einen vollständigen Softwareset mit ECC (EMC Control Center) zur Administration der SAN-Plattformen, und einen vollständigen – mit der Akquisition von Legato übernommenen – Softwarestack in Backup- und Restore-Lösungen an. Mit VMware wurde das führende Unternehmen in Virtualisierungstechnik übernommen, mit Documentum ein gewichtiges Marktmitglied

316

8 ILM aus der Sicht der Anbieter

im ECM-Markt aufgekauft. Mit diesen Lösungen lässt sich im ILM-Markt, dessen Standardisierung die SNIA für 2008 anstrebt, eine bedeutende Marktmacht einbringen. Die weitere Entwicklung der System Management Initiative (SMP) der SNIA trägt der Bedeutung des Themas Speicher für die IT dahingehend Rechnung, dass das Thema Sicherheit als nächster großer Schritt eingebunden und standardisiert werden soll. EMC2 hat mit der Übernahme von Network Intelligence und der Gründung der Security Division auch diesen Schritt bereits vorweggenommen. Hier zeigt sich eine der großen Stärken von EMC2 . Das Unternehmen hat sich langfristig dahingehend aufgestellt,jede Anforderung aus dem Speicherumfeld mit Produkten aus dem eigenen Produktportfolio befriedigen zu können. Sämtliche Unternehmensakquisitionen dienten der Stärkung des Portfolios. Problematisch könnte hier lediglich sein, die zahlreichen unterschiedlichen Entwicklungslinien zu einem einheitlichen Produktset zusammenzuführen. Dies dürfte für EMC2 die größte Herausforderung darstellen.

8.1.2

Hewlett-Packard inklusive TSG85

Hewlett-Packard (HP) ist eine der größten US-amerikanischen Technologiefirmen mit Sitz in Palo Alto (Kalifornien). Kein anderes IT-Unternehmen besitzt weltweit ein derart umfassendes Technologieangebot wie HP. Die Produktpalette reicht von stationären Desktops über Geräte für das mobile Arbeiten wie Notebooks und Handhelds bis zu Servern, Speicher- und Softwarelösungen. HP ist auch im Bereich der Softwaretechnik sehr erfolgreich. Dazu gehören Entwicklungen wie Desktop-Erweiterungen, Workflow-Lösungen und eine eigene Java Virtual Machine (JVM) für HP-UX. Auch im Outsourcing- und Servicegeschäft hat HP sich einen guten Namen erworben. Mit dem Geschäftsbereich HP OpenView stellt der Konzern Software insbesondere auch für UNIX- und Linux-Betriebssysteme her, mit der das Unternehmen vor allem in den Bereichen Systemüberwachung und -management eine führende Rolle einnimmt. Die Technology Solutions Group (TSG) ist für die Entwicklung und die Auslieferung der IT-Lösungen (Hardware, Software und Dienstleistungen) für Unternehmen sowie öffentliche Auftraggeber verantwortlich. Hewlett-Packard war eines der ersten Unternehmen der Speicherbranche, das sich mit dem Thema Information Lifecycle Management beschäftigte. Bereits 2003 wurde die ILM-Initiative angekündigt.86 Mit der XP- und der StorageWorksProduktfamilie bietet HP sämtliche Hardware zur Realisierung des Tiered-Speicher-Ansatzes. Dabei ist HP als OEM von Hitachi Data Systems mit der XP-Familie im Highend Bereich voll ausgestattet, die eigene StorageWorks-Produktfamilie skaliert ebenfalls von Midrange- bis Enterprise-Klasse.HP bietet zusätzlich Backup (Tape) und Archivierungssysteme (WORM, optische Medien) an. Gemeinsam mit den geschnürten Lösungspaketen Information Capture,Information Management, Information Retention und Information Delivery bietet HP die Lösung Application 85 86

Wikipedia, HP (www.hp.com), diverse Pressemitteilungen. Vgl. R. Marrone-Hurley, Nancy: Hewlett Packard – November 2003, HP Announces their ILM Initiative, aus ESG Business Brief, November 2003.

8.1 ILM und die Vollsortimenter

317

Solution zur anwendungsspezifischen Archivierung an (Email solutions, Medical solutions, Database solutions, Application Consolidation solutions, Enterprise Content Management solutions, Rich Media solutions). Hier kann HP aus seinem großen Beratertopf schöpfen, der beim businessrelevanten Servicegeschäft vorhanden ist. HP scheint den Managementausverkauf zu Beginn der 2000er Jahre überstanden zu haben und sich wieder einem seiner bereits früher tragenden Geschäftszweige, dem Speicherbereich, zu nähern. Anders als EMC2 entwickelt sich HP SNIA-konform nicht durch den Einkauf wesentlicher Geschäftszweige, sondern eher durch moderate Partnerschaften wie der mit Hitachi Data Systems.

8.1.3

IBM

IBM ist eines der ältesten IT-Unternehmen und zudem der weltweit größte Anbieter im Bereich Informationstechnik (Hardware (Mainframe, Server und Speicher), Software und Services). Mit einem Jahresumsatz von 46,2 Mrd. US-Dollar (2004) hat sich Global Technology Services in den letzten Jahren als wichtiger Bestandteil von IBM etabliert, in dem zusätzlich weit mehr als die Hälfte der Mitarbeiter ihr Tätigkeitsfeld finden. Neben dem Beratungszweig sind hauptsächlich in diesem Bereich die zahlreichen Serviceangebote angesiedelt. Ein Beispiel für mögliche Leistungen stellt der Bereich Strategic Outsourcing dar, der die teilweise oder komplette Übernahme von IT-Abteilungen anbietet. Betätigungsfelder von Global Technology Serivces sind im Einzelnen: • • • • •

e-business Hosting Services Integrated Technology Services IT Strategic Outsourcing Technical Support Services and Maintenance IT Management Consulting

Mehr noch als Hewlett-Packard setzt der weltweit größte Computerhersteller im Speicherumfeld auf Partnerschaften. So wird der Midrange-Bereich im Speichergeschäft (DS 4xxx-Familie) nahezu komplett durch Technologie von LSI Logic bestritten. Die DS6000- und DS8000-Speicherfamilien bieten Enterprise-Funktionalitäten und -Skalierung im IBM-Produktportfolio. SAN/NAS-Lösungen zur Implementierung von Tiered-Speicherarchitekturen, NAS-Lösungen zur Implementierung von Archivierungslösungen sowie Services zur Implementierung von ILM zum „Management des fluktuierenden Datenwerts“ werden angeboten.87 Auch IBM folgt der SNIA-Linie und kann mit Fug und Recht alsVollsortimenter bezeichnet werden.

87

Vgl. http://www-5.ibm.com/de/solutions/itsolutions/sol inform 2.html.

318

8 ILM aus der Sicht der Anbieter

8.1.4

Fujitsu Siemens Computers (FSC)

Fujitsu Siemens Computers setzt bei seinen Speicherlösungen voll auf Partnerprodukte. So hebt FSC als Vorteil seiner integrierten Speicherlösungen die „Bestin-Class-Produkte führender Hard- und Softwarehersteller“88 hervor. Im SANUmfeld wird die Produktpalette von EMC2 vermarktet und im NAS-Umfeld die von Network Appliance. Bei Magnetbändern besteht eine Partnerschaft mit ADIC und CAS wird mit EMC2 CENTERA abgedeckt. FSC orientiert sich in seiner ILM-Strategie an der der Partner und kann somit ein durch Beratung komplettiertes Vollportfolio anbieten.

8.1.5

Network Appliances (NetApp)

NetApp ist als Marktführer im NAS-Umfeld durch Partnerschaften und Eigenentwicklungen in SAN und Komplettlösungen gewachsen. So bietet NetApp heute mit der FAS-Familie vom Einsteigermodell bis zum Enterprise Speicher skalierende FC-Speichersysteme an. Im NAS-Markt ist NetApp natürlicherweise zu Hause. Zu sämtlichen führenden Backup-/Security-/ECM- und DMS-Herstellern bestehen Partnerschaften. Für ILM bietet NetApp mit dem IS1200 (Information Server) eine Appliance mit Stärken in der Content-sensitiven Klassifizierung und Analyse von Datenzugriffen und Suchen. Dieses erlaubt weitgehende Automatisierung von Policies zum Management unstrukturierter Daten. Hier werden nicht zugegriffene Daten indiziert, klassifiziert und suchbar gemacht. Die Zusatzfunktionen SnapSearch (Klassifizierung und Suche auch für Snapshot-Backups), Transparent Migration Manager (Automatisierung der Datenmigration in der Tiered-Storage-Umgebung) und Retention Manager (Erkennen von Inhalt zu Datenschutz und Compliance) runden das Komplettangebot von NetApp ab.

8.1.6

SUN Microsystems mit der ILM-Lösung IM389

SUN90 Computer hat als Produkte Server und Arbeitsplatzplatzrechner sowie im Softwarebereich Java und Solaris als Betriebssystem. SUN bietet neben dem eigenen UNIX-Derivat Solaris auch Java-VMs für Linux und Windows an. Andere Hersteller lassen ihre Java-VM für ihre Plattform zertifizieren,zum Beispiel die Firma Apple für Mac OS X. Im Mai 2005 übernahm SUN das Softwareunternehmen Tarantella.Tarantella war eine US-amerikanische Softwarefirma,die Software rund um den Secure Global Desktop entwickelte und verkaufte. Im April 2006 schloss SUN Deutschland die Übernahme von StorageTek (Speicher) ab. Während die meisten Speicher- und Infrastrukturhersteller das Thema Information Lifecycle Management mit Nachdruck verfolgen, geht SUN in der Öffentlichkeitsarbeit einen anderen Weg. Die Company, die mit der Übernahme von StorageTek den Erfinder von ILM übernommen hat und sich damit als Komplett88 90

http://www.fujitsu-siemens.de/products/storage/index.html. Wikipedia, SUN (www.sun.com), diverse Pressemitteilungen.

8.1 ILM und die Vollsortimenter

319

anbieter einschließlich Speicher auch in der Speicheroberklasse etablierte, kehrt zumindest im Marketing dem ILM-Modell den Rücken. SUN präsentierte kürzlich eine eigene Speicherstrategie, die auf einem Prozess namens Information Management Maturity Model (IM3) aufbaut, der von den IT-Verantwortlichen die absolute Durchführung von vier Schritten für alle Unternehmens-Daten fordert, die da sind: • Identity Built In: SUN bietet eine umfassende identitätsbasierte Managementlösung, um Daten auf andere Speicherressourcen im Verlauf ihres Lebenszyklus zu migrieren. Der SUN Java System Identity Manager steht für das UserProvisioning, die Synchronisierung von Identitätsdaten sowie für die Verwaltung der Identitätsprofile und Berechtigungen während des gesamten Lebenszyklus zur Verfügung. • Virtualization Built In: Mit der Virtualisierung können alte und neue Daten von Band über Capacity-Disk bis hin zu Datacenter-Disk in heterogenen Umgebungen als gemeinsame Ressourcen genutzt werden. • Security Embedded: Bei SUN gehört nun auch Sicherheit zur höchsten Priorität und ist in Form von Sicherheitsmechanismen bereits in die Systeme integriert. Dazu gehören das Identitätsmanagement sowie eine Verschlüsselung auf Geräteebene. SUN verfolgt hierbei die Strategie, alle Daten von ihrer Entstehung auf Applikationslevel bis hin zur Archivierung zu schützen. • Integrated-Data-Management-Plattform: Mit Hilfe des Betriebssystems Solaris 10 ermöglicht es SUN, die Daten durch eine einzige gemeinsame Plattform mit Policy-Modellen und Automatisierungen verfügbar und zugänglich zu machen. Die gemeinsame Plattformintegration soll die Komplexität und Abhängigkeiten verringern. Sie soll durch einen gemeinsamen Satz an Werkzeugen unterstützt werden und zudem auf einem offenen Standard basieren. Die eingesetzten Speicher werden natürlich Solaris als Betriebssystem verwenden. Mit den Projekten Honeycomb und Thumper zeigt SUN neue, teilweise revolutionäre Technologien, welche völlig neue Produktkategorien im Bereich der Speicherlösungen schaffen. Das Projekt Honeycomb verändert die Art, wie Anwendungen nach Daten suchen, auf diese zugreifen und sie abrufen. Das Projekt Thumper bietet Kunden, die nicht transaktionsbezogene oder missionskritische Daten speichern müssen, Lösungen für das schnelle Analysieren und Bearbeiten von Daten. James Whitemore, Vice President of Marketing der Data Management Group bei Sun, glaubt, dass der IM3-Ansatz besser als ILM geeignet sei, die Probleme der Anwender zu lösen. Aus seiner Sicht verdeckt ILM die Probleme nur, IM3 dagegen löse sie. Gleichwohl unterstützt SUN in Form eines IM3-Workshops seine Kunden, langfristig von ILM-Strategien zu profitieren. In einer „halbtägigen“ Veranstaltung hilft SUN seinen Kunden, mit Modellen, Auswertungen und Benchmarks die Stärken und Schwächen ihrer ILM-Strategien festzustellen. Aus Sicht der beiden Autoren bestätigt SUN, dass es zukünftig für die Unternehmen, d. h. sowohl für die Hersteller als auch die Anwender, immer wichtiger wird,eine ILM-Strategie zu entwickeln.Ob hierfür eine halbtägigeVeranstaltung in

320

8 ILM aus der Sicht der Anbieter

Form eines Workshops ausreicht, das bezweifeln die beiden Autoren.Auch bei ILM versuchen die Hersteller durch singuläre Lösungen, Märkte zu besetzen und hohe Hürden für einen Anbieterwechsel für die Anwender zu schaffen. Auch hier gilt, je geringer der Anwender in die eigene Planung eines ILM-Konzeptes investiert, desto größer wird seine Abhängigkeit von einzelnen Anbietern und desto höher wird der Preis in Zukunft, den er zahlen muss; sei es beim Einkauf – außer er hat eine besonders große Einkaufsmacht – , sei es bei einem notwendigen Anbieterwechsel, falls erforderliche IT Serviceprozesse nicht oder nur unzureichend unterstützt werden, oder bei der Durchführung eigener Ergänzungen zur Erreichung der notwendigen IT-Services für die unternehmenskritischen Geschäftsprozesse. Zudem bleibt der wichtige Aspekt des Sicherheitsmanagements (80 Prozent der Sicherheit) bisher nicht abgedeckt. Der Vorteil einer standardisierten Lösung liegt in der Schnelligkeit der Realisierung und in der Reduzierung des Risikos für den Anwender bei entsprechender Vertragsgestaltung mit SUN.

8.1.7

Hitachi Data Systems: Der gewachsene Vollsortimenter

Von allen bisher dargestellten Herstellern, die ein Information Lifecycle Management mit einer vollständigen Produktpalette für ein Tiered-Storage-Konzept wie dem unseren ermöglichen, unterscheidet sich Hitachi Data Systems (HDS) dadurch, dass seine Produkte technologisch fundiert aus der beständig erweiterten Produktpalette erarbeitet und in die Administrationsumgebung integriert wurden. Die Hitachi-Produktlinie ist organisch in den Markt gewachsen. Dabei orientierte sich Hitachi Data Systems von Anfang an nicht nur an den gängigen Hypes der Industrie und suchte nicht nur eine „me too“-Strategie zu entwickeln, sondern entwickelte konsequent seine Produkte entlang einer technologie- und marktorientierten Roadmap. Die Lightning-Produktfamilie wurde Anfang 2000 zielgerichtet mit neuer richtungsweisender interner Architektur (switched Backend über Crossbar Switch) im Enterprise-Segment auf den Markt gebracht. Nach dem Speicherinvestitionsstau um den Jahrtausendwechsel, hervorgerufen durch die Y2K-Furcht, mussten die Anwender ihre betagte Speicherumgebung konsolidieren. Dies war die Zeit des SAN-Wachstums in speicherintensiven GroßIT-Umgebungen. Hier war Hitachi Data Systems zum richtigen Zeitpunkt mit dem richtigen Produkt auf dem Markt. Die Thunder-Produktpalette rundete das Spektrum im Midrange-Segment ab. Mit dieser Produktpalette konnte seitens Hitachi Data Systems dem SAN-Markt der Stempel aufgedrückt werden, das Unternehmen konnte über mehrere Jahre Quartal für Quartal zweistellig wachsen. Gemeinsam mit der technisch kompletten Hardwareplattform wurde mit der HiCommand Software Suite ein Administrationsprodukt entwickelt, das sämtliche Komponenten in einem Hitachi-SAN administrieren konnte. Mit Präzisierung der SMI-S Speicher Management Standards der SNIA (Storage Networking Industry Association) wurde HiCommand dem SMI-S-Standard angepasst und konnte so standardkonforme heterogene Speichersysteme unterschiedlicher Hersteller in das HiCommand-Administrationsframework integrieren.

8.1 ILM und die Vollsortimenter

321

Bereits mit der Marktreife der Lightning- und Thunder-Produktfamilien wurde seitens Hitachi die Zielrichtung für die nächsten Jahre vorgegeben – die Speichervirtualisierung. Die Lightning- und Thunder–Familie hatte im Wesentlichen folgende Zielrichtung: • Optimale Konsolidierung und Pooling von Speicherresourcen • Implementierung unterbrechungsfreier Real-Time-Kopien für Backups und schnelles Disaster Recovery • Bereitstellung einer Plattform für Tiered-Storage-Umgebungen für Data Lifecycle Management und Compliance zu Aufbewahrungs- und Sicherheitsanforderungen91 • Bedienung über die gleichen Speichermanagementmechanismen Die beiden Produktfamilien Lightning und Thunder stellen für die angestrebte Speicherkonsolidierung sowie für die Implementierung einer Tiered-StorageUmgebung sämtliche benötigten Funktionalitäten zur Verfügung: • Durch unterbrechungsfreie Erweiterungen skalierbar bis 140 TB Kapazität • Multidimensionale Skalierbarkeit von Kapazität, Bandbreite, Cache, Connectivity, Auslastungs-Mix und Embedded Applications • Einführung von Speichervirtualisierungselementen • Benutzerdefinierte (automatisierbare) sowie Ad-hoc-Point-in-Time-Kopien zur Beschleunigung von Backups-/Restores und Optimierung der Business Continuity • Off-Site Redundanz mit vollständiger Datenintegrität • Multiprotokoll-Kompatibilität—Fibre Channel, FICON und ESCON • Unterstützung von DAS, SAN, NAS und iSCSI Anschlusstechnologien • Unterstützung von diversen RAID- und Laufwerkstypen • Kopiermechanismen zwischen den Produkten beider Familien Mit den Systemen der TagmaStore Universal Storage Plattform (USP) und dem „kleinen Bruder“, dem TagmaStore Network Storage Controller (NSC), wurde die Zielrichtung Speichervirtualisierung und Tiered-Storage-Implementierung auf eindrucksvolle Weise erreicht. Hier wird innerhalb der Speicherindustrie erstmalig ein applikationszentrierter Speicherarchitekturansatz gewählt, der Virtualisierung heterogener Speichertechnologien und -hersteller sowie die Zuordnung von Speicher zu unterschiedlichen Datenklassen für Anwendungen über eine zentrale Plattform ermöglicht. Dies führt zu deutlichen Leistungskennzahlen: • Die Performance ist mit bis zu 2 Millionen I/Os pro Sekunde bei einer aggregierten internen Bandbreite von 81 GByte/Sekunde über die interne Architektur des Universal Star NetworkTM Crossbar Switch beeindruckend • Virtualisierung von intern und extern angeschlossener Speicherkapazität

91

Vgl. http://www.hds.com/products services/storage systems/enterprise storage/.

322

8 ILM aus der Sicht der Anbieter

• Die TagmaStore Universal Storage Platform kann bis zu einer Gesamtkapazität von 32 PB skaliert werden. Darin sind bis zu 332 TB interner Speicher enthalten • Die Frontend-Direktoren bieten Anschlussmöglichkeiten von bis zu 192 FibreChannel-, 64 ESCON- oder 48 FICON- Ports, was die TagmaStore „Universal Storage Platform“ wirklich universell in Host- und Open-Systems-Umgebungen einsetzbar macht • Die logische Partitionierung von intern und extern angeschlossenen Speicherressourcen transportiert das Domänenkonzept aus der Mainframe-Umgebung in den Speicherbereich • Universelle Replikation über heterogene Speicherumgebungen • Aktives Workload Balancing und Performance Tuning • Durchgängiges Management-Framework der HiCommand Software • Hitachi-Software ermöglicht Virtualisierung (Hitachi Universal Volume Manager), Replikation (TrueCopy und ShadowImage), permanente und unterbrechungsfreie Datenmigration übergreifend über heterogene Speichersysteme • Garantierter und damit auch in SLA-Vereinbarungen einzubringender applikationsbezogener Quality of Service durch bis zu 32 Virtual Private Machines in der USP, die durch die Virtualisierungstechnologie gebildet werden. Diese können ebenfalls zur applikationsbezogenen Leistungsverrechnung der Speicherumgebung herangezogen werden • Durch die Universal Storage Platform ist eine echte Any-to-any-Datenreplikation realisierbar • Die TagmaStore Universal Storage Platform unterstützt damit in jeglicher Hinsicht den Tiered-Storage-Ansatz und ist eine komplette Architektur für das Information Lifecycle Management, wie wir es definiert haben Mit der„TagmaStore Universal Storage“ Plattform ist Hitachi Data Systems optimal gerüstet für eine Implementierung von Tiered Storage gemäß einer Datenklassifizierung, wie beispielsweise der von der IDC in der Data Classification Study empfohlenen 5-stufigen Klassifizierung. Diese untergliedert die Daten nach ihrer Bedeutung für das Unternehmen in: • Mission Critical Data (Erfolgskritische Daten) Mission Critical Daten sind die Daten des Unternehmens, die die häufigste Zugriffsrate sowie den größten Wert darstellen. Sie benötigen zur Speicherung die höchste Performance, die höchste Verfügbarkeit, nahezu keine geplanten/ungeplanten Ausfallzeiten und verursachen damit die höchsten Speicherungskosten. • Business Critical Data (Geschäftskritische Daten) Die IDC bezeichnet Daten als geschäftskritisch, wenn sie bei Erzeugung durchschnittlicher Speicherkosten von bedeutendem Wert für das Unternehmen sind, sowie gute Performance und Verfügbarkeit bei einer Wiederherstellzeit von maximal 8 Stunden benötigen. In unserem in Kapitel 3 dargestellten Projekt KONCOM/IT wurden diese beiden Klassen in die Verfügbarkeitsklassen 1–4 erweitert. Beide IDC-Klassen wurden

8.1 ILM und die Vollsortimenter

323

Abb. 8.1. TagmaStore Universal Speicher Platform – Partitionierung und virtuelle Speichersysteme

nochmals nach logischer und physikalischer Wiederherstellzeit untergliedert. Für das Beispielprojekt der EurAmFi AG haben wir sie jedoch zur Datenklasse 1 (hochverfügbare Speichersysteme) zusammengefügt. • Accessible Online Data Daten dieser Klasse sind charakterisiert durch Kostensensitivität, relativ geringe Zugriffsrate, Online-Datenzugriff, gute Datenverfügbarkeit mit Wiederherstellzeiten unter 8 Stunden. Die Daten sind sehr häufig unveränderbar (Fixed Content) und Compliance-relevant. • Nearline Data Diese Datenklasse beschreibt kostensensitive Massendaten mit geringer Zugriffswahrscheinlichkeit, akzeptierten Zugriffszeiten von bis zu einer Stunde mit automatisierten/automatisierbaren Zugriffsmechanismen. Die IDC-Klassen der Accessible Online Data und der Nearline Data wurden in unserem Beispielprojekt KONCOM/IT zur Datenklasse 2 (Nearline-Daten) zusammengefasst.

324

8 ILM aus der Sicht der Anbieter

• Offline Data Hierbei handelt es sich um archivierte Daten, die Backup- oder ComplianceRelevanz besitzen. Diese Daten sind extrem kostensensibel. Sie werden nur begrenzt genutzt. Zugriffszeiten von bis zu 72 Stunden werden akzeptiert. Diese IDC-Datenklasse wurde in KONCOM/IT zur Datenklasse 3. Auf den ersten Blick bietet die „Universal Storage Plattform“ von Hitachi Data Systems die geeigneten Hardwarelösungen für die Datenklassifizierung gemäß IDC, mit vielleicht der einzigen Ausnahme der Compliance relevanten Daten mit Fixed-Content. Dieses letzte Teil zur Komplettlösung wurde vom japanischen Speicherlösungsspezialisten mit der „Hitachi Content Archive Platform – HCAP“ geschlossen, auf die wir gleich eingehen wollen. Zuvor jedoch noch eine Bemerkung zu den dargestellten Datentypen und deren Unterstützung durch Hitachi: Hitachi Data Systems bietet nicht allein die Hardwareplattform für TieredStorage zuzüglich Datentypisierung als wesentlichen Schritt zu Information Lifecycle Management. Mit dem HiCommand Tiered Storage Manager stellt das Unternehmen auch die notwendige Managementunterstützung zur Implementierung der automatischen Migration Policies für die Migration der Daten auf die unterschiedlichen Speicher Tiers im Verlauf des Informationslebenszyklus bereit. Außerdem unterstützt Hitachi Data Systems hier nicht nur das „Tiering“ von Kapazitäten, sondern die Typisierung sämtlicher speicherrelevanter Infrastruktur.92 Hier seien insbesondere genannt: • • • •

Backup Services (Disk-to-Disk, virtuelles Magnetband, Disk-to-Tape) Speicheranschlusstechnologie (Fibre Channel, iSCSI, NAS, FICON, ECSON) Disaster Recovery Services (synchrone vs. asynchrone Remote-Kopien) Data Protection Service (Snapshots, lokale Spiegel)

Die Hitachi Content Archive Platform (HPAP) stellt ein aktives, webbasiertes und objektorientiertes Archivierungssystem mit Single-Cluster-Architektur ohne theoretisches Limit für die Anzahl der unterstützten Clustermemberknoten dar. Technische Basis von HCAP ist die „SAN plus Array of Independent Nodes (SAIN)“-Architektur. Diese hat folgende Bestandteile: • Ein Array unabhängiger Knoten in einem symmetrischen Cluster. Diese werden über Standard-Gateways angebunden und mit der Hitachi Content Archiver Software, basierend auf Archivas betrieben. • Die Backend-Infrastruktur eines Speichersystems (heute WMS 100, zukünftig komplette Hitachi-Produktpalette bis „Universal Storage Plattform“ mit externem Speicher), über die die archivierten Objekte RAID-Schutz genießen. Auf Basis dieser Architektur können sowohl Blöcke, Dateien als auch Fixed-Content-Objekte archiviert werden. Bei dem Content Addressing der Fixed-ContentObjekte geht Hitachi Data Systems nicht über proprietäre APIs wie C-Clips, sondern verfolgt einen „Content Aware“-Ansatz bei Verwendung von Standardproto92

Vgl. Merrill, David R.: Tiered Storage Economics, White Paper von Hitachi Data Systems, Sept. 2005.

8.1 ILM und die Vollsortimenter

325

Abb. 8.2. Hitachi Content Archive Platform und SAIN-Architektur

kollen zum Dateizugriff (NFS, CIFS, http, WebDAV). Dies verhindert die Nachteile der Standard-APIs wie Herstellerbindung, Zugriff auf die Daten lediglich über CDF-Referenz (Updates und Erweiterungen sind nur über Policies mit Neuerzeugung des kompletten Archivsatzes über die ursprüngliche Applikation möglich) oder keine volle Indizierung der Inhalte. Dem Argument, dass nur über diesen Weg eine gesetzeskonforme Archivierung von unveränderlichen Daten erreicht werden könne, begegnet HCAP mit der Verwendung von digitalen Signaturen zur Sicherstellung der Datenintegrität der Metadaten. Ferner sind auch für diese Architektur sämtliche Policies verfügbar,die in Band 1 „Grundlagen und Modelle des Information Lifecycle Management“, Kapitel 3 zu Compliance zu nationalen und internationalen Rechtsvorschriften hinsichtlich Archivierung dargestellt werden: • Retention Policies (Schutz vor Löschung vor Fristablauf) • Protection Policies (bis zu 4 Kopien zum Schutz vor Verlust der archivierten Daten) • Zugriffsschutz über definierte Unternehmensregeln • Authentizitäts-Policies für die Dokumente (wählbare Hash-Algorithmen, Schutz durch elektronische Signatur, die seitens HCAP periodisch neu berechnet und mit dem Original verglichen wird) • Shredding Policies (Sicherstellung, dass nach Löschung keine physikalische Wiederherstellbarkeit möglich ist)

326

8 ILM aus der Sicht der Anbieter

Abb. 8.3. LSI Logic: Silicon to Systems Innovation

Fazit: Mit HCAP hat Hitachi Data Systems den letzten fehlenden Baustein in ein überzeugendes Produktportfolio eingefügt, das das Unternehmen zum Vollsortimenter für die ILM-Implementierung gemäß diesem Buch macht. Die Autoren beeindruckt bei dem Ansatz vor allem, dass Hitachi nicht der Entwicklung des Speichermarktes durch schnellen Zukauf von Technologien begegnet.Hitachi Data Systems folgt der Roadmap des Marktes durch gezielte Erweiterung des Produktportfolios kombiniert mit der Integration in ein funktionierendes ManagementFramework. Dies wird durch Professional Services komplettiert, die hinsichtlich Implementierung von Tiered Storage,Archivierung und Information Lifecycle Management auch den größten Anforderungen gerecht werden können.

8.1.8

LSI Logic: Innovation mit Silicon-to-Systems

In den bisherigen Abschnitten haben wir eine Vielzahl von Herstellerlösungen dargestellt, die insgesamt alle ihre Marktführerschaft im Speichermarkt oder Teilen des Marktes hervorheben. Dennoch haben wir auch darauf hinweisen können, dass einige dieser Hersteller ihr Produktportfolio oder Teile daraus von Partnern fremdbeziehen und in ihre eigenen Lösungen einsetzen. Woher stammen diese Segmentprodukte, woher stammen die eingesetzten Technologien? Bei etwas intensiverer Suche wird man immer wieder auf LSI tref-

8.1 ILM und die Vollsortimenter

327

Tabelle 8.1. LSI Entry-Level Speichersysteme (1) Parameter

2822-SATA

2882-Speichersystem

Max. Cache I/O

70.000 I/O pro Sekunde

77.000 I/O pro Sekunde

Max. Sustained I/O (FC) (I/O-Dauerrate vom Speichermedium)

10.000 I/O pro Sekunde

25.000 I/O pro Sekunde (FC), 10.000 I/O pro Sekunde (SATA)

Max. Sustained Transfer (kontinuierliche Transferrate vom Speichermedium)

485 MB pro Sekunde

400 MB pro Sekunde (FC) 395 MB pro Sekunde (SATA)

Maximale Anzahl unterstützter Laufwerke

112 (SATA)

112 (FC oder SATA)

Maximale Kapazität (36 GB FC/15.000 rpm)

—

4,0 TB

Maximale Kapazität (73 GB FC/10.000 und 15.000 rpm)

—

8,2 TB

Maximale Kapazität (146 GB FC/10.000 rpm)

—

16,4 TB

Maximale Kapazität (250 GB SATA/7200 rpm)

28 TB

28,0 TB

Performancewerte

Kapazitätswerte

Host-/Laufwerkanschlüsse 2822-SATA: 4 × 2-Gbit/s FC- Host-/-SANVerbindungen 2822-SATA: 2 × Gbit/s FC–Laufwerkserweiterungsverbindungen

2882: 4 × 2 Gbit/s FC-Host-/-SAN-Verbindungen (FC-AL oder FC-SW) 2822: 2 × 2 Gbit/s FC-AL Laufwerkserweiterungsverbindungen

fen. Womit haben wir es bei LSI zu tun? Die Homepage der LSI Corporation in Deutschland gibt einen kurzen Überblick über das Unternehmen und seine Produkte. „Produkte der LSI Corporation verändern die Art und Weise, in der Menschen rund um den Globus Daten erstellen, speichern und konsumieren. Unsere für führende Technologieanbieter in den Speicher- und Consumer Märkten konzipierten „silicon-to-systems“-Lösungen ermöglichen diesen Unternehmen Design und Produktion einiger der modernsten und bekanntesten heute auf dem Markt erhältlichen Produkte. LSI entwickelt seit 25 Jahren innovative Technologien, die sich auf Leben und Arbeit der Menschen auswirken.Wir bieten dem Speicher-Markt ein unvergleichliches Leistungsspektrum und verfügen über ein tiefes und zugleich breit gefächertes Lösungsangebot – von spezialisierten Siliziumlösungen bis hin zu kompletten Systemen. LSI war aktiv an der Entwicklung und Vermarktung des weltweit ersten SCSI-Chips beteiligt, brachte als erster Anbieter SAS (Serial Attached SCSI) auf den

328

8 ILM aus der Sicht der Anbieter

Tabelle 8.2. LSI Entry-Level-Speichersysteme (2) Parameter

2822-SATA

2882-Speicher System

Unterstützte RAID-Level

0, 1, 3, 5 und 1 + 0

0, 1, 3, 5 und 1 + 0

Redundante und hotswappable Komponenten

Storage-Controller, Netzteile, Kühlventilatoren und Festplattenlaufwerke

Storage-Controller, Netzteile, Kühlventilatoren und Festplattenlaufwerke

Hot-Spare-Laufwerke

Globale Hot-Spares für automatische Erkennung und Wiederherstellung von/nach Laufwerkfehlern

Globale Hot-Spares für automatische Erkennung und Wiederherstellung von/nach Laufwerkfehlern

Cacheschutz

Akkupufferung des Cache

Gespiegelter, batteriegepufferter Cache

Weitere Features

—

Automatischer I/O-PfadFailover, Online-Administration, Konfigurationsdateien werden auf jedem konfigurierten Laufwerk gespeichert

Unterstützte Betriebssysteme

W2K, W2K3, Solaris, Linux, AIX, HP-UX, NetWare, IRIX

W2K, W2K3, Solaris, Linux, AIX, HP-UX, NetWare, IRIX

Failover-Unterstützung durch Serverhersteller

AIX, HP-UX, NetWare, IRIX

AIX, HP-UX, NetWare, IRIX

Verfügbarkeit

Konfiguration/Überwachung

Markt und war der Vorreiter bei der Einführung von 4 Gb/s Fibre Channel Speicher Arrays. LSI setzt Maßstäbe für Speicher-Technologie der Spitzenklasse. Für den Consumer Markt ermöglichen wir digitale Home Entertainment-Produkte wie DVD-Rekorder,tragbare Media-Player,Set-Top-Boxen (STB) und High-DefinitionVideo Produkte sowie auch Produkte für die professionelle Videoproduktion, Rundfunk und TV. Vor kurzem haben wir eine neue Applikationsprozessorarchitektur (ZEVIOTM ) für Anwendungen mit geringer Leistungsaufnahme vorgestellt. Auch in der Zukunft wird LSI auf Basis des umfangreichen technischen „Know Hows“ für weitere Innovationen im Markt sorgen.“93 Diese Präsentation zeigt auf, warum LSI sich als „Silicon to Systems Solution Provider“ und als „Enabler of Leading Technology Companies“ positioniert. Seit seiner Gründung vor nunmehr 26 Jahren ist LSI technologisch führend in Consumer-Elektronik und Speichertechnologie. Daher ist LSI in der Welt der Hersteller wohlbekannt.Jeder der im Speicherumfeld tätigen Hersteller,setzt Komponenten von LSI ein. So ist LSI zum Beispiel einer der größten Lieferanten für herstellerspezifische und Standardbausteine wie am Beispiel eines SAS (Serial Attached SCSI) „Custom Silicon“ dargestellt werden soll. 93

Homepage der LSI Logic Corporation in Deutschland, Über uns, http//:www.lsil.com/worldwide/lsi emea/ germany/index.html.

8.1 ILM und die Vollsortimenter

329

Abb. 8.4. SANtricity – Storage Manager

So setzen sowohl Hitachi als auch Seagate das LSI Custom Silicon zum Anschluss ihrer „small form-factor“ SAS-Magnetplatten ein.94 Hitachi und Seagate wiederum teilen sich nahezu brüderlich den mit Abstand größten Marktanteil des Festplattenmarktes. Jedes System der im Speichermarkt tätigen Hersteller verbaut Magnetplatten von Hitachi und/oder Seagate. Somit lässt sich sagen, dass kein Speichersystem auf dem Markt exisitiert, das nicht zumindest diese Teile von LSI enthält. Die Enterprise Strategy Group nennt folgende Schlüsselaspekte für LSIs „silicon-to-systems“-Portfolio im Speichersystemmarkt:95 Externe Speichersysteme: • Komplette Speichersysteme, skalierbar von 219 Gigabytes bis 112 Terabytes (also von Entry-Level-Systemen bis Enterprise-Storage-Systemen) • SATA- und FC-Magnetplatten • Anschluss via 4-Gbit/s-FC oder Infiniband • Software für Datenmanagement und -schutz 94

95

Vgl. Babineau, Brian: Enterprise Strategy Group – ESG (Hrsg.), Leverage, Storage, Innovation: The New LSI Logic in: Storage and Information Management Brief vom 8.07.2006, S. 2. Vgl. Babineau, Brian: Enterprise Strategy, a.a.O, S. 2.

330

8 ILM aus der Sicht der Anbieter

Host-Bus-Adapter, RAID-Adapter, Speicherprotokoll-Software • MegaRAID-Hardware-Adapter (Controller) • MegaRAID-Treibersoftware-Stacks für Server und CPU/IO-Boards • FC-, SATA-, SAS-Host-Bus-Adapter zum SAN-Anschluss Kundenspezifische und Standardkomponenten • Magnetplatteninterfaces für SATA, SCSI, FC und SAS (Serial Attached SCSI) • Switching- und I/O-Chips, Custom Silicon • SCSI- und SAS-Expander Betrachten wir zunächst die kompletten externen Speichersysteme, so liefert hier LSI eine komplette Speichersystemfamilie für Entry-Level-Ansprüche an Performance und Kapazität bis hin zum Enterprise Speicher mit höchsten Anforderungen an I/O-Performance, Throughput, lokaler und remote Spiegelung sowie einfacher Verwaltung. Bereits die Entry-Level-Systeme der LSI sind dazu geeignet, für Small- und Medium-Umgebungen komplette und compliant ILM-Tiered-Storage-Strukturen aufzubauen. Neben den oben geschilderten Speichersystem-Parametern zeichnen sich bereits die Entry-Level Systeme mit all den Features aus, die Tiered-Storagebasiertes ILM erfordert, wie: • Durchgängige SANtricity Speicher Manager Software für die komplette Produktfamilie mit diversen Replikationsoptionen sowie einer einheitlichen Funktionalität über sämtliche FC- und SATA-Speichersysteme. • Die LSI Always-On-Bereitschaft mit Online-Speichermanagement, redundanten und hot-swappable Komponenten und automatischem Pfad-Failover sichern eine hohe Datenverfügbarkeit (Business Continuity). • Die SanShareTM Speicherpartitionierung ist für Konsolidierungsprojekte, wie wir sie mit dem Beispielprojekt KONCOM/IT im dritten Kapitel dieses Buches beschrieben haben, sinnvoll zur Konsolidierung im 24x7-Betrieb einzusetzen. • Volume SnapshotTM kann zum zeitbezogenen Erstellen von Snapshots verwendet werden (vgl. Entscheidungstabelle zum Projekt KONCOM/IT). Die Snapshots sind kapazitätsarm und beschreibbar. • Die LSI HotScaleTM -Technologie ermöglicht die Online-Skalierung der Speichersysteme bis zur Maximalkapazität. Das „pay-as-you-grow“-Konzept ermöglicht die Skalierung in den tatsächlich benötigten Stufen. Upgrades und Konfigurationsänderungen garantieren LSI Datenintegrität. • Ab dem 2882-Speichersystem können zusätzlich mit Volume Copy aus SANtricity physikalische Kopien oder Klons von Volumes erzeugt und zur Steigerung der Business Continuity eingesetzt werden. Der Administrator kann die so erstellten und normalerweise beschreibbaren Kopien auch „nur lesbar“ halten und damit Revisonssicherheit herstellen. • Bereits beim 2882-Speichersystem kann mit RemoteVolume Mirror eine Disaster-Recovery-Umgebung aufgebaut werden, wie sie ansonsten lediglich in Enterprise-Storage-Umgebungen gefordert wird. Ein Wechsel vom synchronen

8.1 ILM und die Vollsortimenter

331

Tabelle 8.3. LSI Midrange-Speichersysteme (1) Parameter

3994-Speicher System

5884-Speicher System

Max. Cache I/O

120.000 I/O pro Sekunde

148.000 I/O pro Sekunde

Max. Sustained I/O (FC) (I/O-Dauerrate vom Speichermedium)

44.000 I/O pro Sekunde (FC-lesend), 9.000 I/O pro Sekunde (FC-schreibend)

53.200 I/O pro Sekunde (FC), 19.800 I/O pro Sekunde (SATA)

Max. Sustained Transfer (kontinuierliche Transferrate vom Speichermedium)

990 MB pro Sekunde (FClesend), 850 MB pro Sekunde (FC-schreibend)

795 MB pro Sekunde (FC) 780 MB pro Sekunde (SATA)

Performancewerte

zum asynchronen Spiegeln ist im laufenden Betrieb möglich. Es kann jederzeit unterbrochen und punktgenau wieder aufgesetzt werden. • Über SMI-S kann Managementsoftware von Drittanbietern wie beispielsweise Computer Associates, Hewlett-Packard oder Symantec die Arrays steuern und überwachen. • SANtricity verfügt über Benachrichtigungsfunktionen via E-Mail oder SNMP und kann so in diverse Management-Frameworks eingebunden werden. • Für die Steuerung in Microsoft-Welten stellt der Hersteller auf seiner Website kostenlos einen VDS/VSS-Provider zur Verfügung. Mit dem Speichersystem 5884 brachte LSI das erste Speichersystem mit der 4Gbit/s-Fibre-Channel-Connectivity auf den Markt. Dabei ist der Controller so kompatibel entwickelt, dass er Anschlüsse von 1-, 2- oder 4-Gbit/s Geschwindigkeit erkennt und automatisch unterstützt, so dass auch die bisherigen Investitionen in die langsamere Fibre-Channel-Technologie weiter genutzt werden können. Sämtliche neueren Speichersysteme, darunter das Speichersystem 3994 sowie die Highend-Systeme, die auf LSIs XBBTM -Architektur der sechsten Generation aufgebaut sind, unterstützen allesamt die 4-Gbit/s-Anschlusstechnologie. Zusätzlich zu den klassischen FC-AL- und FC-SW-SAN-Anbindungen liefert LSI mit dem Speichersystem 6498 ein für High-Performance-Umgebungen (HPC) und technische Computing-Umgebungen optimiertes System mit InfiniBand Interconnect für High Performance Fibre Channel und High Capacity SATA-Anforderungen aus. Das System 6498 ist mit 4x10-Gbit/s- Infiniband-Ports zum Anschluss von Servern sowie 8x4-Gbit/s-Laufwerkserweiterungsanschlüssen bestückt. Damit kann die 6498 bis zu 224 FC-Laufwerke mit einer maximalen Kapazität von 67,2 TB (mit 300-GB-FC-Festplatten) halten. Die maximale kontinuierliche Transferrate von bis zu 1.300 MB pro Sekunde (lesend) und 1.200 MB pro Sekunde (schreibend) bietet die ideale Plattform für technische Server-Cluster von 2 bis mehrere tausend Knoten und damit eine geeignete Plattform für den externen Speicher eines Enterprise Grid Computing. Die 2882- und 5884-Speichersysteme werden gegen Ende des Kalenderjahres 2006 aus dem Lieferprogramm genommen. Danach wird das komplette Produkt-

332

8 ILM aus der Sicht der Anbieter

Tabelle 8.4. LSI Midrange-Speichersysteme (2) Parameter

3994-Speichersystem

5884-Speichersystem

Maximale Anzahl unterstützter Laufwerke

112 (FC oder SATA), je Einschubgehäuse 16

224 (FC oder SATA)

Maximale Kapazität (36 GB FC/15.000 rpm)

—

8,1 TB

Maximale Kapazität (73 GB FC/10.000 und 15.000 rpm)

8,0 TB

16,4 TB

Maximale Kapazität (146 GB FC)

16,0 TB (15.000 rpm)

32,7 TB (10.000 rpm)

Maximale Kapazität (300 GB FC/15.000 rpm)

34,0 TB

—

Maximale Kapazität (250 GB SATA/7200 rpm)

—

56,0 TB

Maximale Kapazität (500 GB SATA)

56,0 TB

—

Kapazitätswerte

Host-/Laufwerkanschlüsse 3994: 8 × 4-Gbit/s FC-Host-/-SAN-Verbindungen (FC-AL oder FC-SW)

5484: 8 × 2-Gbit/s FC-Host-/-SAN-Verbindungen (FC-AL) oder 4 × 2 Gbit/s – FC-SW

3994: 4 × 4-Gbit/s FC-AL Laufwerkserweiterungsverbindungen

5484: 4 × 4-Gbit/s FC-AL Laufwerkserweiterungsverbindungen

Verfügbarkeit Unterstützte RAID-Level

0, 1, 3, 5 und 1 + 0

0, 1, 3, 5 und 1 + 0

Redundante und hotswappable Komponenten

Storage-Controller, Netzteile, Kühlventilatoren, Cache Akkus und Festplattenlaufwerke

Storage-Controller, Netzteile, Kühlventilatoren und Festplattenlaufwerke

portfolio der LSI im Speicherbereich vom Entry- bis zum Highend-System komplett auf der 4-Gbit-Technologie bestehen. Der bereits geschilderte „pay-as-you-grow“-Ansatz macht LSI zur besten Adresse, was Skalierbarkeit und Modularität anbelangt. Die drei Komponenten eines modularen skalierbaren Speichersystems von LSI • Controller-Modul, • Array-Modul und • Plattenmodul können entsprechend den unterschiedlichen Anforderungen an Performance und Kapazität skaliert werden. Jedes der Module ist voll fehlertolerant mit automatischem Pfad-Failover und redundanten und online tauschbaren Komponenten ausgestattet.

8.1 ILM und die Vollsortimenter

333

Tabelle 8.5. LSI Midrange-Speichersysteme (3) Parameter

3994-Speichersystem

5884-Speichersystem

Hot-Spare-Laufwerke

Globale Hot-Spares für automatische Erkennung und Wiederherstellung von/nach Laufwerkfehlern

Globale Hot-Spares für automatische Erkennung und Wiederherstellung von/nach Laufwerkfehlern

Cacheschutz

Gespiegelter, batteriegepufferter Cache

Gespiegelter, batteriegepufferter Cache

Weitere Features

Automatischer I/OPfad-Failover, OnlineAdministration, Konfigurationsdateien werden auf jedem konfigurierten Laufwerk gespeichert

Automatischer I/O-PfadFailover, Online Administration, Konfigurationsdateien werden auf jedem konfigurierten Laufwerk gespeichert

Unterstützte Betriebssysteme

W2K, W2K3, Solaris, Linux, AIX, HP-UX, NetWare, IRIX

W2K, W2K3, Solaris, Linux, AIX, HP-UX, NetWare, IRIX

Failover-Unterstützung durch Serverhersteller

AIX, HP-UX, NetWare, IRIX

AIX, HP-UX, NetWare, IRIX

Verfügbarkeit

Konfiguration/Überwachung

Im Controller-Modul wird die RAID-Firmware gehalten. Hier werden die Frontend- und Backend-SAN-Systemanschlüsse für Fibre-Channel- oder SATAPlatten bereitgestellt. Das Array-Modul enthält neben den Controllern und der RAID-Firmware des Controller-Moduls auch noch bis zu 14 Fibre-Channel- oder SATA-Plattenlaufwerke, so dass ein Array-Modul ein Einstiegsspeichersystem darstellt, das mit Kapazitätsexpansion durch Plattenmodule erweitert werden kann. Die Plattenmodule bestehen aus bis zu 16 Fibre-Channel (2- bzw. 4-Gbit/s) oder SATA-II Magnetplattenlaufwerken (3-Gbit/s),die dual-ported in redundanten Dual-Active-Loops angeschlossen werden, um die Verfügbarkeit auch bei einem Loop- oder Kabelfehler in einer der redundanten Loops sicherzustellen. Der Silicon-to-Systems-Ansatz der LSI Logic zeigt sich auch im Segment der LSI-externen Speichersysteme insofern, als diese über OEM-Partner vertrieben werden. Die wesentlichen Partner für die Speichersysteme sollen im Folgenden kurz dargestellt werden. 8.1.8.1 IBM IBM bietet mit der DS4000-Speichersystemfamilie (ehemals FAStT) eine vom Entry Level bis zum Enterprise Speicher skalierbare Speicherlösung, basierend auf der Technologie von LSI, an. Dabei wird seitens IBM den Systemen lediglich die globale Service- und Supportorganisation von IBM sowie die Produktvalidierung

334

8 ILM aus der Sicht der Anbieter

Tabelle 8.6. LSI Highend-Enterprise-Speichersysteme (1) Parameter

6994-Speichersystem

6998-Speichersystem

Max. Cache I/O

375.000 I/O pro Sekunde

575.000 I/O pro Sekunde

Max. Sustained I/O (FC) (I/O-Dauerrate vom Speichermedium)

62.000 I/O pro Sekunde (FC)

56.000 I/O pro Sekunde (FC)

Max. Sustained Transfer (kontinuierliche Transferrate vom Speichermedium)

1.240 MB pro Sekunde (FC)

1.600 MB pro Sekunde (FC)

Maximale Anzahl unterstützter Laufwerke

224 (FC oder SATA)

224 (FC oder SATA)

Maximale Kapazität (73 GB FC/10.000 und 15.000 rpm)

16,4 TB

16,4 TB

Maximale Kapazität (146 GB FC)

32,7 TB

32,7 TB

Maximale Kapazität (300 GB FC/15.000 rpm)

67,2 TB

67,2 TB

Maximale (500 GB SATA)

112,0 TB

112,0 TB

Performancewerte

Kapazitätswerte

Kapazität

Host-/Laufwerkanschlüsse 6994: 8 × 4-Gbit/s FC-Host-/-SAN-Verbindungen (FC-AL oder FC-SW) 6994: 8 × 4-Gbit/s FC-AL-Laufwerkserweiterungsverbindungen

6998: 8 × 4-Gbit/s FC-Host-/-SAN-Verbindungen (FC-AL oder FC-SW) 6998: 8 × 4-Gbit/s FC-AL-Laufwerkserweiterungsverbindungen

Verfügbarkeit Unterstützte RAID-Level

0, 1, 3, 5 und 1 + 0

0, 1, 3, 5 und 1 + 0

gegen die IBM xSeries und pSeries sowie weitere Unix- und Intel-basierte Serverplattformen hinzugefügt, die Speichertechnologie ist rein die von LSI. 8.1.8.2 SUN/StorageTek SUN/StorageTek gründet seine eigene ILM-Strategie skalierbarer Speicherlösungen von Entry Level Direct Attached Speicher (DAS, Inline-Speicher) bis zu Enterprise-SAN-Lösungen auf den Speichersystemen der FlexLine 200/300-Produktfamilie.Diese sind OEM-Lösungen der LSI-Produktfamilien,mit der SUN/StorageTek seine ILM-Ansätze unterstützt hinsichtlich • substanzieller Reduktion geplanter und ungeplanter Applikations-Ausfallzeiten,

8.1 ILM und die Vollsortimenter

335

Tabelle 8.7. LSI Highend-Enterprise-Speichersysteme (2) Parameter

6994-Speichersystem

6998-Speichersystem

Redundante und hotswappable Komponenten

Speicher-Controller, Netzteile, Kühlventilatoren, Cache-Akkus und Festplattenlaufwerke

Speicher-Controller, Netzteile, Kühlventilatoren und Festplattenlaufwerke

Hot-Spare-Laufwerke

Globale Hot-Spares für automatische Erkennung und Wiederherstellung von/nach Laufwerkfehlern

Globale Hot-Spares für automatische Erkennung und Wiederherstellung von/nach Laufwerkfehlern

Cacheschutz

Gespiegelter, batteriegepufferter Cache

Gespiegelter, batteriegepufferter Cache

Weitere Features

Automatischer I/O-PfadFailover, Online-Administration, Konfigurationsdateien werden auf jedem konfigurierten Laufwerk gespeichert

Automatischer I/O-PfadFailover, Online-Administration, Konfigurationsdateien werden auf jedem konfigurierten Laufwerk gespeichert

Unterstützte Betriebssysteme

W2K, W2K3, Solaris, Linux, AIX, HP-UX, NetWare, IRIX

W2K, W2K3, Solaris, Linux, AIX, HP-UX, NetWare, IRIX

Failover-Unterstützung durch Serverhersteller

AIX, HP-UX, NetWare, IRIX

AIX, HP-UX, NetWare, IRIX

Verfügbarkeit

Konfiguration/Überwachung

• besserer Ausnutzung der Kapazität des vorhandenen physikalischen Speichers und • substanzieller Reduktion direkter und indirekter Speicherkosten zur Reduktion der Total Cost of Ownership (TCO). 8.1.8.3 CRAY Der Supercomputerhersteller CRAY bietet seinen Kunden Speichersystemlösungen für höchste Ansprüche an Performance, Verfügbarkeit und Kapazität basierend auf LSI-Systemen. Die Supercomputer XD1, XT3 und X1E von Cray stellen für die auf den Massenmarkt zielenden Marktteilnehmer im Speichermarkt selten angebundene Systeme dar, so dass hier CRAY mit der LSI-Technologie preisgünstige Alternativen zu den klassischen Marktteilnehmern bereitstellen kann. Die Speichersystemfamilie von CRAY bietet • Integration sämtlicher CRAY-Supercomputer sowie Betreuung durch CRAYs weltweite Customer-Support-Organisation, • Hard- und Softwarekompatibilität über sämtliche CRAY-Produktfamilien und damit Reduktion von Trainingskosten und Gewährleistung der Upgrade-Pfade durch CRAY und

336

8 ILM aus der Sicht der Anbieter

• Flexibilität durch die Nutzung von SAN- und Direct-Attached–Speicherkonfigurationen sowie die Unterstützung diverser – sonst nur selten unterstützter – Filesysteme wie Lustre, XFS und StorNext FS. 8.1.8.4 TERADATA (NCR) TERADATA (NCR) bietet eine komplette Speichersystemfamilie, basierend auf LSITechnologie, speziell für Data-Warehousing-Lösungen an. Diese haben im Einsatz von Data Warehouses vor allem die folgenden Vorteile: • Integration in TERADATAs Parallel-Database-Technologie, deren Datenzugriffs- und -verwaltungswerkzeuge und robuste Data-Mining-Möglichkeiten. Dadurch kann auch auf die Data Warehouse Consultants von TERADATA bzgl. der optimalen Speichernutzung zugegriffen werden. • Für TERADATAs Data-Warehousing-Umgebung optimierte 2 Gb Quad Modular Disk Arrays mit Unterstützung höherer Performance und größerer Distanzen zwischen Server- und Speichersystem. 8.1.8.5 Silicon Graphics (SGI) Die SAN-Server und Total-Performance-Familie von Speichersystemen der Silicon Graphics (SGI) basieren ebenfalls auf der LSI-Produktfamilie. Diese Systeme sind optimiert für eine High-Performance-Computing-(HPC-)Umgebung. Dazu bieten sie: • den simultanen Zugriff auf die gleiche Datei von unterschiedlichen Betriebssystemen im SAN über das CXFS-Filesystem sowie • die Unterstützung von IRIX FailSafe in Hochverfügbarkeits-Cluster-Anwendungen. 8.1.8.6 Verari Systems Ebenfalls für hochperformante Cluster- und Enterprise-Computing-Umgebungen ist die Speicherfamilie von Verari Systems ausgelegt, die auch komplett auf LSITechnologie beruht. Die VS-Speichersysteme sind die Basis für Veraris SAN-, NAS- und Shared-Filesystem-Lösungen. Verari-Speichersysteme werden hauptsächlich in den anforderungsreichen Branchen Energieversorgung, Neue Medien/ Entertainment, Wissenschaft, Finanzdienstleistungen und in der öffentlichen Verwaltung eingesetzt. 8.1.8.7 Linux Networks Linux Networks ST-Speichersystemfamilie liefert in Verbindung mit dem General Parallel File System (GPFS) von Linux Networx oder CFS Lustre zuverlässige Performancewerte in produktionsorientierten Supercomputerumgebungen.

8.1 ILM und die Vollsortimenter

337

8.1.8.8 MaXXan MaXXan bietet mit der SVT100 Appliance in Verbindung mit LSI-Speichersystemen eine komplette virtuelle Tape-Library. Hier wird die Speichertechnologie von LSI für die Sicherung der hochverfügbaren Daten der Datenklasse 1 aus den ersten Phasen des Informationslebenszyklus verwendet.Die virtuelle Tape-Library • reduziert die Betriebskosten durch Nutzung von (günstigem SATA) Plattenplatz zur Emulation mehrerer Tape-Libraries und Tape-Laufwerke, • ermöglicht Backup- und Restorezeiten, die bis um den Faktor 10 schneller sind als die von klassischen Magnetband-basierten Sicherungssystemen und • ermöglicht höhere Verfügbarkeiten der gesicherten Informationen durch Vermeidung von Bandfehlern, mechanischen und Bedienerfehlern beim Umgang mit Magnetbändern. 8.1.8.9 SEPATON Die S2100-ES2 Virtual Tape Appliance von SEPATON verwendet eine industrieweit einzigartige Tape-Emulationstechnologie und ein Filesystem, die gemeinsam SEPATONs ReadyRestore-Anwendung auf LSI-Speichersystemen realisieren. Diese Anwendung ermöglicht synthetische Vollsicherungen, Content-basierte Datenkompression sowie ein Remote-Site-Backup mit industrieweit ungeschlagener Performance und Skalierbarkeit. LSI entwickelt in dem Segment der Interconnectivity für verschiedene Hersteller Hard- und Software wie Host-Bus-Adapter, RAID-Adapter und Protokollsoftware für Speichersystemkomponenten. LSI bietet diesen Herstellern interne und externe SCSI-, Fibre-Channel- und SAS-Interconnections sowie SCSI- und SAS-Expander für busbasiertes I/O-Balancing und Reichweitenverlängerung. Mit dem für Hersteller verfügbaren Software Developer Kit können diese ihre Systeme einfach in die LSI-Speicherumgebung einbinden. Die MegaRAID-Hardwareadapter und Softwarestacks ermöglichen Anbietern von Serversystemen und Motherboards den einfachen Anschluss von SCSI-, SATAund SAS-internen und -externen Speichergeräten für performancekritische Anwendungen. Die iMegaRAID-Kits ermöglichen die Erstellung von iSCSI-Appliances,ferner liefert LSI Fibre-Channel-,SAS- und SCSI-HBAs,die über ein gemeinsames Treibermodell verfügen, so dass die Topologie beliebig ohne Änderungen der Betriebssystemtreiber gewählt werden kann. Aus Sicht unseres Themas Information Lifecycle Management bietet LSI sämtliche Hard- und Software, die für ein dem ILM zugrunde liegendes Tiered-SpeicherKonzept benötigt wird. Interessant ist jedoch auch, dass LSI weitere Lösungen anzubieten hat, die auch im Rahmen eines über den Tiered-Storage-Ansatz hinausgehenden Engagements im ILM von Interesse sind. Diese Lösungen werden – auch hier getreu dem Silicon-to-Systems-Ansatz – nur über OEMs vertrieben und dienen diesen lediglich als eine Unterstützung dafür, Komplettlösungen mit LSIEquipment zu erstellen.

338

8 ILM aus der Sicht der Anbieter

So wird ein Lösungsportfolio zur Business Continuance angeboten, das dynamischen Datenschutz und Prozesse zur Wiederherstellung der Daten bei jedweder ungeplanten Unterbrechung des Betriebes verspricht. Voraussetzung für die Gewährleistung der Business Continuance ist, dass ein Business-Continuance-Plan existiert, der die benötigten Disaster-Recovery-Prozesse beschreibt. Grundlage des Business-Continuance-Plans ist die Klassifizierung der Daten hinsichtlich ihrer Geschäftskritikalität. Die unterschiedliche Geschäftskritikalität der Daten bedingt unterschiedliche Wiederherstellzeiten und unterschiedlichen geplanten Datenverlust, wie wir im Abschnitt über Datenklassifizierung bei der Definition der Verfügbarkeitsklassen bereits erwähnt haben (vgl. Abschnitt 6.2.1.9 dieses Buches). Das Business-Continuity-Portfolio von LSI trägt diesem Rechnung und bietet folgende Eigenschaften: • Sicherstellung des Datenschutzes durch Off-Site-Kopie der Daten außerhalb des Metro-Bereiches oder lokal innerhalb des Metro-Bereiches. • Bereitstellung des Wiederherstellungsprozesses für Daten und Applikationen. • Dynamischer Wechsel von asynchroner zu synchroner Replikation der Daten je nach Anwendungsanforderung. Dynamischer Wechsel der DatenreplikationsPolicies bei Anwendungsänderungen oder -unterbrechungen. • Streamlining von Backups in ein remote Tape-Backup-System. • Best Fitting von synchroner und asynchroner Spiegelung, Snapshot und Volume Copy zur Implementierung des Business-Continuity-Plans. Dabei auch dynamischer Start/Stopp-Prozess für das Mirroring für geplante und bei ungeplanten Unterbrechungen des Mirroring (suspend/resume-Operationen). Das Lösungsportfolio zu Backup und Recovery versucht die geschäftsbezogenen Problematiken von Backup- und Recovery-Operationen zu lösen oder die geschäftlichen Einflüsse zu minimieren. Dabei handelt es sich im Wesentlichen um Folgende: • Einflüsse auf die Anwendungsverfügbarkeit. In Backup-/Recovery-Operationen werden die Anwendungen entweder gar nicht (Offline- Backup/Restore) oder mit geringerer Performance verfügbar gehalten. Dadurch geht Applikationsproduktivität verloren. • Jede Recovery-Operation verhindert insbesondere für Mission-Critical- oder geschäftskritische Anwendungen den zeitkonformen Zugriff auf die Anwendungsdaten. • Probleme mit der Zuverlässigkeit undVollständigkeit der Datensicherung.Sehr häufig kann nicht gewährleistet werden, dass die vorhandenen Datensicherungen für ein vollständiges Recovery der Anwendungsdaten ausreichen. • Die Komplexität der Backup/Recovery-Verwaltung erfordert zumindest beim Speichermedium Magnetband langwierige und fehleranfällige manuelle Intervention. Das Backup/Recovery-Lösungsportfolio kombiniert die Replikations-Funktionalitäten der SANtricity-Management-Software (bspw. Snaphots) mit dem Einsatz

8.1 ILM und die Vollsortimenter

339

von SATA-Speichersystemen und Zusatzfunktionalitäten von OEMs und bietet so folgende Vorteile: • Hohe Anwendungsverfügbarkeit durch Weiterführung der Produktion der Anwendung während des Backups. Durch die Einführung von Snapshots wird das Backup-Fenster auf nahezu 0 reduziert. Dies führt zu konsistenteren und vorhersehbaren Backup-Zyklen. • Schnelle Wiederherstellung von Informationen durch Restore von Platte, nicht von Band. Schnelles inkrementelles Recovery, geringere Anzahl von RedoLogfiles, signifikant schnellere Wiederherstellung von SATA-Platten führen zu konsistenteren und vorhersehbaren Wiederherstellzeiten. • Höhere Zuverlässigkeit der Backups durch die Möglichkeit, eine Vielzahl schneller Snapshot-Backups zu erzeugen. Dadurch wird auch die Gefahr nicht gesicherter offener Dateien minimiert. Das Backup/Recovery-Medium SATAPlatte sorgt für den Wegfall mechanischer Fehler beim Handling mit Bändern, hat eine zusätzliche Schutzebene durch die eingebaute Redundanz und sorgt damit für Vertrauen in die Wiederherstellbarkeit der Daten aus dem Backup. • Leichteres und kostengünstigeres Management von Backup-Operationen durch die Reduktion der Komplexität und Eliminierung manueller Operationen. Ferner wird die gesamte Speicherumgebung mit einem Werkzeug administriert. Die existierende Sicherungssoftware kann weiter verwendet werden, benötigt jedoch keine zusätzlichen Client-Lizenzen. Als letztes Lösungspaket sollen die Lösungen zum E-Mail-Management aufgeführt werden. Mit der LSI-Lösung automatisierter Replication Express for Microsoft Exchange 2003 Lösung werden die Probleme des immensen Wachstums des Speicherbedarfs für E-Mails, die unterschiedlichen Formate, in denen E-Mails gespeichert werden, um Disk Quotas und Speicher-Policies der Unternehmen zur Begrenzung des Wachstums zu unterlaufen, sowie die regulatorischen Anforderungen zur Compliance (vgl. Kapitel 1 dieses Buches) adressiert. Mit diesem Produkt- und Lösungsportfolio ist LSI als Vollsortimenter für die Implementierung von ILM-Lösungen gemäß den Klassifizierungen unseres Buches zu bezeichnen. LSI hat sich mit seiner Marktstrategie, sich als „Silicon to Systems Solution Provider“ und als „Enabler of Leading Technology Companies“ zu positionieren, einen bedeutsamen Namen als Technologieführer gemacht, der im Speichermarkt Innovation, Standardisierung und Reaktion auf Anforderungen des Marktes und seiner Partner vorantreibt, was den Silicon-to-Systems-Ansatz von LSI ausmacht. Diese Technologieführerschaft soll letztendlich noch am Beispiel der Implementierung der SAS-Technologie auf dem Markt dargestellt werden. Basierend auf der Serverplattform Dual-Core Intel Xeon bietet LSI SAS-Komponenten für mehr als 100 Servermodelle. Allein hiermit positioniert sich LSI als Marktführer im Segment von Serial-Attached-SCSI-Speichergeräten. Die bisherigen Generationen des SCSI-Protokolls arbeiten mit parallelem Datenverkehr. Vom SCSI-1-Standard von 1981–1986 mit Übertragungsraten von 1,5 bis 5 MB/s bis zum aktuellsten parallelen SCSI-Standard Ultra640 SCSI (2003–

340

8 ILM aus der Sicht der Anbieter

Abb. 8.5. SAS – skalierbare Topologie und Kaskadierung

2004) mit bis zu 640 MB/s Übertragungsrate stieg die Problematik des parallelen Datenverkehrs (sämtliche parallel zu übertragenden Bits werden am Sendergerät synchronisiert), das Misalignment der am Empfänger angelieferten Daten aufgrund von Übertragungsinterferenzen auf dem Kabel. Das SAS-Protokoll ermöglicht eine Point-to-Point-Verbindung zwischen Sender und Empfänger, eliminiert die Laufzeitdifferenzen der Signale, verhindert Interferenzen auf dem Kabel und erlaubt so eine größere Datenübertragungsrate. SAS stellt das Replacement für Parallel SCSI dar, gewährleistet jedoch – wie beim SCSI-Standard üblich – die Softwarekompatibilität. Die SAS-Point-to-Point Star-Topologie stellt sicher, dass jedes angeschlossene SAS- (oder auch SATA-) Gerät die komplette Übertragungsbandbreite (derzeit 3 Gbit/s) bei minimalem Arbitration-Overhead erhält. SAS unterstützt das Dual-Porting von SAS-Devices, bietet jedoch auch den nativen Support für singleported-SATA-Geräte. Je Domäne können bis zu 16.000 Geräte angeschlossen werden. SAS-Konnektoren werden im Infiniband-Stil (SAS 4x Connector) oder dem iPass-Stil von Molex (Mini SAS 4x Connector) angeboten. Durch die Mini SAS 4x Connectors werden die Connectivity und die Packaging-Dichte stark erweitert. Bis zu 160 SAS-Links sind auf einem Schrankplatz von einer Höheneinheit verbaubar. Außerdem treibt SAS die Entwicklung von Small-FormFactor-(SFF-)Komponenten voran. Dies hat folgende wesentliche Vorteile:

8.1 ILM und die Vollsortimenter

341

Abb. 8.6. SAS-Switched Fabric

Der Small Form Factor erhöht die Rack-Auslastung (Bestückungsdichte) • Der zurzeit vorhandene Rack-Platz und Cabinet-Platz kann zur Skalierung und Expansion verwendet werden, wenn SFF-Devices eingesetzt werden • SFF stellt für Blade-Systeme den idealen Form Factor dar Reduktion des Energieverbrauchs durch SFF-Magnetplattenlaufwerke • Reduktion der Energiekosten • IT-Wachstumspotenzial ohne zusätzliche Stromversorgungskosten • IT-Wachstumspotenzial ohne zusätzliche Anforderungen an Kühlung und sonstige Sekundär- und Tertiärtechniken Größere Performance zu niedrigerem Preis • Reduktion des Kapitalbedarfs für zukünftige Speichererweiterungen • Geringere TCO aufgrund gemeinsam genutzter Infrastruktur • Größerer Investitionsschutz durch gesteigerte Paketierungsdichte (RAID 5 oder 6 auf einer Höheneinheit) und verbesserte Zuverlässigkeit von Festplatten (durch geringere Übertragungsfehler und Dual-Porting) Durch SAS-Switches können – wie im SAN üblich – eine Vielzahl von Servern auf mehrere unabhängige Speichergeräte (JBODs oder RAID-Speichersysteme) zugreifen. Der SAS-Switch erlaubt ebenfalls die gemeinsame Nutzung (Sharing) und die Bevorratung (Pooling) von Speicherplatz. Dies ermöglicht die Nutzung

342

8 ILM aus der Sicht der Anbieter

Tabelle 8.8. Fabric-Vergleich FC und SAS Parameter

FC-4-Gbit/s

SAS–3-Gbit/s

Verbindungen

Mehrere 1.000

Mehrere 100

Reichweite

10 Kilometer

100 Meter

Transmission

Verlustfrei

Verlustfrei

Switch

Buffered

Unbuffered

Fabric Management

Komplex

Einfach

Infrastruktur

Update-Zyklus 30–40 Monate

Update-Zyklus 30–40 Monate

Native Drive Connect

Ja

Ja

Kosten

Infrastrukturbereitstellung, initiale Kosten hoch

“Pay as you grow“

Throughput

4-Gbit/s

12-Gbit/s

Leistungsbewertung

Höchste Verfügbarkeit, höchste Zuverlässigkeit, längste Distanzen, beste Connectivity

Höchste Performance, moderate Kosten, günstige Skalierbarkeit, verwendet Commodity-Komponenten

weniger und größerer Speichersysteme, wodurch Sicherung und Aktualisierung der Umgebung optimiert werden. Vergleicht man die Fabric-Eigenschaften von SAS zu Fibre-Channel, so stellt SAS eine kostengünstige Alternative gerade für ILM-Anwendungen zumindest der Nearline-Datenklassen (Datenklasse 2 gemäß unserer Notation im Buch) dar. Die hier wiedergegebenen Informationen zu Serial Attached SCSI wurden dem Vortrag„SAS: Changing the Storage Market“ entlehnt,der vom Präsidenten der SCSI Trade Association (STA) – Harry Mason – auf der Storage Networking World – Europe (SNW) der SNIA im September 2006 gehalten wurde. In diesem Vortrag wurde aus Sicht der STA die marktbeherrschende Bedeutung von SAS für den zukünftigen Speichermarkt dargestellt. Dass LSI in diesem Markt wiederum keine geringe Bedeutung hat, mag aus der Tatsache geschlossen werden, dass jener Harry Mason hauptberuflich Direktor Industriemarketing von LSI ist. Die Bedeutung von LSI für die Standardisierung auf dem Speichermarkt zeigt sich auch darin, dass mehrere der Referenten der diesjährigen SNW von LSI gestellt wurden. LSI-Speichersysteme wurden bereits 2004 seitens der SNIA als SMI-S-Hersteller zertifiziert und dies gerade einmal ein halbes Jahr nach der endgültigen Definition des Standards. Die Autoren sind der Überzeugung, dass der „Silicon-to-System-Innovation“Ansatz LSI zu einer industrieweit einzigartigen Produktpalette über die komplette Wertschöpfungskette des Speichermarktes geführt hat. LSIs Verpflichtung zu Standards und die Nähe zu seinen Kunden und deren Anforderungen machen das Unternehmen zu einem bedeutenden Marktteilnehmer, wenn es allein um die verkauften Stückzahlen und Erträge geht. Betrachtet man

8.2 Interessante Spezialisten

343

jedoch, wer die innovativen Zyklen des Marktes mit seinen Produkten bestimmt, so qualifiziert sich LSI mit seiner innovativen Vergangenheit eindeutig zum technologischen Marktführer, der nach Ansicht der Autoren vor einer endgültigen Investitionsentscheidung in Zukunftstechnologien zu Rate gezogen werden sollte.

8.2 8.2.1

Interessante Spezialisten Softwarelösungen

8.2.1.1 ECM-Lösungen Die Problematik der Zuordnung von Daten zu einer Speicherstufe bei der Implementierung von ILM-Modellen liegt – wie wir bereits in Kapitel 7 dieses Buches dargestellt haben – in der Klassifizierung unstrukturierter Daten. Gemäß dem AIIM-Modell des Enterprise Content Management stellt ECM hier Komponenten und Technologien zur Verfügung, um die Lösung dieser Problematik zu unterstützen. Die Komponenten • • • • •

Erfassung (Capture), Verwaltung (Manage), Speicherung (Store), Ausgabe (Deliver) und Bewahrung (Preserve)

werden ganz oder in Teilen von ECM-Softwarelösungen und zum Teil auch von Dokumentenmanagementsystemen dargeboten. Enterprise Content Management bietet Raum für eine Abhandlung in Buchform – dies wollen wir hier nicht tun. Was wir bei der Betrachtung aus Sicht des Information Lifecycle Management tun können,ist,ECM-Software hinsichtlich der Module und Services zu betrachten,die für unseren Zweck von Bedeutung sind. Von den klassischen Anwendungsfeldern für ECM • • • • • • •

Dokumentenmanagement, Digitales Asset Management, Collaboration, Compliance- und Message-Management, Web-Content-Management, Business-Process-Management und Workflow sowie Records-Management

sind für uns im Wesentlichen die Verfahren zur Automatisierung des RecordsManagement (Archivierungssysteme) und Compliance- und Message-Managements (E-Mail-Archivierung, Compliance-Systeme) relevant. Die Analyse der am Markt angebotenen Lösungen zeigt, dass längst nicht alles automatisiert und vielleicht auch nicht automatisierbar ist, was zu ILM gehört. Tatsächlich scheinen die Zeiten noch fern, in denen ein kontextsensitives System

344

8 ILM aus der Sicht der Anbieter

die Inhalte einer Mail oder einer Datei erahnt und daraus treffend schließt, wie das betreffende Material aufzubewahren ist. Hier sind nach wie vor die Manager außerhalb des IT-Departments gefordert, die klar ansagen müssen, welchen Arten von Daten sie hohe Priorität zubilligen und welchen nicht. Mit den derzeit existierenden Produkten lassen sich höchstens einzelne Anwendungen durchautomatisieren. Unabhängig vom Terminus haben alle Prozesse der Speicherung von Information eines gemeinsam, dass durch sie der Nutzer in die Lage versetzt wird, sich mit seinen Daten und seinen Geschäftsprozessen detailliert auseinanderzusetzen. Nur dadurch kann er den Wert der Informationen für einzelne Abteilungen, Abläufe und das gesamte Unternehmen erkennen. Basierend darauf lassen sich die Daten in einer mehrstufigen Speicherumgebung sichern und mit Automatismen sowie manuell bewegen, archivieren oder vernichten. „Nur wer seine Daten kennt und deren Wert für Prozesse und Geschäft,kann sie entsprechend sichern oder gar löschen. Regelwerke lassen sich auch nur bei Daten anwenden, die sinnvoll gekennzeichnet sind“, so EMC2 -Manager Kotro. „Mit dem Verständnis für Informationen wächst dann auch das Verständnis für ILM. Einige Technologien lassen bereits eine automatische Klassifizierung zu. Diese war bislang für heutige Anforderungen eher unzureichend und oberflächlich. Erst eine neue Generation an Software wird hier Abhilfe schaffen.“ Bei den aktiven Daten ist ein fortschrittliches ILM besonders wichtig, wird mit diesen doch mehr oder weniger täglich gearbeitet. Ein ILM-Tool zur Verwaltung von aktiven Daten ist das IBM „SAN File System“. Dieses erlaubt nicht nur Speicherklassen verschiedener Service Levels zu definieren, sondern auch Files, basierend auf vorher festgelegten Policies, einem bestimmten Medium zuzuordnen, und zwar gleich bei der Erzeugung. Eine spätere Migration auf Tape ist über die Anbindung an TSM möglich. Der Aufbau eines Tiered Storage lässt sich laut IBM durch den „SAN Volume Controller“ vereinfachen. Das Tool ermöglicht unterbrechungsfrei Änderungen der Infrastruktur, verwaltet zentral auch heterogene Landschaften und stellt zum Host hin ein homogen erscheinendes Umfeld dar. Der Vorteil der von IBM angebotenen Lösungen besteht unter anderem darin, dass sie sich in vorhandene Infrastrukturen einbetten lassen.„Ein effizientes ILM aufzubauen heißt nicht, sämtliche Hardware gegen neue auszutauschen“, erläutert der IBM-Manager Scheefer. „Vielmehr sollen intelligente Software-Produkte den vorhandenen Ressourcen neues Leben einhauchen.“ Eine ILM-Integration umfasst neben der Planungsphase, dem Identifizieren und Abschätzen von Trends sowie der eigentlichen Datenklassifizierung, auch die Definition von Policies und die intelligente Verwaltung von aktiven und inaktiven Daten. „Die am Ende dieses Prozesses stehende Infrastrukturlösung ermöglicht, anders als in der Vergangenheit, nicht das Managen von Speicher, sondern vielmehr das Verwalten von Daten“, konstatiert Scheefer.96 Speicherhersteller wie EMC2 haben das Problem der Datenbewertung auch erkannt. Neben optimiertem Management ging es dem Anbieter auch darum, die 40 96

IBM, Pressemitteilung, www.ibm.com.

8.2 Interessante Spezialisten

345

Prozent Zeitaufwand zu verringern, die statistisch gesehen jeder Mitarbeiter aufbringt,um Informationen zu finden.Hier soll die neu entwickelte Plattform„EMC2 Documentum Content Intelligent Services“ (CIS) Abhilfe schaffen. Dabei klassifiziert die Software die Unternehmensdaten nicht nur, sondern automatisiert diesen Prozess durch Metadaten-Funktionalitäten einer neuen Generation. Der Content lässt sich somit auf Basis spezieller Informationen und Geschäftsregeln klassifizieren und für eine optimierte Navigation kategorisieren. In verschiedenen Sprachen kann der Administrator das Klassifizieren manuell vornehmen oder ganz einfach zum automatischen Vorgang wechseln. Das neue und hervorstechende Leistungsmerkmal des verteilten Kompetenzmanagements ermöglicht den Anwendern, die Kompetenz der Mitarbeiter in unterschiedlichen Funktionen zu nutzen, indem der Content über verschiedene Abteilungen zur Klassifizierung verteilt wird. Eine eingebaute Funktion und die Benutzeroberfläche ermöglicht es den Themenverantwortlichen, den Content in den Fällen zu klassifizieren, in denen der automatische Prozess keine eindeutige Klassifizierung vornehmen konnte. Die Themenverantwortlichen können die Klassifikationen somit weiter verbessern und unternehmenseigene Taxonomien entwickeln. Somit wird vermieden, dass der Kunde zurückschreckt, wenn er die Klassifizierung einem komplett automatisierten System übergeben soll. Paradebeispiel für die Automatisierung im Rahmen von ILM sind E-Mails. Hewlett-Packard zum Beispiel verweist anlässlich der ILM-Diskussion immer wieder auf sein Produkt „RIM for Messaging“ (Reference Information Management) für „Lotus“ und „Exchange“ – nunmehr ergänzt um die Lösung „RIM for Databases“, die durch den Aufkauf des Datenbankanalyse-Spezialisten Outerbay möglich wurde. Seit neuestem gibt es auch „RIM for Files“ für digitalen Content. Die RIMLösungen basieren auf „RISS“ (Reference Information Storage System) und dieses wiederum auf so genannten Storage-Cells, in denen HP die Grundbestandteile automatisierter, verteilter Speichersysteme der Zukunft sieht. IBM setzt ebenfalls auf das Produktpatchwork Tivolis für Dokumentenmanagement und -archivierung und „Content Manager“ für E-Mails, SAP und Datenbanken in Verbindung mit SAN, dem Filesystem „SAN FS“, dem WORM-Diskbasierten Content-Speicher sowie dem „Tivoli Storage Manager“, um eine Lösung zu realisieren, bei der Mails oder Daten regelgerecht archiviert werden. Bei der Einschätzung, welche Daten wohin migriert werden sollten, kann „Total Storage Productivity Center for Data“ helfen. Das System durchsucht heterogene Subsysteme auf ihre Inhalte und zeigt zum Beispiel an, welche File-Arten vorhanden sind und wie oft auf welche Daten zugegriffen wird. Inhalte registriert es jedoch nicht. ILM-Lösungen für E-Mail-Archivierung hat auch Computer Associates (CA) im Programm. Sie basieren zu einem Gutteil auf Ilumin. In den USA ist Ilumin Marktführer bei den Firmen, die unter Börsenaufsicht stehen. Ilumins Archivierungssoftware überwacht mit einem „Compliance Monitor“ E-Mails nach regelbasierten Kriterien und liefert die Ergebnisse an den Compliance-Manager, eine Funktion, die es vorläufig in kaum einem deutschen Unternehmen geben dürfte. CA plant zudem eine Software, die eine produktneutrale Ablage für Exchangeund Lotus-Mails in einem zentralen Repository bietet.Anwender sollen von außen

346

8 ILM aus der Sicht der Anbieter

auf die Mails auch dann zugreifen können, wenn sie die Applikation gerade nicht nutzen. Das Produkt soll mit bisher vorhandenen Content-Speicher-Produkten integriert werden und optional auch Module beispielsweise für die Speicherung von Instant-Messaging integrieren. Für das Ressourcenmanagement von Files setzt CA auf den OEM-Partner Arkivio. Beim hierarchischen Speichermanagement ist der Hersteller mit Caminosoft ebenfalls über ein OEM-Agreement verbunden. Symantec bietet Unternehmen eine enge Integration zwischen Sicherheitsanwendungen wie Virenschutz und Intrusion-Detection, Backup und der MailArchivierung mittels „Enterprise Vault“. Mit „IM Logic“ steht ein Produkt zur Verfügung, das für Instant-Messaging Ähnliches leistet wie „Enterprise Vault“ für Mails. „ILM ist heute noch sehr auf Speicher zentriert“, so Wedlich, Solution Marketing Manager Speicher EMEA bei Symantec. Dabei gebe es Anwendungen wie Sicherheit oder Workflow, die man sinnvollerweise an ILM-Anwendungen andocken könne und auch solle. „Beispielsweise wollen viele Kunden Chargebacks für Datenbewegungen“, sagt Wedlich und weist darauf hin, dass sein Unternehmen mit „Command Central Storage“ eine entsprechende Applikation im Programm hat, die man mit den oben genannten Lösungen verbinden kann.97 Inzwischen gibt es immerhin einige Ansätze für applikationsübergreifendes Daten- und Informationsmanagement. EMC2 teilt ILM in drei Stadien auf. Bei Fujitsu-Siemens setzt man hier hardwareseitig besonders auf das VTL-Produkt „CentricStore“,das Multi-Tier-Storage und schnelle Archivierung ermöglicht.Auch CA nähert sich mit Record-Managementspezialisten MDY dem ILM-Ideal. Die MDY-Software wird als zusätzliche Schicht über das E-Mail-Archivierungssystem, das Dokumentenmanagement oder den Sharepoint-Server gelegt und integriert dann alle Datenquellen unter einheitlichen Regeln, was Aufbewahrungszeiten und Verwaltung der Daten angeht. 8.2.1.2 Tool zur Unterstützung der Klassifizierung Die Analysten der Aberdeen Group stellen derzeit einen Trend in den Unternehmen zum Aufbau von„Information-Value“-Teams fest,die sich mit allen Fragen des Datenmanagements beschäftigen, Rollen und Verantwortlichkeiten zuordnen und eine Art Business-Plan erstellen für den Umgang mit den Informationen, die das Unternehmen produziert.Aberdeen erwartet,dass in diesem Jahr Klassifizierungsprogramme auf den Markt kommen werden, die eine intuitive Benutzeroberfläche, einen Katalog und ein Wörterbuch für die Metadaten sowie vordefinierte Policies enthalten. Erst wenn diese Werkzeuge verfügbar sind, so Aberdeen, könnten die Unternehmen „zuversichtlich und proaktiv“ ihr Datenmanagement planen.

97

Symantec, Pressemitteilung, www.symantec.com.

8.2 Interessante Spezialisten

347

8.2.1.3 Symantec – der Vollsortimenter im Softwarebereich Wenn wir EMC2 als Vollsortimenter bezeichnet haben, der als Hardwarehersteller über den Zukauf von Unternehmen der Roadmap der SNIA folgt, so kann dies bei den klassischen Softwareunternehmen von Symantec ebenfalls behauptet werden. Lediglich in der Entwicklungsrichtung unterscheidet sich Symantec im Softwarebereich von EMC2 . Während EMC2 als letzten Schritt die Standardisierung der SNIA im Sicherheitsbereich nachvollzogen hat, entwickelt sich Symantec als weltweit führendes Unternehmen in IT-Security vom Server hinein in das Speichernetzwerk.Mit der Übernahme vonVERITAS hat Symantec erheblichen Marktanteil in der SMI-konformen Speicherverwaltung und im Business-Continuity-Umfeld gewonnen. Heute bietet Symantec jedem etablierten Hersteller bei der Verwaltung heterogener Speicherlandschaften Paroli und dürfte auch den Standardisierungsprozess der SNIA im Security-Umfeld stark beeinflussen.

8.2.2

Brocade – dateibasiertes Information Lifecycle Management (ILM) auf Basis des File Area Networking (FAN)

8.2.2.1 File Lifecycle Management Brocade verfolgt einen ILM-Ansatz, der sich mit dem Lifecycle Management von dateibasierten Daten befasst, die immerhin bis zu 80 Prozent der vorhandenen Unternehmensdaten ausmachen. Speziell für diesen Bereich hat Brocade – Marktführer im Bereich SAN-Infrastruktur – im Jahr 2006 eine ganze Produktpalette unter der Dachmarke „Tapestry“ vorgestellt, die auch Lösungen für das „File Lifecycle Management“ umfasst. Brocades Definition des Information Lifecycle Management orientiert sich an der Basis dieses Konzepts: Alle Dateien, angefangen von ihrer Erstellung bis hin zur Archivierung oder Löschung, unterliegen unterschiedlichen Bedingungen. Diese Bedingungen hängen von Faktoren wie beispielsweise Zugriffshäufigkeit, Dateialter, Zugehörigkeit zu Applikationen und Abteilungen oder auch rechtlichen Aufbewahrungspflichten ab. Entsprechend diesen Faktoren werden die Daten klassifiziert und nach einem zuvor definierten Schema auf unterschiedliche Speichersysteme herstellerunabhängig abgelegt. Die jeweiligen Speichersysteme entsprechen den Datenklassifizierungen und sind dementsprechend leistungsfähig, kostenintensiv beziehungsweise günstig. Anstatt wertvollen und teuren Online-Speicher für Dateien einzusetzen, die seit langer Zeit nicht mehr genutzt werden oder keine entsprechende andere Wertigkeit aufweisen, sollten Dateien mit geringerem Wert automatisiert auf kostengünstigere Speichersysteme migriert werden. Schlussendlich ist es das Ziel, den Return of Investment (ROI) der gesamten Speicherumgebung möglichst hoch zu halten, die Kosten zu senken und den Administrationsaufwand zu minimieren. Nebenbei werden durch das ILM-Prinzip auch oft die Backup-Kosten reduziert, was ein zusätzliches Einsparungspotenzial darstellt.

348

8 ILM aus der Sicht der Anbieter

Wie beschrieben, legt Brocade seinen Schwerpunkt im Bereich des Information Lifecycle Management auf die Speicherung und Verwaltung von dateibasierten Daten. Die Tapestry-Produktfamilie bietet ein umfangreiches Softwareund Serviceportfolio für die Implementierung kompletter Global-NamespaceKonzepte, die neben zahlreichen Datenmanagement-Funktionalitäten, auf die weiter unten noch eingegangen werden wird, Information Lifecycle Management im Dateiumfeld erst möglich machen. Darüber hinaus ist Brocade eine der treibenden Kräfte für das File Area Networking (FAN), das die Grundlage für ILM- und Virtualisierungsstrategien im Dateiumfeld darstellt. 8.2.2.2 FAN ist die Basis für ILM Die Ausgangslage und damit auch der Grund, warum ILM im Dateiumfeld einen ganzheitlichen Lösungsansatz erfordert, ist die Tatsache, dass sich, trotz der Schwierigkeiten bei Betrieb und Verwaltung, unterschiedliche Dateispeichersysteme dauerhaft in Unternehmen etabliert haben. Eine integrierte Lösung für das Management und die Betriebsprozesse gab es bis heute nicht. Es ist nach wie vor nicht ungewöhnlich, mit einem Datenmigrations-Tool zu arbeiten, bei dem noch 25 manuelle Arbeitsschritte nötig sind oder beispielsweise für einen Replikationsjob 15 einzelne Aktionen durch einen Administrator ausgeführt werden müssen. Für das Ressourcenmanagement braucht man ein drittes und für die Archivierung ein viertes Produkt. Eine Wiederherstellung nach einem Totalausfall ist zu komplex und zu zeitaufwendig. Es gibt noch viele andere typische Probleme in diesem Kontext, die durch derartig fragmentierte Ansätze nicht gelöst werden können.Die Grundlage für ein erfolgreiches Lifecycle Management von Dateidaten ist eine einheitliche, umfassende Lösung für ein durchgängiges Management der Dateispeicherumgebungen unterschiedlicher Hersteller. Um dateibasierte Daten konsolidiert betrachten und gemäß ILM organisieren und verwalten zu können, bietet sich daher das Konzept des File Area Networking an. File Area Networking ist ein systematischer Ansatz, dateibasierte Technologien und Daten in Unternehmen zu organisieren. FAN stellt eine skalierbare und intelligente Plattform für die Verwaltung von Informationen in Unternehmen dar. Das FAN-Konzept bietet die Möglichkeit der unternehmensweiten Kontrolle über alle Dateiinformationen sowie das Management auf Basis von Metadaten und Inhalten auf allen gängigen Plattformen. Hiermit stellt das FAN-Konzept eine der ersten Produktlösungen dar, die bei der komplexesten Form der Datentypisierung, wie wir sie in Kapitel 6 beschrieben haben, den Unternehmen Unterstützung zur Typisierung nach Metadaten und Content bietet. FAN erlaubt es, den kontrollierten Zugriff auf Dateien entsprechend den Anforderungen im Unternehmen zu garantieren (ILM), unabhängig davon, auf welchen physikalischen Systemen die Daten abgelegt sind. Das unterbrechungsfreie und durchgängige Verschieben von dateibasierten Daten über alle unternehmensweiten Speichersysteme hinweg ist die Basis für einen reibungslosen Einsatz, ohne den Tagesablauf in einem Unternehmen unterbrechen zu müssen. Darüber hinaus bietet FAN echte ManagementServices über die gesamte Infrastruktur hinweg, unabhängig von applikations-

8.2 Interessante Spezialisten

349

Abb. 8.7. Brocades File Lifecycle Manager (FLM) im File Area Network

spezifischen Speicherlösungen oder der eingesetzten Technologie (SAN oder NAS). File Area Networking (FAN) kann daher die Grundlage für ein transparentes und regelbasiertes Information Lifecycle Management von Dateibeständen darstellen. File Area Networking basiert auf sechs Kernelementen: Erstens auf der Speicherinfrastruktur,die entweder auf einem SAN oder einem NAS beruht.Das zweite Kernelement sind die File Serving Devices. Sie müssen auf Standardprotokollen wie CIFS oder NFS basieren. Die dritte Komponente sind die Namespaces, die durch einen virtualisierten Namensraum, vergleichbar dem DNS im Internet, die Organisation, den Zugriff und die Speicherung der Daten ermöglichen. Sie bilden den Kern jedes „FAN“. Die vierte Instanz sind die File-Managementund Kontrollservices. Sie ermöglichen eine Vielzahl an Funktionalitäten und Lösungen, in denen das große Einsparungspotenzial eines FAN liegt. Beispiele für solche Services sind die Migration, Replikation, Klassifizierung, Zugriffsrechte, Wide Area File Services und viele andere Dienste. Das fünfte Element bei File Area Networking sind die Clients. Sie greifen im FAN über die Namespaces auf die Dateien zu, unabhängig von der Plattform. Die letzte und sechste Komponente ist die Connectivity, die über das LAN ebenso wie über Wide-Area-Technologien erfolgen kann und somit auch die Einbindung von Dateien ermöglicht, die in Remoteoder Branch-Offices abgelegt sind. Information Lifecycle Management im dateibasierten Umfeld kann also mit Hilfe des File Area Networking realisiert werden. Der erste Schritt in diesem Pro-

350

8 ILM aus der Sicht der Anbieter

zess ist die Datenkonsolidierung und Klassifizierung. Denn nur wenn alle im Unternehmen vorhandenen Daten erfasst und bewertet sind,kann eine ILM-Strategie geplant und implementiert werden. 8.2.2.3 Einfache, regelbasierte Datenhaltung in Prozessen Dank des integrierten Ansatzes zum heterogenen Datenmanagement,hilft Brocade Tapestry den IT-Abteilungen, erhöhten Nutzen aus ihrer bestehenden Infrastruktur zu ziehen. Die ILM Solution Tapestry File Lifecycle Manager (FLM) ist das Kernprodukt in Brocades FLM-Ansatz. FLM ist eine Software, die auf Strategien, Methoden und Anwendungen basiert, um Dateien automatisiert entsprechend ihrem Wert und ihrer Nutzung optimal auf dem jeweils kostengünstigsten Speichermedium in Network-Appliance-Umgebungen bereitzustellen. Durch den File Lifecycle Manager werden Dateien langfristig entsprechend ihren geschäftlichen Anforderungen sowie technologisch sinnvoll und sicher aufbewahrt. FLM ist eine Dateimanagementlösung, basierend auf Regeln (Policies), die Datenverlagerungen zwischen High-Cost- und Low-Cost-Speicher automatisiert übernehmen und somit einen wichtigen Teil der Information Lifecycle Management Strategie darstellen. FLM bewegt Dateien in Abhängigkeit von Attributen oder Zugriffsmustern. Dabei hält es die Daten für den Anwender zu jeder Zeit verfügbar. Administratoren wird durch FLM die Möglichkeit geboten, Dateien zu analysieren, zu klassifizieren, zu bewegen, zu verlagern und zu organisieren. Dies geschieht in Abhängigkeit von den geschäftlichen Prioritäten. Durch den Einsatz von FLM können Unternehmen eine deutliche Senkung der Dateispeicherkosten erwarten, zum einen durch geringeren Ausbau der teuren Primärspeichersysteme,zum anderen durch Reduzierung der Kosten bei Datensicherungen. 8.2.2.4 Global Namespace und File Lifecycle Management Tapestry FLM kann auch bereits in Umgebungen eingesetzt werden, die noch nicht über ein Global-Namespace-Konzept verwaltet werden. Durch die Implementierung eines Global Namespace über die gesamte Dateiumgebung lässt sich aber ein wirkliches FAN-Konzept umsetzen und so noch wesentlich weiter gehende Grundlagen für einen umfassenden FLM-Ansatz schaffen. So erlaubt die File Management Suite Tapestry StorageX über den Global Namespace die komplette Verwaltung heterogener Dateispeicherumgebungen durch die logische Vereinigung verteilter Dateispeicher im Unternehmen. Durch richtlinienbasierte Automatisierung wird das IT-Personal bei täglichen Verwaltungsaufgaben entlastet. Datenmigrationen werden nun über Herstellergrenzen hinweg ausgeführt. Standortübergreifende Replikationen werden zur automatisierten Routine. Failover für Anwender und Clientsysteme, Priorisierung und Klassifizierung von Dateien, Disk-to-DiskArchivierung, Kapazitätsplanung und Reporting sind die wichtigsten Einsatzszenarien. Entscheidend jedoch ist die erhöhte Effizienz. Denn ab sofort gibt es keine Auszeiten mehr für Anwender aufgrund von Speicherausfällen, und der Aufwand

8.2 Interessante Spezialisten

351

für Administratoren wird erheblich minimiert, so dass Ressourcen für andere ITAufgaben freigehalten werden. File Area Networking ermöglicht somit die generelle, massive Vereinfachung des gesamten Dateispeichermanagements und kann damit die Grundlage für einen umfassenden Ansatz beim File Lifecycle Management bieten. Es ermöglicht eine kompakte und zentrale Verwaltung von vernetzten Dateispeichersystemen und erlaubt Speicheradministratoren, Windows- und Unix-Server sowie Network Appliance Filer zu konsolidieren, zu migrieren, zu ergänzen und umzuschalten (Failover). Entscheidend ist, dass diese Aufgaben automatisiert mittels Richtlinien (Policies) ausgeführt werden können, ohne jegliche Ausfallzeit für die Anwender. Damit sind wesentliche Schritte für das Information Lifecycle Management erfüllt. Darüber hinaus bietet die Global-Namespace-Lösung Tapestry StorageX auch spezifische Anwendungsvorteile für das File Lifecycle Management: Speicheradministratoren sind mit SpeicherX in der Lage, das Problem der Datenklassifizierung für die Umsetzung einer ILM-Strategie zu lösen. Tapestry SpeicherX gruppiert Daten. Es erstellt Reports über alle Datenbestände und klassifiziert die Daten nach Wichtigkeit im Unternehmen wie beispielsweise nach Abteilung, Standort, Projekt, Nutzergruppe, Alter, Größe, Zugriffshäufigkeit oder letztes Zugriffsdatum. Die Benutzer und Administratoren profitieren vom transparenten Zugriff, denn Tapestry SpeicherX erstellt eine einheitliche Sicht auf die Daten, die über verschiedene Plattformen im gesamten Unternehmen verteilt sind. Tapestry File Lifecycle Manager übernimmt in diesem Rahmen die eigentlichen FLM-Aufgaben, das heißt die über definierte Regeln automatisierteVerschiebung von Dateien zwischen High-Cost- und Low-Cost-Plattformen. Und zwar so, dass Anwender weiterhin komplett und transparent Zugriff auf die verlagerten Daten haben und sämtliche Einsparmöglichkeiten wie z. B. auch durch nicht redundantes Backup, minimale Ausfallzeiten und zentrale Administration realisiert werden können.Alle dieseVorteile führen zu einem wesentlichen Ziel innerhalb einer ILM-Strategie – der Senkung der Gesamtbetriebskosten für vernetzte Massenspeicher-Infrastrukturen. 8.2.2.5 ILM – Komplexität der Umsetzung In der Realität ist es oftmals schwierig, Daten, die auf unterschiedlichen Speichersystemen verteilt sind, zu erfassen, zu bewerten, zu kontrollieren und gemäß ILM zu migrieren. Beispielsweise existieren in vielen Unternehmen mit Filialnetzen eine große Anzahl an Daten, über die keine detaillierten Kenntnisse vorhanden sind. In vielen Fällen ist nicht durchgängig bekannt, welche Daten in Filialen abgespeichert sind, welche Wichtigkeit diese haben oder welche rechtlichen Implikationen mit diesen Daten verbunden sind. Dadurch kann der Information Lifecycle anhand des Alters, der Zugriffshäufigkeit oder anhand weiterer wichtiger Kriterien, wie beispielsweise der unternehmerische Wert der Daten, nicht vollständig und effektiv ermittelt werden; Information Lifecycle Management ist aber das Konzept, das zentrale Schmerzpunkte wie Backup oder TCO erfolgreich addressiert und Unternehmen aus den häufig unkomfortablen Situationen in ihren Speicherumgebungen helfen kann. In der Anwendung ist ILM hochkomplex und erfordert

352

8 ILM aus der Sicht der Anbieter

komplizierte Eingriffe in existierende Speicherumgebungen. Brocade konzentriert sich auf ILM-Konzepte für dateibasierte Daten. Dieser Bereich ist in vielen Unternehmen an einem kritischen Punkt angelangt, da insbesondere dateibasierte Daten in der Vergangenheit unstrukturiert gespeichert wurden und durch vielfältige Applikationen ein enormes Wachstum aufweisen. Durch die Palette der Brocade Tapestry Software haben Unternehmen jetzt die Möglichkeit, ihre teuren und komplexen Probleme in der Dateispeicherverwaltung – sowohl für heterogene Umgebungen als auch im reinen Microsoft-Umfeld – zu lösen.

8.2.3

DELL

Niemand spricht von Dell beim Thema ILM. Dies ist ein Fehler. Dell ist nach Angaben des Marktforschers IDC (Final Data May 2006) mit 18,1 Prozent Marktanteil der weltweit größte Hersteller von Personal Computern. (HP 16,4 Prozent, Lenovo 6,4 Prozent, Acer 5,5 Prozent, Fujitsu Siemens 4,4 Prozent) und bezüglich des Vertriebs von Speicherlösungen bereits Nr. 5, nur knapp geschlagen von Hitachi. Die Produktpalette umfasst u. a. PCs, Notebooks, Server, Handhelds und Drucker. Am 1. September 2005 hat Dell in Halle ein Service- und Vertriebszentrum zur Betreuung mittelständischer Kunden und öffentlicher Auftraggeber eröffnet, das die Kunden berät und in Verbindung mit Partnerunternehmen bei der Realisierung von IT-Projekten unterstützt. Fokus von Dell war bisher die Belieferung mit preiswerter Hardware und hardwarenaher Support. Die Unterstützung des Kunden bei der Konzeption der Lösung und deren Umsetzung war nicht im Fokus bzw. wird von den Kunden erst in Ansätzen wahrgenommen. Durch die Partnerschaften mit EMC2 und den Aufbau des Servicezentrums zeichnet sich hier ein Wandel ab.EMC2 und Dell nutzen in der Zusammenarbeit ihre Kernkompetenzen,um ihren gemeinsamen Kunden höheren Nutzen zu bieten.Diese weltweite Zusammenarbeit vereint die Speicherprodukte von EMC2 mit dem bewährten Direktmodell für Server von Dell. Die Endbenutzer profitieren von umfassenden Server- und Speicherlösungen für Unternehmen – einschließlich Hardware, Software und Services – direkt von Dell. Die Stärken von Dell liegen bisher in der Verknüpfung von preisbewusster Hardware, die über Monate aus den gleichen Komponenten besteht, und einem Systemmanagement für Server. Beide Faktoren tragen dazu bei, dass die Kunden insbesondere durch vereinfachtes System- und Sicherheitsmanagement hier deutlich Kosteneinspareffekte erzielen. Bei einer großen installierten Basis ist die Homogenität der Hardwarekomponenten eine wesentliche Komponente, da sie insbesondere das Patch-Management und den Roll-out-Prozess von Software vereinfacht und zudem sicherer macht. Die Bedeutung einer standardisierten Hardwareumgebung bei weltweiten Aktivitäten auch für das Sicherheitsmanagement wurde bereits ausführlich in Kapitel 7 behandelt. Darüber hinaus stehen zahlreiche Dienstleistungs- und Support-Optionen zur Verfügung, um die Integrität der Lösung zu überwachen und zu erhalten. Mit der Bereitstellung dieser Dienstleistungen und der „Standardisierung“ der Abläufe bzw. der Vertrautheit mit Problemen wirkt sich der Dell-Effekt in diesem

8.2 Interessante Spezialisten

353

Abb. 8.8. Service und Support

Markt deutlich aus: Die Servicequalität wird kontinuierlich verbessert und die Behebungszeit bzw. die Kosten werden reduziert. Damit unterstützt Dell insbesondere die Basisprozesse, die erst die Voraussetzung für eine erfolgreiche Umsetzung eines ILM-Projektes schaffen. Kennzeichen der Leistungen von Dell, vergleichbar mit IBM und Siemens, sind: • Weltweites Roll-out einer einheitlichen IT-Infrastruktur bis auf die einzelne Komponentenebene • Weltweites Patch-Management • Weltweiter Support Dell ist bisher noch nicht mit einem eigenen ILM-Modell in Erscheinung getreten. Für die Wertung bei der Auswahl eines Partners ist zu berücksichtigen, dass ILM einen strategischen und einen taktischen Aspekt besitzt: • Zum taktischen Bereich gehören die mittelfristigen Investitionsentscheidungen, wie zum Beispiel die Realisierung von Tiered Storage ohne jede automatische Verlagerung. • Im taktischen Ansatz können auch für definierte Segmente oder Applikationen bereits heute ILM-Konzepte realisiert werden. • Im strategischen Ansatz werden langfristige Investitionsentscheidungen, wie die Realisierung einer Tiered-Speicher-Architektur,an der eigenen ILM-Vision ausgerichtet.

354

8 ILM aus der Sicht der Anbieter

Die Kernkompetenzen von Dell in Bezug auf die Realisierung von ILM liegen: • auf taktischer Ebene, wie z. B. Einzellösungen für E-Mail, • auf strategischer Ebene, wie z. B. weltweite Lieferung von Hardware, Speicher und Backup aus einer Hand, sowie • im Einsatz von Standards. Warum hat sich Dell für den Einsatz von Standards entschieden? Standards bieten heute und auf absehbare Zeit den höchsten Nutzen sowie die größte Auswahl und Flexibilität für den Kunden. Alle Technologien migrieren im Laufe der Zeit zu Industriestandards, so dass die Gesamtkosten für Kunden sinken. Diese Entwicklung lässt sich in verschiedenen Anwendungsbereichen verfolgen. Vieles spricht dafür, dass dies auch mit anderen IT-Technologien geschehen ist und selbst mit Datencenter-Technologien, wie beispielsweise Server und Speicher, geschehen wird. Konkrete Lösungen mit nachvollziehbaren Ergebnissen wie beispielsweise TCO-Reduzierungen bringen Unternehmen voran. Dell setzt deshalb mehr auf die Grundideen von ILM und deren Umsetzung auf Basis von Standards, statt ein eigenes ILM-Modell zu entwerfen. Kunden interessieren sich deshalb zunehmend für taktische und operativ umsetzbare Lösungen mit exzellenten ROI-Werten. Dell stellt hierfür standardisierte Lösungen bereit. Beispiele sind CentricStor für die Integration der Bandebene in ILM und Branch-Office-Connection-Lösungen für den Anschluss der Filialen und Zweigstellen sowie spezifische Lösungen für E-Mail auf Basis von EMC2. In Teilbereichen jedoch lässt sich ILM deshalb bereits heute mit Dell recht problemlos einführen – vergleichbar den meisten großen Herstellern verfügt Dell über die passenden Produkte und Lösungen. Umfassende Gesamtlösungen allerdings gibt es nicht von der Stange. Die Planung des skalierbaren Unternehmens erfolgt in mehreren Phasen und auf pragmatische Art und Weise. • Phase 1: Aktiviert. Diese Phase umfasst die Anwendung von Lösungen für Gruppenmanagement und Implementierung zur Vereinfachung von Abläufen sowie das Prüfen von Konsolidierungs- und Virtualisierungslösungen zur Verbesserung der Nutzung. • Phase 2: Integriert. In Phase 2 werden Lösungen und Technologien weiter integriert, indem Standards und technologische Verbesserungen kontinuierlich weiterentwickelt werden. Es zeichnet sich eine Entwicklung hin zu herstellerneutralen Lösungen und entsprechender Automation ab. • Phase 3: Verbessern. In Phase 3 werden schließlich Betriebs- und Nutzungsverbesserungen problemlos durch auf Richtlinien basierende Lösungen und Technologien zur Selbstanalyse erreicht. Viele Branchenanalysten (Gartner,IDC,Summit Strategies) unterstützen den pragmatischen Ansatz von Dell bei der Vision des Datencenters der Zukunft.

8.3 ILM-Ansätze der Dienstleister

355

Zu komplex und zu unterschiedlich ist die Situation in den Firmen, als dass sich deren Anforderungen in einer Lösung wiederfinden.Andererseits drängt ILM zu einem schrittweisen Vorgehen, indem sich – wie bereits gezeigt – mit jedem einzelnen Schritt Kosten und Komplexität reduzieren lassen.

8.3

ILM-Ansätze der Dienstleister

Als Dienstleister verstehen wir in diesem Abschnitt die klassischen IT-Integratoren sowie die Beratungshäuser, die im Rahmen von BPM-Dienstleistungen dem Thema Information Lifecycle Management Aufmerksamkeit zollen sollten. Außerdem gehören hierzu die klassischen Wirtschaftsprüfungsgesellschaften und Unternehmensberatungen,die dem Thema ILM aus betriebswirtschaftlicher und aus Compliance-Sicht zugewandt sein müssten. Bei Betrachtung des öffentlichen Auftritts dieser Unternehmen finden wir jedoch – für uns völlig überraschend – wenige vage bis keinerlei Hinweise auf Aktivitäten in diesem Umfeld.

8.3.1

Accenture

Bezüglich Compliance bietet Accenture im Rahmen seines Programms zu Risk & Regulatory Management für Finanzinstitute Unterstützung bei Prozessen zur Gewährleistung regulativer Compliance zu Basel II, SOX etc. an. Compliance wird von Accenture in der Beratung zu Risk Management voll auf die Agenda gesetzt. Bei der Verbindung von Compliance zu Information Lifecycle Management und TieredStorage verweist Accenture auf seine langjährige Partnerschaft mit EMC2 . Direkte Unterstützung zu ILM von Accenture findet man zumindest auf der AccentureInternetpräsenz nicht.Die Allianz mit EMC2 liefert Accenture den Zugang zu dieser im Speichermarkt relevanten Thematik,dies jedoch lediglich über das in dieser Allianz geschulte Personal und nur in der durch EMC2 vorgegebenen Interpretation von Information Lifecycle Management.

8.3.2

BCG – Boston Consulting Group

ILM wird bei der BCG in keiner Weise thematisiert. Auch Compliance wird lediglich im Rahmen von Risikomanagementsystemen gestreift. Dennoch bietet die Information Technology Practice Support auch in diesem Umfeld an.

8.3.3

Computacenter Compunet

Computacenter Compunet thematisiert als IT-Integrator ILM. Dabei wird vor allem auf Tiered Storage zur Absenkung der Total Cost of Ownership abgehoben. „Damit mit der Datenflut nicht automatisch eine Kostenflut einhergeht, konzipiert Computacenter Speicher-Lösungen, welche die Kosten für die Speicherung und Archivierung der Daten ebenso berücksichtigen wie das Management der sich im

356

8 ILM aus der Sicht der Anbieter

Lauf der Zeit verändernden Informationen.“98 Dies deutet auf ein Engagement von Computacenter bei der Implementierung von Tiered-Storage-Umgebungen hin, jedoch weniger auf die Berücksichtigung und Integration der IT-Prozesse in die Geschäftsprozesse und vice versa.

8.3.4

CSC Ploenzke

CSC Ploenzke als in Deutschland bedeutender IT-Integrator, Outsourcer und anerkanntes IT-Beratungshaus gibt zwar den Hinweis auf Beratung über das Management des Produktlebenszyklus, also den klassischen betriebswirtschaftlichen Ansatz, der jedoch hier mit keiner Silbe auf das Produkt Information angewandt wird. So muss CSC Ploenzke als einer der größten Outsourcer in Deutschland im Rahmen seiner IT-Managementaktivitäten zwar einem Druck zur Implementierung eines ILM-Konzeptes folgen, macht jedoch nach allem Anschein keinerlei Gestalten, diesen Ansatz selbst aktiv zu steuern.

8.3.5

EDS

EDS macht als Outsourcer ILM zum Geschäftsthema und kündigt drei Phasen seiner ILM-Entwicklung an: • In der ersten Phase (Stand heute) wird Speicheroptimierung angeboten. Darunter versteht EDS Tiered Managed Services, basierend auf flexiblen Anforderungen an die Daten. Hier liefert EDS Managed Storage Services sowie Information Protection Services. • Die zweite Phase (bis 2008) ist die Phase der Informationsoptimierung. Hier wird der anwendungszentrierte Blick auf die Services der EDS gelegt. Hier soll ein Policy-basiertes Management von Enterprise-Anwendungen und Messaging- Plattformen den Fokus auf die Geschäftsprozessunterstützung durch das IT-Management legen. • Die dritte Phase (nach 2008) bietet Policy-basierte Management Services für sämtliche Anwendungen des Unternehmens. Hier erfolgt das komplette Alignment von IT- und Informationsmanagement mit den Geschäftsprozessen. Betrachtet man diese Roadmap der EDS-Services bzgl. ILM, so stellt man eine enge Korrelation mit der Roadmap der SNIA hinsichtlich SMI fest. EDS folgt dieser – gemeinsam mit den beiden Partnern EMC2 und Cisco, deren Allianz mit EDS auf der Internet-Präsenz der EDS explizit herausgestellt wird.

8.3.6

Ernst & Young

Bei Ernst & Young als einem der weltweit größten Wirtschaftsprüfungs- und Beratungsunternehmen haben wir zumindest bei der Einhaltung von Compliance im Umfeld mit IT-Governance Aktivitäten, wenn nicht gar einen Themenschwer98

http://www.computacenter.de/technologien/server Speichertechnologien/popup ilm.shtml.

8.3 ILM-Ansätze der Dienstleister

357

punkt erwartet. Hier wurden wir auch fündig. Compliance wird hier im Detail für internes Controlling, Corporate Governance, Tax-Compliance usw. abgehandelt. Hier sieht Ernst & Young einen Schwerpunkt seiner Tätigkeit. Den Querverweis zu Information Lifecycle Management oder gar Unterstützung von Information Lifecycle Management konnten wir in den Hinweisen zum Produktportfolio nicht finden.

8.3.7

Kienbaum

Kienbaum legt seinen Schwerpunkt auf das Thema Management Consulting. Im Bereich IT-Management wird nicht speziell auf ILM abgehoben. Im Management Consulting und den einzelnen bevorzugten Branchen Health Care, Öffentlicher Dienst, Pharmaindustrie und Finanzinstitute wird auf Compliance ebenso wenig hingewiesen.

8.3.8

Logica CMG

Logica CMG befasst sich über seinen Beratungszweig, die erst kürzlich übernommene Unilog Avinci, mit dem Thema ILM. Diese betreibt klassische IT-Beratung auch im Speicherumfeld, nähert sich dem Thema ILM jedoch eher über die Umsetzung von Virtualisierungskonzepten als über den betriebswirtschaftlich rechtlichen Ansatz. „Die sogenannten ,Virtualisierungsprojekte’ sind oftmals vielmehr Projekte mit ILM-Ansatz, mit Business-Continuity- und Service Level AgreementAnforderungen, die sich nur sinnvoll mit Hilfe der Virtualisierung lösen lassen.“99

8.3.9

Materna GmbH

Materna bietet mit dem Government Site Builder, der ab 2002 für das Bundesverwaltungsamt entwickelt wurde und heute frei vermarktet wird, eine flexible Content-Management-Lösung an. Damit ist Materna als Segmentanbieter im ILMUmfeld von Interesse. Komplettmodelle und Strategien bzgl. Information Lifecycle Management und Compliance konnten nicht gefunden werden.

8.3.10

McKinsey & Company

McKinsey & Company fokussieren ihre Services auf das High Level Consulting des Topmanagements bzgl. ihrer größten Herausforderungen. In diesem Zusammenhang ist Compliance im Rahmen des Risikomanagements und ILM zur Anpassung der IT-Prozesse an die Geschäftsprozesse sehr wohl im Blickfeld des McKinsey Consultings. McKinsey adressiert hier jedoch mehr die Themen, die wir in Kapitel 1 und 2 dieses Buches beschrieben haben. Die Implementierung von ILM sowie die Durchführung solcher Realisierungsprojekte stehen nicht im Zentrum der Beratung von McKinsey & Company.

99

Kuhn, Rudolf, Die Datenflut beherrschen, aus: IT-Director, 1-2/2006.

358

8 ILM aus der Sicht der Anbieter

8.3.11

PriceWaterhouseCoopers (PWC)

PWC hat einen Schwerpunkt in der Beratung zu Corporate Governance, Risikomanagement und Compliance. Hier wird der Kunde in aller Tiefe Kompetenz finden. Den Schwung von Compliance zu Archivierung, Storage Tiers und ILM zur Implementierung der IT-Governance und technischen Unterstützung des rechtlichen und ökonomischen Schwerpunktes findet man bei PWC so nicht.

8.3.12

Roland Berger Strategy Consultants

Roland Berger Strategy Consultants bedienen ein dem von McKinsey & Company ähnelndes Geschäftsmodell. Dabei adressiert das IT-Strategie-Consulting von Roland Berger den Lebenszyklus des Informationsmanagements, ohne explizit auf Information Lifecycle Management abzuheben. Hier wird das Portfolio der IT zum Informationsmanagement beschrieben und dessen Effizienz während des Lebenszyklus überwacht. Information Lifecycle Management als Nutzung dieses Portfolios liegt eine Ebene unter der von Roland Berger betriebenen strategischen Beratung.

8.3.13

Siemens (hier SBS)100

Seit dem 01.10.2006 agiert SBS mit neuer Organisationsstruktur am Markt. Als strategischer Partner bei der Lösung unternehmerischer Aufgabenstellungen bietet SBS seinen Kunden weltweit und in Deutschland Leistungen entlang der gesamten IT-Dienstleistungskette aus einer Hand – vom Consulting über die Systemintegration bis zum Management von IT-Infrastrukturen. Schwerpunktbranchen sind Manufacturing, öffentliche Auftraggeber und Finanzdienstleister. Das Geschäft mit produktnahen Dienstleistungen (PRS) wurde an den PC-Hersteller Fujitsu Siemens verkauft. Zu den produktnahen Dienstleistungen gehört unter anderem die Wartung von Großrechnern. Die Einheit werde bei Fujitsu Siemens als Ganzes erhalten um den Kern einer neuen Serviceeinheit zu bilden, hieß es.

8.3.14

Deutsche Telekom AG (hier T-Systems)101

T-Systems ist ein weltweit operierender Dienstleister für Informations- und Kommunikationstechnologie (ICT). T-Systems mit seinen langjährigen fundierten Erfahrungen aus dem Betrieb von effizienten Rechenzentren ist auch für ILM ein kompetenter Anbieter. Die beiden Autoren haben in Zusammenarbeit mit T-Systems u. a. für T-Systems eine Reihe anspruchsvoller Aktivitäten insbesondere im Speicherbereich durchgeführt. Die Ausrichtung als ICT-Anbieter folgt der Beobachtung, dass sich die Grenze zwischen Informationstechnik (IT) und Telekommunikation (TK) langsam auflöst und die beiden Bereiche im Begriff sind, zu verschmelzen. So hat T-Systems auch das Kunstwort ITC entwickelt, das die 100 101

Wikipedia, Siemens (www.siemens.de), diverse Pressemitteilungen. Wikipedia, Telekom (www.telekom.de), diverse Pressemitteilungen.

8.3 ILM-Ansätze der Dienstleister

359

Verschmelzung von IT und TC widerspiegeln soll. Der Beiname „Convergence Company“, den sich T-Systems zeitweise gab, sollte ausdrücken, dass komplette „Konvergenz“-Lösungen, bestehend aus IT und TK, angeboten werden. Ein wichtiges Geschäftsfeld von T-Systems ist das Projektgeschäft. Im Idealfall legt der Kunde dabei T-Systems einen Anforderungskatalog vor, T-Systems stellt dann einen Projektplan auf, beschafft die Technik, installiert sie bis zur Abnahme, schult die späteren Benutzer und ist für den kurzfristigen Service im Falle von Ausfällen zuständig.

9 Zusammenfassung und Fazit

Information Lifecycle Management ist, wie bereits mehrfach beschrieben, kein Produkt, sondern ein Prozesswerk, basierend auf einem Modell. Sie sollten nach dem Studium des Buches vor dem Hintergrund der beschriebenen Anforderungen und Risiken nicht zu der Überzeugung gelangen, dass ILM für Ihr Unternehmen zu anspruchsvoll oder zu komplex ist. Wichtig für uns ist, dass Sie die Erkenntnis aus der Lektüre mitnehmen, dass ILM weder eine Laisser-faireVorbereitung noch ein Nonchalance-Durchführung erlauben. Wir haben Ihnen in diesem Buch gezeigt, dass ILM-Projekte sehr wohl auch aus wirtschaftlicher Sicht vorteilhaft sein können und dass die beschriebenen Risiken zu managen sind. Natürlich bietet sich als vermeintlicher Königsweg an, das gesamte Thema in Form des beliebten Outsourcings oder gar mittels Offshoring an Dritte abzuwälzen und zusätzlich für alle Fälle eine Manager-Haftpflichtversicherung abzuschließen. Nie war jedoch die Gefahr für Vorstände, Geschäftsführer oder Führungskräfte größer, auf Schadensersatz verklagt oder sogar strafrechtlich belangt zu werden, denn die beschriebene Verantwortung ist nicht delegierbar. Amerikanische Manager kennen längst das Gefühl, permanent mit einem Bein im Gefängnis zu stehen. Der spektakulärste Fall der letzten Jahre ist die Verurteilung des Ex-Enron-Chefs Skilling. Wegen Betrugs und Verschwörung muss er für 24 Jahre ins Gefängnis. Hinzu kommt eine Schadensersatzstrafe von 45 Millionen Dollar. Auch in Deutschland kann es für Topmanager und Führungskräfte schnell um siebenstellige Haftungssummen und damit um die nackte Existenz gehen. Dazu hat unter anderem, wie im Band „Grundlagen und Modelle des Information Lifecycle Management“ beschrieben, das „Gesetz zur Kontrolle und Transparenz im Unternehmensbereich“, kurz KonTraG geführt. Dieses verpflichtet Geschäftsführer, Vorstände etc. ausdrücklich, „geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende Entwicklungen früh erkannt werden“.Die Konsequenzen solcher Regelungen spürt aktuell auch das BenQ-Management. Nach der Pleite des Handy-Herstellers ermittelt die Staatsanwaltschaft. Der Vorwurf ist Insolvenzverschleppung und diverse Bankrottdelikte.Das Management habe nach Meinung des ermittelnden Staatsanwaltes schon länger von der schlechten finanziellen Situation des Unternehmens gewusst und noch im Juni falsche Bilanzzahlen vorgelegt. Der BenQ-Spitze droht nun eine Klagewelle, denn spätestens bei einer strafrechtlichen Verurteilung ist der Weg frei für eine persönliche Haftung der Führungskräfte.

362

9 Zusammenfassung und Fazit

Aber es gibt auch viel alltäglichere Situationen, die für die Führungskräfte ein fast unkalkulierbares Risiko darstellen. Zwei Beispiele sollen dies verdeutlichen. Wenn ein Geschäftsführer eines mittelständischen Unternehmens die Buchführung an einen Mitarbeiter delegiert, so bleibt jedoch die Verantwortung laut Gesetz weiterhin bei ihm. Wenn der Geschäftsführer die Buchhaltung nicht detailliert überwacht und sich keinen ausreichenden Überblick über die Geschäftslage verschafft, kann es zu einer falschen Gewinnermittlung und demzufolge zu einer falschen Gewinnausschüttung kommen.Wenn das Unternehmen eine zu hohe Gewinnausschüttung vornimmt, die nicht rückgängig gemacht werden kann, so muss der Geschäftsführer persönlich dafür haften. In einem weiteren Beispiel rückte ein ganzer Aufsichtsrat in den Blickpunkt. Bei einer kleineren Baufirma wurde die Geschäftsleitung nicht ausreichend kontrolliert. So gab es bei Aufsichtsratssitzungen lediglich eine standardisierte Tagesordnung ohne genaue Geschäftsleitungsberichte. Das Kontrollgremium „Aufsichtsrat“ erkannte die drohende Misere nicht und konnte daher Managementfehler nicht korrigieren.Als das Unternehmen Konkurs anmeldete, wurde der Aufsichtsrat haftbar gemacht. Die rechtlichen Risiken für Führungskräfte gleichen immer mehr einem dichten Dschungel. Oft lauert der Fehler im Detail. Führungskräfte sollten daher aus reinem Selbstschutz darauf dringen, dass die beschriebenen spezifischen ILMAnforderungen erfüllt, und alle Entscheidungen gegebenenfalls bis ins Detail gerechtfertigt waren (vgl. hierzu das Mannesmann-Verfahren). Besonders brisant sind Firmenpleiten. Der Insolvenzverwalter macht sich sofort auf die Suche nach Verantwortlichen, die zur Pleite des Unternehmens beigetragen haben könnten. Besteht der Verdacht, Führungskräfte hätten nicht im Sinne des Unternehmens gehandelt, schlägt die Managerhaftung zu und sie sind in der Beweispflicht, das Richtige getan zu haben. ILM bleibt in der Verantwortung der IT und des CIO des Unternehmens. Die Kompetenz für die Durchführung eines Implementierungsprojektes zu ILM muss sich dieser hausintern oder anderweitig beschaffen. Innerhalb des Prozesswerkes ILM liefert jeder der hier betrachteten Hersteller einen mehr oder weniger großen Anteil zur Lösung. Auffällig ist, dass jeder der betrachteten Hersteller sich dem Prozesswerk von seinem klassischen Produktportfolio her nähert. Die Beratungsunternehmen decken den juristischen und betriebswirtschaftlichen Part mehr oder weniger komplett ab, das Gleiche mag für die eher aus dem Speicherumfeld kommenden Hard- und Softwarehersteller für den technischen Part von ILM gelten. Insgesamt belassen jedoch beide Richtungen einen Großteil der Komplexität – zumindest die Datentypisierung – und die Durchführung des Projektes inklusive der Lösungs- und Herstellerauswahl bei ihren Kunden.

Literaturverzeichnis

100-6INFO, Department of the Army, Washington, DC, USA, Field-Manual-No. 100-6, 1996. Aberdeen Group, www.aberdeen.com AICPA, www.aicpa.org. AIIM, The Enterprise Content Management Association, www.aiim.org Airbus Industrie Pressemitteilung, www.airbus.com. Albach, H., Organisation: Mikro¨okonomische Theorie und ihre Anwendungen, Wiesbaden, 1989. Anlage zum BMF-Schreiben vom 7. November 1995 IV A 8 – S 0316 – 52/95. Ault, Michael R., Das Oracle 8-Handbuch, Bonn et. al., 1998. Ault, Michael, Oracle 8 Administration and Management, New York et.al., 1998. Babineau, Brian, Enterprise Strategy Group – ESG (Hrsg.), Leverage, Storage, Innovation: The New LSI Logic in: Storage and Information Management Brief vom 8.07.2006, S. 2. Bartmann, Hermann: Preistheorie (Vorlesung), St. Gallen, 1981, S. A/1. Bauwens, M., The free Loss of the Cyber-Economy, in: CMC Magazin 1996 Benner, Alan F., FIBRE CHANNEL for SANs, New York et. al., 2001. Bergfeld, Heinz, Kreativit¨atstechniken, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.813 ff. Bergmann,Friedhelm; Gerhardt,Hans-Joachim; Frohberg,Wolfgang: Taschenbuch der Telekommunikation, 2. Auflage, Leipzig, 2003, S. 553. BGBl I 1976, 613 (1977, 269). BGBl I 1976, 613 (1977, 269). BGHZ 135, 244 = NJW1997, aus www.uni-frankfurt.de/fb/fb01/ifawz1/segna/files/ 0607/koll-0607-synopsis.de BITCOM, www.bitkom.de Black, Uyless, ATM – Foundation for Broadband Networks, Prentice-Hall PTR, Englewood Cliffs, NJ, 1995.

364

Literaturverzeichnis

Blecher, Michael, Gartner Group, Component based Development: The next wave, 4/1999. BMF-Schreiben vom 15. Juli 1998 BStBL I S. 630, ge¨andert durch BMF-Schreiben vom 14. Februar 2000 (BStBl. I S. 190), vom 27. September 2000 (BStBl. I S. 1232) und vom 22. Dezember 2000 (BStBl. I S. 1549:2). BSI – Bundesamt f u¨ r Sicherheit in der Informationstechnologie, www.BSI.de. BSI, www.bsi.de/gshb/deutsch/g/g05.htm. Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003 (BGBl.I S.66),ge¨andert durch § 13 Absatz 1 des Gesetzes vom 5.September 2005 (BGBl. I S. 2722) Business Intelligence, Verlegerbeilage der COMPUTERWOCHE, COMPUTERWOCHE 26/2006, M¨unchen, 2006. CISA, www.isaca.org/cisa. Clark, Tom, DESIGNING STORAGE AREA NETWORKS, 3.Aufl., Massachusettes et. al., 2000. Clifford, Chance, P¨under, Rechtsanw¨alte, Frankfurt. Comer, Douglas E., Internetworking with TCP/IP Vol. 1: Principles, Protocols,and Architecture, Prentice-Hall, Englewood Cliffs, NJ, 1995. Computer Security Institute Pressemitteilung, www.gocsi.com COMPUTERWOCHE 9/2001, vom 27.07.2001, S. 7f, S. 10. Corsten, H., Die Produktion von Dienstleistungen, Berlin, 1985. Corsten, H., Dienstleistungsmanagement, M¨unchen, 1997. Cox, Roger, Storage:The New IT Gorilla, Gartner Dataquest Storage, General Session, STR 17, 06/01, Stammford, 2001, S. 18. Cramer, M.L., Measuring the Value Information, infoWAR-Congress, Vienna 1997. Defekter EMC-Speicher legt Strato lahm, aus: COMPUTERWOCHE 14/2001, vom 06.04.2001, S. 10. Dell Pressemitteilung. DeMarco, Tom, Lister, Timothy, B¨arentango. Mit Risikomanagement Projekte zum Erfolg f u¨ hren, Wiesbaden, 2003. Diederich, Helmut: Allgemeine Betriebswirtschaftslehre I, Stuttgart, Berlin, K¨oln, Mainz, 1979, S. 18. Diederich, Helmut: Allgemeine Betriebswirtschaftslehre II, Stuttgart, Berlin, K¨oln, Mainz, 1979, S. 113 ff. Dignan, L., Strassman, Paul,Who Led the Baseline 500 and Why, Baseline Magazine Okt. 2004. DoD 5015.2-STD, "Design Criteria Standard for Electronic Records Management Software Applications,"06/19/2002, S. 24, verf u¨ gbar u¨ ber: Egip Software AG, www.egip.com

Literaturverzeichnis

365

Einkommenssteuer-Handbuch 1993 vom 18. Mai 1994 (BStBl I 1994, Sondernummer 1/1994). Schreiben des BMF an die obersten Finanzbeh¨orden der L¨ander vom 7. November 1995 – IV A 8 – S 0316 – 52/95 – BStBl 1995 I EMC Corpoation (Hrsg.), Symmetrix Optimizer Control Interface, Version 4.0 for MVS, USER GUIDE, Hopkinton, 1999, P/N 300-999-035. EMC Corporatin (Hrsg.),EMC ControlCenter,Version 4.1,INSTALLATION GUIDE, Hopkinton, 2000, P/N 300-999-230. EMC Corporation (Hrsg.) EMC ControlCenter TimeFinder Manager, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1998,1999,2000, P/N 300-999-240. EMC Corporation (Hrsg.), Connectrix ED-1032 Director, USER GUIDE, Hopkinton, 2000, P/N 300-600-004. EMC Corporation (Hrsg.), Connectrix EC-1100 System, PLANNING GUIDE, Hopkinton, 2000, P/N 300-600-002. EMC Corporation (Hrsg.), Connectrix EC-1100 System, USER GUIDE, Hopkinton, 2000, P/N 300-600-001. EMC Corporation (Hrsg.), EMC Connectrix Enterprise Storage Network System, TOPOLOGY GUIDE, Hopkinton, 2000, P/N 300-600-008. EMC Corporation (Hrsg.), EMC ControlCenter Console with Resource View, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-229. EMC Corporation (Hrsg.), EMC ControlCenter Integration Packages, Version 4.1 for Windows and UNIX, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-235. EMC Corporation (Hrsg.), EMC ControlCenter SRDF Manager, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-237. EMC Corporation (Hrsg.), EMC ControlCenter SRDF Manager, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1998,1999,2000, P/N 300-999,238. EMC Corporation (Hrsg.), EMC ControlCenter Symmertix Disk Reallocation,Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-242. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Disk Reallocation,Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-241. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Manager for Windows, Verson 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-233. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Manager, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-234. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Optimizer, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-243. EMC Corporation (Hrsg.), EMC ControlCenter Symmetrix Optimizer, Version 4.1 for UNIX, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-244. EMC Corporation (Hrsg.), EMC ControlCenter TimeFinder Manager, Version 4.1 for Windows, PRODUCT GUIDE, Hopkinton, 1999,2000, P/N 300-999-239.

366

Literaturverzeichnis

EMC Corporation (Hrsg.), EMC ControlCenter Web Edition, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-232. EMC Corporation (Hrsg.), EMC ControlCenter Workload Analyzer, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-246. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Base Component,Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-624-04. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Base Component,Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-624-03. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Configuration Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-298. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Control Component, Vesion 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-142. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Control Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-142-01. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Mapping Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-999-037-01. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Mapping Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 300-99-037-02. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI SRDF Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-625-04. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI SRDF Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-625-03. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI Time Finder Component, Version 4.1, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-634-03. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI TimeFinder Component, Version 4.2, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-634-04. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI, Version 4.1.2, Release Notes, Hopkinton, 2000, P/N 200-999-632-07. EMC Corporation (Hrsg.), EMC Solutions Enabler SYMCLI, Version 4.2, Release Notes, Hopkinton, 2000, P/N 200-999-632-08. EMC Corporation (Hrsg.), EMC Solutions Enabler, version 4.1, INSTALLATIONS GUIDE, Hopkinton, 2000, P/N 200-999-635-04. EMC Corporation (Hrsg.), EMC Solutions Enabler, Version 4.2, INSTALLATIONS GUIDE, Hopkinton, 2000, P/N 200-999-635-05. EMC Corporation (Hrsg.), Instant Restore of Oracle Databases: Leveraging TimeFinder Multi-BCV and Instant Split, Hopkinton, 1999,2000. EMC Corporation (Hrsg.), Symmetrix SRDF Host Component, Version 4.0, PRODUCT GUIDE, Hopkinton, 2000, P/N 200-999-561. EMC verliert den Glanz fr¨uherer Tage, aus: COMPUTERWOCHE 22/2001, vom 01.06.2001, S. 1 und S. 16.

Literaturverzeichnis

367

EMC zertifiziert, aus: COMPUTERWOCHE 24/2001, 28. Jahrgang, M¨unchen, 2001. EMC zertifiziert, aus: COMPUTERWOCHE 24/2001, vom 15.06.2001, S. 35. EMC, Pressemitteilung, 2006. EMC2 Marketingunterlage 2005. EMC2 Pressemitteilung. Enticknap, Nick, Ein verkanntes Problem tritt in den Vordergrund, STORAGE AKTUELL, e-business Sonderausgabe, 2001, S. 14. Erste Produkte f u¨ r IP-Speicher, SAN mit Gigabit Ethernet und IP, aus: COMPUTERWOCHE 13/2001, vom 30.03.2001, S. 42. EU Pressemitteilung, www.europa.eu EUDRALEX Volume 4 – Medicinal Products for Human and Veterinary Use : Good Manufacturing Practice, http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev4.htm Fafaeli, S., Raban, D.R., Experimental Investigation of the Subjective Value of Information in Trading, 2003. Farley, Marc, Building Storage Networks, The McGraw-Hill Companies, 2000. Fassung aufgrund des Gesetzes zur Einf¨uhrung internationaler Rechnungslegungsstandards und zur Sicherung der Qualit¨at der Abschlusspr¨ufung (Bilanzrechtsreformgesetz – BilReG) vom 4.12.2004 m.W.v. 10.12.2004. Fassung der Bekanntmachung vom 9. Juni 1999 (BGBl. I S. 1270) FAZ Institut; www.faz-institut.de FC-AL, Fibre Channal Arbitrated Loop, ANSI X3.272-1996. FC-AL-2, Fibre Channal Arbitrated Loop, ANSI X3.T11 Project 1133-D. FC-GS, Fibre Channal Generic Services, ANSI X3.288-1996. FC-GS-2, Fibre Channal Generic Services 2, ANSI X3.T11 Project 1134-D. FC-LE, Fibre Channal Link Encapsulation, ANSI X3.287-1996. FCP, Fibre Channal Protocol for SCSI, ANSI X3.269-199x. FC-PH Errata, Fibre Channal Physical and Signaling Interface Errata,ANSI X3.230: AM1-1996. FC-PH, Fibre Channal Physical and Signaling Interface, ANSI X3.230-1994. FC-PH-2, Fibre Channal Physical and Signaling Interface-2, ANSI X3.297-1997. FC-PH-3, Fibre Channal Physical and Signaling Interface-3, ANSI X3.T11 Project 1119-D. FC-SL, Fibre Channal Slotted Loop, ANSI X3.T11 Projekt 1232-D. FC-SW, Fibre Channal Switch Fabric, ANSI X3.T11 Project 959-D Federated Storage Area Management, HP setzt auf dezentrale Systeme, aus: COMPUTERWOCHE 12/2001, vom 23.03.2001, S. 48.

368

Literaturverzeichnis

Fragen und Antworten zum Datenzugriffsrecht der Finanzverwaltung, http://www.bundesfinanzministerium.de/DE/Service/Downloads/Abt IV/ 009,property=publicationFile,cap.locale=de.pdf. Fujitsu Siemens Pressemitteilung. Gartner Dataquest, www.dataquest.com. Gesetz u¨ ber das Kreditwesen (Kreditwesengesetz – KWG) in der Neufassung der Bekanntmachung vom 9. September 1998 (BGBl. I S. 2776) zuletzt ge¨andert durch Art. 4a des Gesetzes vom 22. September 2005 (BGBl. I S. 2809). Gesetz u¨ ber das Kreditwesen (Kreditwesengesetz – KWG), a.a.O. Gesetz zur Anpassung der Formvorschriften des Privatrechts und anderer Vorschriften an den modernen Rechtsgesch¨aftsverkehr, Bundesgesetzblatt Jahrgang 2001 Teil I Nr. 35, ausgegeben zu Bonn am 18. Juli 2001 GoBS Tz. 1, Abschnitt c) aus Schreiben des BMF an die obersten Finanzbeh¨orden der L¨ander vom 7. November 1995 Gottwald, Holger, R/3-Datensicherung mit Spiegelplatten, aus: COMPUTERWOCHE 20/2001, vom 18.05.2001, S. 34ff. Graf von Kerssenbrock, Otto-Ferdinand, Riedel, Olaf, Z¨ollkau, York, Steuerliches Risikomanagement / Tax Risk Management Am Beispiel des Datenzugriffs der Finanzverwaltung nach § 147 Abs. 6 AO und GDPdU – Schreiben, 1. Auflage, Bonn, 2005. Grau, Nino, Projektziele, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.155. Grunds¨atze zum Datenzugriff und zur Pr¨ufbarkeit digitaler Unterlagen (DGPdU), Schreiben des BMF an die obersten Finanzbeh¨orden der L¨ander vom 16. Juli 2001 – IV D 2 – S 0316 – 136/01-. Gulbins, J¨urgen, Obermayr, Karl, AIX UNIX System V.4, Berlin et. al., 1996. Gutenberg, E.: Grundlagen der Betriebswirtschaftslehre, Bd. 1: Die Produktion, 21. Aufl., Berlin, Heidelberg, New York, 1975, S.1 f. nach W¨ohe, G¨unter, a.a.O., S. 287. Handschuch, Thomas, Solaris 2 Systemadministration, Bonn et. al., 1996. H¨auser, Franz: Bankenaufsicht in Europa – „Basel II“ als Perspektive, Leipzig, 2002, S. 19. Hesteller setzen zunehmend auf offene Standards, Viele neue Allianzen auf dem Speichermarkt, aus: COMPUTERWOCHE 9/2001, vom 02.03.2001, S. 6. Hewlett Packard Company (Hrsg.), MC/Service Guard, User Guide, 1998. ¨ Homepage der LSI-Logic Corporation in Deutschland, Uber uns, /www.lsil.com/worldwide/lsi emea/germany/index.html. H¨orner, Brigitte, DECnet- Das Netzwerk als System, 2. Aufl., Bonn et. al., 1992. HP (www.hp.com) http://de.wikipedia.org/wiki/Basel II#Motive

Literaturverzeichnis

369

http://de.wikipedia.org/wiki/Basel II#Motive, a.a.O. http://de.wikipedia.org/wiki/Daten#Informatik. http://de.wikipedia.org/wiki/Good Manufacturing Practice http://de.wiktionary.org/wiki/Information http://de.wiktionary.org/wiki/Markt http://de.wiktionary.org/wiki/Produkt http://de.wiktionary.org/wiki/produzieren http://www.computacenter.de/technologien/server storagetechnologien/ popup ilm.shtml. http://www.dtic.mil/whs/directives/corres/pdf/50152std 061902/p50152s.pdf. http://www.fujitsu-siemens.de/products/storage/index.html. http://www.hds.com/products services/storage systems/enterprise storage/. http://www-5.ibm.com/de/solutions/itsolutions/sol inform 2.html. IBM entscheidet sich f u¨ r TCP/IP,aus: COMPUTERWOCHE 9/2001,vom 02.03.2001, S. 6. IBM und Hitachi gehen einen Schritt weiter, Schulterschluss von sechs Speicherherstellern, aus: COMPUTERWOCHE 26/2001, vom 29.06.2001, S. 29. IBM, Pressemitteilung, www.ibm.com. Information zum „Beschreibungsstandard f u¨ r die Daten¨uberlassung“, http://www.bundesfinanzministerium.de/DE/Service/Downloads/Abt IV/ 010,property=publicationFile,cap.locale=de.pdf. Johnson, Robert H., MVS Concepts and Facilities, New York et.al., 1989. Kleinaltenkamp, M., Begriffsabgrenzungen und Erscheinungsformen von Dienstleistungen, in: Bruhn, Stauss (Hrsg.), Handbuch Dienstleistungsmanagement, 2002. Kleineaschoff; Ulrich, Unternehmenpr¨asentation T-Systems 2004. Kotler, Philip, Bliemel, Friedhelm: Marketing Management, Stuttgart, 1995, S. 586. Kuhn, Rudolf, Die Datenflut beherrschen, aus: IT-Director, 1-2/2006. Kumar, Balaji, Broaadband Communications: A Professional‘s Guide to ATM, Frame Relay, SMDS, SONET, and BISDN, The McGraw-Hill Companies, New York, 1995 Manager-Magazin, www.manager-magazin.de Marrone-Hurley, Nancy, Hewlett Packard – November 2003, HP Announces their ILM Initiative, aus ESG Business Brief , November 2003. c M Data, FIBRE CHANNEL, CONNECTION TO THE FUTURE, 2.Aufl.,1998. McDysan, David E., and Spohn, Darren L., ATM: Theory and Application, The McGraw-Hill Companies, New York, 1995.

370

Literaturverzeichnis

Merrill, David R., Tiered Storage Economics, White Paper von Hitachi Data Systems, Sept. 2005. Messeausgabe DMS-K¨oln, 2006 Meta Group, www.metagroup.com Meyer-Stamer, J¨org, Strategien lokaler/regionaler Entwicklung, Projekt MesoNRW, 1993. Microsoft Press (Microsoft Corporation) (Hrsg.), Networking Essentials,Washington, 1996. Microsoft Press (Microsoft Corporation) (Hrsg.), Windows NT Workstation, Version 4, Unterschleißheim, 1996. Miller, Mark A., P.E. Internetworking: A Guide to Network Communications: LAN to LAN; LAN to WAN, M&T Books, New York, 1991. Moore, Fred: Storage New Game New Rules, Boulder, 2003, S. 10. Moore, Fred: Storage New Horizons, Boulder, 2006, S. 8. Morgan Stanley vermisst Anwenderfreundlichkeit, SAN: Die grosse Herausforderung, aus: COMPUTERWOCHE 21/2001, vom 25.05.2001, S 52. Motzel, Erhard: Leistungsbewertung und Projektfortschritt, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.690 ff. M¨uller-Ettrich, Roswitha: Einsatzmittelmanagement, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.586 f. Network Appliance, www.drchip.de/html/bis 12 september 2006.html. Neue Server-Familie von Maxtor, NAS 4100 unterst¨utzt Directories, aus: COMPUTERWOCHE 12/2001, vom 23.03.2001. Nilsson, Ragnar: Die Evolution der IT-Abteilung, in: COMPUTERWOCHE 26/2006, M¨unchen, 2006, S. 26. Optische Storage-Netze, Speicherl¨osungen ohne Begrenzungen, aus: COMPUTERWOCHE 24/2001, vom 15.06.2001, S. 35. Ott, Alfred E.: Preistheorie, in: Ehrlicher, W. et al.: Kompendium der Volkswirtschaftslehre, 5. Auflage, G¨ottingen, 1975, S. 119. Page, William G. Jr., Special Edition Using Oracle 8/8i, Indianapolis, 1999 Partridge, Craig, Gigabit Networking, Addison-Wesley, Reading, MA, 1994. Petcoviæ Duˇsan, Sybase- und Microsoft-SQL Server, Bonn et.al., 1994. Platz, Jochen: Projektstart, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.1055. Pressemitteilung Symantec, www.symantec.com. Price Waterhouse, www.pwcglobal.com. Probst, G., Raub, S., Romhardt, K.: Wissen managen, 3. Aufl., Wiesbaden 1999.

Literaturverzeichnis

371

Quelle Porter, Michael E., Competivie Advantages : Creationg and Sustaining Surperior Performance, New York, 1985, Seite 3 Redman, T.C., The Impact of poor Data Quality on the Typical Enterprise, ACM Communications, 1998 Richter, Rudolf, Grundtvig,Erik,NeueInstitutions¨okonomik1999, in Mohr, Siebek, 1999, aus www.grin.com. RICHTLINIE 2003/ 94/EG DER KOMMISSION vom 8.Oktober 2003 zur Festlegung der Grunds¨atze und Leitlinien der Guten Herstellungspraxis f u¨ r Humanarzneimittel und fu¨ r zur Anwendung beim Menschen bestimmte Pr¨ufpr¨aparate, aus Amtsblatt der Europ¨aischen Union, L262/22 DE, vom 14.10.2003. Ripke, Joachim, Der deutsche Fussball geht ins Netz, aus: COMPUTERWOCHE extra, Ausgabe Nr. 2, Wege zum E-Business,Von Anwendungsinseln zu innovativen Architekturen, 23.03.2001. Robbe, Bj¨orn: SAN. Storage Area Network, Wiesbaden, 2004. Rohrschneider, Uwe: aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.1091. Rosen, Kenneth H., Rosinski, Richard R., Faber, James M., UNIX SYSTEM V RELEASE 4: AN INTRODUCTION, Berkeley, 1990. R¨oßler, Steffen, Risch, Wolfram: Projektmanagement-Einf u¨ hrung, aus: GPM/RKW Lehrgang Projektmanagement, PMF III – Wissensspeicher CD, Serie 1501/2000, 2000, S.119. Rundgang Speichersysteme, SAN und NAS kommen sich n¨aher, aus: COMPUTERWOCHE 11/2001, vom 16.03.2001, S. 52. Schelle, Heinz: Projekte zum Erfolg f u¨ hren, 4. Auflage, M¨unchen, 2004, S. 123. Schwartz, M., Computer-Communication Network Design and Analysis, PrenticeHall, Inc., Englewood Cliffs, NJ, 1977. Seiler, Martin, EMC schluckt Network Intelligence, in: COMPUTERWOCHE 38/ 2006, S. 10. Siemens (www.siemens.de), Presse Smith III, Philip H., Goldberg, Gabriel,The VM/ESA User’s and Applications Handbook, New York et.al., 1994. SNIA-Security, www.snia.org. SNW Europe 2006, Frankfurt September 2006, Tagungsunterlage Sollbach, Wolfgang , Bausteine f u¨ r die Client/Server Technik, Landsberg, 1996. Sollbach, Wolfgang: Storage Area Networks/Network Attached Storage. Hohe Datenverf u¨ gbarkeit durch Speichernetzwerke, M¨unchen, 2001. Sozialgesetzbuch (SGB) F¨unftes Buch (V) – Gesetzliche Krankenversicherung – (Artikel 1 des Gesetzes v. 20. Dezember 1988, BGBl. I S. 2477), zuletzt ge¨andert durch Art. 10 G v. 29. 6.2006 I 1402.

372

Literaturverzeichnis

Sozialgesetzbuch (SGB) Viertes Buch (IV) – Gemeinsame Vorschriften f u¨ r die Sozialversicherung – (Artikel I des Gesetzes vom 23. Dezember 1976, BGBl. I S. 3845) in der Fassung vom 23. Januar 2006 (BGBl. I S. 86 (466)), zuletzt ge¨andert durch Artikel 8 des Gesetzes vom 29. Juni 2006 (BGBl. I S. 1402) Sozialgesetzbuch, Drittes Buch (III) – Arbeitsf o¨ rderung [Artikel 1 des Arbeitsf o¨ rderungs-Reformgesetzes – AFRG] vom 24. M¨arz 1997 (BGBl. I 1997 S. 594) zuletzt ge¨andert durch Artikel 1 des Gesetz zur ganzj¨ahrigen Besch¨aftigung vom 24.April 2006 (BGBl. I 2006 Nr. 19 S. 926).. Speicher f u¨ r 25000 Dollar zu vermieten, aus: COMPUTERWOCHE 16/2001, vom 20.04.2001, S. 64. Standish Group, www.standishgroup.com Startup verspricht Interoperabilit¨at im Storage-Management, Sangate sprengt Plattformgrenzen zwischen Speichern, aus: COMPUTERWOCHE 28/2001, vom 13.07.2001, S. 9. Steward, Th.: Der vierte Produktionsfaktor, M¨unchen, Wien 1998. Studie Gartner, www.gartner.com. St¨urner, G¨unther, Oracle 7 A User‘s and Developer‘s Guide, London et.al., 1995. SUN (www.sun.com SuSE GmbH (Hrsg.), SuSE Linux 6.0, 13. Aufl. N¨urnberg, 1998. Symantec, Pressemitteilung, www.symantec.com. Tanenbaum, Andrew S., Computer-Netzwerke, 2. Aufl.,Amsterdam, 1990. Telekom (www.telekom.de), Presse Telekommunikationsgesetz Geltung ab 26.06.2004. Zuletzt ge¨andert durch Art. 3 Abs. 2 G v. 7.7.2005 I 1970, Bundesministerium der Justiz, 2004, 2005. Thome, G¨unter, Sollbach, Wolfgang: SOW Statement of Work, KONCOM/IT, Abschnitt Projektmanagement, 2003, S. 13 f. Veritas Pressemitteilung. R R Software Corporation (Hrsg.),VERITAS Cluster Server Agent DevelVERITAS oper‘s Guide, Version 1.2, 1999, P/N 100-001165. R R VERITAS Software Corporation (Hrsg.), VERITAS Cluster Server Enterprise Agents Istallation and Configuration Guide, 1999, P/N 100-001181. R R VERITAS Software Corporation (Hrsg.), VERITAS Cluster Server Enterprise Agents Release Notes, 1999, P/N 100-001182. R R VERITAS Software Corporation (Hrsg.), VERITAS Cluster Server Enterprise Agents Release Notes, Version 1.1, 1999, P/N 100-001182. R R VERITAS Software Corporation (Hrsg.), VERITAS Cluster Server Installation Guide, Version 1.1, 1999, P/N 100-001168. R R VERITAS Software Corporation (Hrsg.), VERITAS Cluster Server Quick-Start Guide, An Examle with NFS, Version 1.1, 1999. P/N 100-001205.

Literaturverzeichnis

373

R R VERITAS Software Corporation (Hrsg.), VERITAS Cluster Server Release Notes, Version 1.1, 1999, P/N 100-001170. R R VERITAS Software Corporation (Hrsg.),VERITAS Cluster Server Sun StorEdge A5000 Disk Array, Application Note, Version 1.0, 1999, P/N 100-001171. R R VERITAS Software Corporation (Hrsg.),VERITAS Cluster Server User‘s Guide, Version 1.1, 1999. P/N 100-001164. R VERITAS Software Corporation (Hrsg.),VERITAS?Volume Manager Storage Administrator, Administrator Guide, Release 3.0.1, 1999, P/N 100-000954. R VERITAS Software Corporation (Hrsg.), VERITAS?WHITE PAPER, Cluster Server Enterprise Availability Management, 1998. Verordnung u¨ ber den Schutz vor Sch¨aden durch R¨ontgenstrahlung (R¨ontgenverordnung – R¨oV) vom 30. April 2003 Washburn, K., and Evans, J.T., TCP/IP-Running a Successful Network, AddisonWesley Publishing Company, Wokingham, England, 1993.

W¨ohe, G¨unter, Einf u¨ hrung in die Allgemeine Betriebswirtschaftslehre, 13. Aufl., M¨unchen, 1978, S. 287. www. fraunhofer-studie.de www.aerzteblatt.de/v4/archiv www.basel-ii.info www.bitcom.org. www.computerwoche.de www.experton-group.de XSI Pressemitteilung. Zingel, Harry: Produktlebenszyklus und strategisches Marketing, Skript f u¨ r Zwecke der Aus- und Fortbildung, Version 3.00, 1996-2003, www.zingel.de.

Sachwortverzeichnis

Aberdeen Group, 346 Abgabe eines Angebotes, 119 Abgabenordnung, 299 Abgrenzung des technischen Aufwandes, 169 Ablauf der Aufbewahrungsfrist, 62 Abschluss der Servermigration, 126 Abschlussbericht, 123 Abschlussdokument, 141 Absicherungsmechanismen von Magnetplatten, 163 Abwendungs-Klassifizierung, 240 Accenture, 355 Access, XIII Access Control Entries, 277 Access Control List, 274, 276 Access Control Lists, 276 Accessibility Act, 313 Accessible Online Data, 323 Accounting, 64 Accountingfunktionalität, 160 ACE, 277 8-Bit-EPS, 310 802.1x, 279 ACL, 276, 278 ACL-Systemen, 276 ACLs, 274, 276 Adaptern, 126 ADIC, 318 Administration, 150, 151, 153, 158, 168 Administration der SAN-Plattformen, 315

Administration der Softwareinfrastruktur, 21 Administrations-VLAN, 181 Administrationsapplikationen, 30 Administrationsaufwandes, 151 Administrationsclient, 160 Administrationskonzept, 152 Administrationsleistung pro Speicheradministrator, 156 Administrationsnetz, 181 Administrationsplattform, 208 Administrationsprodukt, 320 Administrationsskripte, 210 Administrationssoftware, 160 Administrationssubnetz, 188 Administrationsumgebung, 208, 210, 320 Administrationsverfahren, 200 Administrationswerkzeug, 160 administrativen Bereich, 2 Administrator, 64 Administratoren, 5, 181 Adobe, 307 Adobe Reader, 312 Adobe Systems, 310, 311 Adressinformationen im Datenfeld, 285 Advanced-Encryption-Standard, 295 AES, 65, 295 AES-Algorithmus, 295 AES-Verfahren, 295 Agenten, 286 AICPA, 63

376

Sachwortverzeichnis

AIIM, 58 AIIM International, 314 AIIM-Modells, 343 AIX, 46, 161, 184, 188, 200 AIX-Server, 188 Aktiv-Aktiv-Cluster, 152 aktive Infrastruktur, 123 aktiven Projektmanagement, 123 aktives Projektmarketing, 123 Aktivieren der Platten, 176 Aktivierung der Spiegelseite, 210 Aktualisierung der Anwendungsdokumentation, 126 Aldus, 307 Alert Management, 264 alten Speicherplatz, 153 älterer Datenbestände, 153 Altsystemlandschaft, 141 Altumgebung, 119 amerikanischen Instituts der Wirtschaftsprüfern, 63 Analyse der Abläufe in K-Fällen, 297 Anbieter, 201 Anbietern, 119 Anbietervorteils, 15 Anbindung der Libraries, 167 Anbindung externen Speichers, 150 Anbindung von Plattenkapazitäten, 150 Anbindung von Speichersystemen, 154 Änderungen in der Systemumgebung, 20 Änderungsmanagement, 85 Anforderungen, 119 Anforderungen an das Informationsmanagement, 3, 4 Anforderungen an das Projektmanagement, 71 Anforderungen an die Datenhaltung, XIII Anforderungen an die Speicheradministration, 160 Anforderungen an die Speichersysteme, 159

Anforderungen des Pflichtenheftes, 201 Anforderungen des Pflichtenhefts, 119 Anforderungs-Compliance, 187 angebotenen Herstellerlösung, 202 Angebotsdokumente, 186 Angebotsfristen, 186 Angriffe, 5 Anpassung der Dokumentation, 123, 140 Anpassung im SAN, 177 Anschlusstechnik, 3 ANSI, 63 Ansprechpartner, 187 Ansätze zur Migration der Daten, 198 Anwendungs-Performance, 155 Anwendungsdaten, 41 Anwendungsdokumentation, 126 anwendungsspezifischen Archivierung, 317 any-to-any Datenreplikation, 322 Anzahl der Host Bus Adapter, 165 Anzahl der Knoten, 152 Appliance, 5, 318 Appliance Gedanke, 151 Application Consolidation solutions, 317 Application Solution, 317 Applikations-Server, 150 Applikationsmanagement, 158 applikationsspezifischen Arbeitspaketen, 126 Arbeitspaket Vorbereitende Arbeiten, 126 Arbeitspakete, 119, 126 Arbeitspakete zur Ausschreibung, 119 Arbeitspakete zur Durchführung der Auszeit für den FC-HBA Einbau, 126 Arbeitsplatz, 16 Arbeitsplatzrechner, 16 Arbeitsplatzrechnern, 62 Arbeitsplätze, 16, 25

Sachwortverzeichnis

Archivas, 324 Archivbestand, 158 Archivdaten, 70, 86, 88, 158, 167, 184, 253 Archive, 1 archivieren, 271 archivierte Daten, 324 archivierte Datenbestand, 158 archivierten Daten, 159, 302 Archivierung, 18, 24–26, 140, 153, 156, 158, 202, 233, 290, 298, 299, 301–303, 307, 311, 326, 346, 355 Archivierung von Mail-Dokumenten, 140 Archivierung von Vektorgrafiken, 311 Archivierungs, 26 Archivierungsbasierte Klassifizierung, 240 Archivierungsdauer, 25 Archivierungsebene, 53 Archivierungsformatanforderungen, 304 Archivierungsformate, 304 Archivierungshard- und -software, 15 Archivierungshardware, 25 Archivierungskonzept, 304 Archivierungslösungen, 157, 317 Archivierungsphase, 10, 15, 23–27, 29, 34 Archivierungsprozess, 303 Archivierungsprozessen, 303 archivierungsrelevante Buchführungs- und Datenschutzpflichten, 299 archivierungsrelevante Dokumente, 270 Archivierungssoftware, 24, 184, 202, 233, 345 Archivierungssystem, 254, 324 Archivierungssysteme, 316, 343 Archivierungstechnik, 25 Archivierungstests, 233 Archivierungsverfahren, 153 Archivierungsvorschriften, 29 Archivierungszeitraum, 10

377

Archivierungszwecke, 308 Archivkapazität, 158 Archivlösung, 202 Archivlösungen, 157 Archivmedium, 158 Archivmediums, 158 Archivordner, 302 Archivsatzes, 325 Archivspeichersystem, 158 Archivsystems, 158 Archivzwecke, 309 Arkivio, 346 Array, 286 Arrays, 5 ASCII-EPS, 310 Assessment, XI Association for Information and Image Management International, 314 Association for Suppliers of Printing, Publishing and Converting Technologies, 314 asymmetrischen Kryptosystems, 296 ATA/SATA-Plattenlaufwerken, 154 attackierenden IP-Adresse, 275 Attacks, 5 Attributausprägungen der Erstellungsphase, 18 Attribute von Verfügbarkeitsklassen, 259 Auditing, 64 auf SATA-Platten, 13 Aufbau von Wettbewerbsvorteilen, 16 Aufbewahrungs-Restzeit, 34 Aufbewahrungsfrist, 10 Aufbewahrungspflichten, 10, 302 Aufbewahrungsräumen, 62 Aufbewahrungszeiten, 346 Aufforderung zur Abgabe eines Angebotes, 119 Aufgabe des Backups, 290 Aufgabe des Information Lifecycle Managements, 35 Aufgabe des Qualitätsmanagements, 15

378

Sachwortverzeichnis

Aufrüstung des Archivmediums, 158 Aufteilung der Storagesysteme, 180 Aufwandschätzungen, 208 Ausfall, 152 Ausfall des primären Standorts, 209, 213 Ausfall des Primärspeichersystems, 172 Ausfall des Primärstandortes, 172, 177 Ausfall einer Zuleitung, 172, 173 Ausfall eines Frontend- Controllers des Speichersystems, 174 Ausfall eines Frontend-Controllers des Speichersystems, 172 Ausfall eines gesamten Rechenzentrums, 177 Ausfall eines HBA, 209, 211 Ausfall eines HBA’s, 172, 173 Ausfall eines primären Servers, 209, 212 Ausfall eines primären Speichersystems, 209, 212 Ausfall eines Servers, 172, 174 Ausfall eines Servers oder Cluster Members, 176 Ausfall eines Switches, 174 Ausfall eines Switches/Direktors, 172, 173 Ausfallzeit, 176, 351 Ausfallzeiten, 42 Ausfallzeiten minimiert, 13 ausgelagerten Dateien, 153 Auskunftsklassifizierung, 241 Auslagern, 153 Auslagerung älterer Datenbestände, 153 Auslagerungsmethode, 153 Auslastung, 160 Auslastungsgrenze der Speicherkapazität, 300 Auslastungsoptimierung, 16, 17, 19, 20, 22, 25 Auslastungsoptimierung in der Bewahrungsphase, 22

Ausschluss eines Single Point of Failure, 151 Ausschreibung, 119, 123, 150, 168, 183, 187, 188 Ausschreibung und Herstellerauswahl, XI, 71 Ausschreibungsphase, 165 Ausschreibungsunterlagen, 88, 119, 183 Austausch defekter Komponenten, 152 Austauschformat, 310 Auswahl der Systemlieferanten, 162 Auswahl der Technologien und Verfahren, 201 Auswertung von Archivdaten, 303 Auszeichnungssprache, 305 Auszeit, 126 Authentifizierung, 64 Authentizität, 157 Authentizität der Daten, 296 Authentizitäts-Policies, 325 Automatische Aktivierung des Remotespiegels, 159 Automatische und manuelle Synchronisation des Remotespiegels, 159 automatischen Migration Policies, 324 automatischer Serviceruf, 152 automatisiert inventarisiert, 119 automatisierte Business Intelligence Prozesse, 24, 27 Automatisierung, 197 Automatisierung der Administration, 8 Automatisierung der Datenmigration in der Tiered Storage Umgebung, 318 Automatisierung von Policies, 318 Automatisierung von Produktionsabläufen, 156 Automatisierung von Prozessen, 86 Autorisierung, 20, 64, 270 Availability, 5

Sachwortverzeichnis

Backend des Speichersystems, 164 Backup, X, 62, 65, 123, 155, 180, 210, 231, 238, 290, 291, 316, 324, 346 Backup and Data protection based on Hot Site – Server displacement, 298 Backup and Data security without a Hot Site, 298 Backup and Protection by Hot Site – Server out of Pool, 298 Backup eines Produktionssystems, 209, 215 Backup Medium Band, 294 Backup Medium Festplatte, 293 Backup Services, 324 Backup und Restore einzelner Dateien und Verzeichnisse mit Snapshots, 231 Backup und Restore kompletter Volumens mit Snapshots, 232 Backup über SAN, 123 Backup- und Recovery Strategien, 6 Backup- und Restore-Lösungen, 315 Backup-/Restore, 199 Backup-/Security-/ECM, 318 Backup-Applikationen, 296 Backup-Architekturen, 295 Backup-Client, 180 Backup-Clients, 179 Backup-Daten, 294 Backup-Devices, 155, 196 Backup-Klassen, 291, 293 Backup-Kontrollpunkte, 155, 196 Backup-Kosten, 347 Backup-Medien, 294 Backup-Medium, 292 Backup-Prozess, 253 Backup-Server, 165, 179, 180 Backup/Restore-Kapazitäten, 187 Backupkonzept, 179 Backups, 179, 296, 298, 321 Backupserver, 209 Backupzeit, 179 Balance Scorecard, VII

379

Balance zwischen Storage-Ressourcen und Sicherung der Daten, 291 Band-Backups, 293 Bandlaufwerke, 154, 285 Bandspeichergeräte, 154 Bandsysteme, 294 Basel II, IX, XIII, 7, 63, 158, 355 Baseline TIFF, 307 Baseline-Einschränkungen, 308 Baseline-Spezifikationen, 308 Basisplan, 126 Basisprojektplan, 112, 119 Basisstandards, 165 BCG, 355 BCV’s, 123 Beauftragung, 186 Begehung, 162 Benachrichtigung per Mail, 160 Benutzerautorisierung, 18, 21, 24, 27 Benutzerrolle, 276 Beratungshäuser, XII Berechtigungskonzept auf Benutzerund/oder Gruppenbasis, 160 Berechtigungskonzept über User/Gruppe, 162 Bereich Business Intelligence, 1 Bereitschaft, 32 Bereitstellung der Infrastruktur- und Netzwerkkomponenten, 123 Bereitstellung von Informationsservices, V Berichtswesen, 84, 108, 112 Beschaffen, Verarbeiten und Speichern von Informationen, 45 Beschreibung der SLA Module, 169 Beschreibung der Zielkonfiguration, 119 Beschreibung der Zielkonfiguration in der Neuumgebung, 119 Besprechungen, 82 bessere Skalierbarkeit, 152 besseren Reaktionszeiten für die Anwendungen, 155 best practice, 289 best practices, 72

380

Sachwortverzeichnis

Best-Practises, 7 Best-Praxis-Erfahrungen, 56 Bestandsaufnahme aller Server/, 188 Bestandteil der Ausschreibungsunterlagen, 119 beteiligten Hersteller, 202 Betrieb von Archivsystemen, 158 Betrieb von Stand-Alone Systemen, 181 betrieblichen Notwendigkeiten, V Betriebsnebenzeiten, 32 Betriebsprüfungen, 302 Betriebssystem, 19 Betriebssystem mit dem höchsten Wachstum, 19 Betriebssystem-Support für die Administration, 160 Betriebssysteme, 19, 161 Betriebssystemeigenschaften, 188 Betriebssystemen, 208 Betriebssystemobjekt, 277 Betriebszeit, 32 Betroffenheitsanalyse, 90 Bewahrungsphase, 10, 15, 21, 23, 24, 29, 141 Beweismittel bei der Dokumentation betriebswichtiger Vorgänge, 300 beweisrechtlichen Positionierung, 300 Bewertung der Angebote, 208 bewusste oder unbewusste logische Zerstörung der Daten, 173 Bewusstsein für Qualitätssicherung, 66, 209 BI, 2, 7 BI-Architektur, 2 BI-Systemarchitektur, 2 Bieterauswahl, 186 Bilddaten, 307 Bildung von Storageklassen, 237 Bindeglied zwischen dem Auftraggeber und dem Serviceleister, 169 BITKOM, 41 Bitmap, 309 Blind-Exchange-Fähigkeit, 313

Blockchiffre, 295 blockorientiert, 154 blockorientiertem Zugriff, 151 Blocksicherungskonzeptes, 180 Blockzugriff, 151 Blowfish, 65 Bluefin/SMI-S, 150 BMP, 309 Booten, 177 Boston Consulting Group, 355 Bounding-Box, 310 BPM, 2 Brandabschnitte, 181 Brandschutz, 123 Brandschutzwände, 195 Brocade, XI, 161, 347 Brocade Tapestry, 350 Brute-Force-Angriffe, 295 BS 7799, 287, 288 BSI, 75 BSI-Grundschutz, XIII Budgetklarheit, 7 Bundesagentur für Arbeit, 66 Bundesamt f u¨ r Sicherheit in der Informationstechnologie, 364 Bundesamt für Sicherheit in der Informationstechnologie, IX Business Continuity, IX, XIII, 6, 22, 25, 196 business continuity, 5 Business Continuity der Geschäftsanwendungen, 155 Business Continuity Management, 20, 24, 27, 141 Business Continuity Umfeld, 347 Business Critical Data, 322 Business Intelligence Prozesse, 18, 21 Business Intelligence Systemen, 7 Business Performance Data, 61 Business Performance Management, 2 Business Process, 41, 50 Business Process Management, 355 Business Recovery-Plänen, 298

Sachwortverzeichnis

Business Transaction based Klassifizierung, 242 Business- und TechnologieFramework, 5 Business-Continuity, 155 Business-Process-Anforderungen, 61, 235 Busniess Continuity Plan, 246 Bypassed, 285 Bänder, 188 C-Clips, 324 CA, 345, 346 Caminosoft, 346 Campus, 278, 290 Capability Maturity Model, 77 Capture, 343 Carrier-Backbone-Netze, 278 CAS, 202, 253, 290, 318 CAS-Lösung, 315 CAS-Magnetplattensysteme, 159 CAS-Systems, 233 CAS-Umgebung, 233 CCITT, 308 CDF-Referenz, 325 CDP, 248, 277 CENTERA, 315, 318 CentricStore, 346 Certified Information System Auditor, 77 Change Management, 27, 126 Change Management Prozess, 24, 27, 126, 140 Change Management Verfahren, 126 Change Reques, 126 Change Request, 85, 126 Change Verfahren, 126 Change-Management, 196 Chargebacks, 346 Chargebacks für Datenbewegungen, 346 Chiffreschlüssel, 5 chiffrieren, 296 CIFS, 325, 348 CIFS-Protokolle, 150

381

CIFS/SMB, 150 CIS, 344 Cisco, 161, 250 Cisco Systems, XI, 278 CLARiiON, 315 CLI, 160 Client, 153 Client Rechnern, 150 Client-Online-Backup, 31 Clients, 150 Clone Platten, 6 Clones, 123 Cloning, 13 Cluster, 123, 126, 152, 176, 177 Cluster-Member, 152 Cluster-Memberknoten, 324 Cluster-Members, 152 Cluster-Softwareeinsatz, 22, 25 Cluster-Verfahren, 152 clusterrelevante Konfigurationen, 152 Clustersystem, 177 Clustersysteme, 13, 177 Clustersystemen, 152, 200, 255 CMM, 77 COBIT, 7 Cold–Standby-Systems, 177 Cold-Standby-System, 176 Cold-Standby-Systems, 179 Command Central Storage, 346 Commandline, 210 Commandline-Interface, 160 Commandline-Skripte, 210 Commodity, 202 Compliance, 7, 21, 24, 64, 112, 140, 233, 321, 323, 324 Compliance Anforderungen, 27 Compliance Angebot, 187 Compliance Systeme, 343 Compliance Tabelle, 186 Compliance und Message Managements, 343 Compliance-Daten, 290 Compliance-Lösung, 186 Compliance-Manager, 345 Compliance-relevante Daten, 270

382

Sachwortverzeichnis

Compliance-Tabelle, 186 Compliance/Datensicherheit, 291 Complianceforderung, 18 CompuServe Inc, 309 Computacenter Compunet, 355 Computer Associates, 250, 345 Computerviren, 181 Computerwoche, IX Concentrator, 275 Configuration Management, 20, 24, 27, 141 Connectivity, 349 Content Addressed Storage, 253, 290 Content Adressable Storage, 29, 202 Content Adressable Storage Magnetplattensysteme, 24 Content Adressing, 324 Content Aware, 324 Content basierte Klassifizierung, 270 Content Filter, 274 Content Services, XIII Content-Management, 58 Content-sensitiven Klassifizierung, 318 Content-sensitiven Klassifizierung und Analyse von Datenzugriffen und Suchen, 318 Continous-Data-Protection, 277 Control Objectives for Information and related Technology, 7 Controlling, 97, 140 Controllingpersonal, 181 COPY-Verfahren, 200 CPIO-Kommando, 200 CRC-Prüfverfahren, 65 Critical Data, 61 CRM, 1, 29 CRM-System, 185 CRM-Systems, 21 Crossbar Switch, 321 CSC Ploenzke, 356 Customer Relationship Management, 1 DAE’s, 161

Dark-Fibre Bereich, 167 DAS, 255, 273, 321 Data Classification Study, 322 Data Lifecycle, 41 Data Lifecycle Management, 321 Data Lifecycle Modell, 32 data loss, 65 Data Management Services, XIII Data Protection Events, 244 Data Protection InitiativeKlassifizierung, 244 Data Protection Service, 324 Data Protection Window, 244 Data Warehouses, 2 Data Warehousing, 154 Data-Warehouse-Systeme und Supply Chain Management, 1 Database solutions, 317 Datamover, 179, 180 Datei-Referenzen, 153 Dateien, 150 Dateispeichermanagement, 350 Dateisysteme, 150 Daten- und Server-Migration, 71 Daten-Backup, 292 Daten-Cloning, 22, 25 Daten-Integrität, 64 Daten-Managements, 346 Daten-Sharing, 150 Datenarchivierung, 157 Datenarchivierung im Fileservicebereich, 153 Datenarchivierungssystem, 303 Datenarchivierungssysteme, 303 Datenbank, 153 Datenbanken, 154, 158, 251, 291 Datenbankteam, 126 Datenbereichen, 156 Datenbestand, 158 Datenbestände, 153 Datenbestände von Unternehmen, 1 Datenbeständen, 155 Datendiebstahls, 62 Datenhaltung, 153 Datenhaltungssysteme, 303

Sachwortverzeichnis

Datenintegrität, 158 Datenklasse, 270 Datenklassen, XI, 86, 119 Datenklassifizierung, 169, 238, 251, 290, 292, 322 Datenklassifizierung der Produktivdaten, 184 Datenklassifizierung der Serversysteme, 189 Datenklassifizierung gemäß IDC, 324 Datenklassifizierungen, 60 Datenklau, 290 Datenkompremierung, 275 Datenkonsolidierung, 349 Datenlöschung, 290 Datenmanagementanbieter, 5 Datenmanagementfunktionen, 238 Datenmenge, 153 Datenmigrations- und Verfügbarkeitsoptionen, 154 Datenmigrations-Tool, 348 Datenmissbrauchs, 62 Datenplatten, 169 Datenreduktion, 4 Datenreplikation, 238 Datenschutz, XIII, 18, 21, 24, 27 Datenschutz- und Geheimhaltungserklärung, 187 Datensicherheit, 18, 21, 24, 27, 62, 302 Datensicherheit für BackupVorgänge, 295 Datensicherheitskonzept, 292 Datensicherung, 42, 153, 273, 299 Datensicherung von PC’s, 31 Datensicherungsstrategien, 13 Datensicherungsumgebungen, 295 Datensicherungsverfahren, 15 Datenspeicher vernetzen, 63 Datenspeicherbereichs, 153 Datenspeicherinfrastrukturen, 274 Datenspeichern, 292 Datenströme im SAN, 179 Datentypen, XIII Datentypisierung, 185, 233, 324

383

Datentypisierungs, 233 Datenverlagerungen, 350 Datenverlust, 24, 140, 292, 293 Datenverlust ausgeschlossen, 13 Datenverwaltungs-DienstleistungenKlassifizierung, 244 Datenvolumen, 20 datenwertorientierte Datenhaltung, 24, 27 Datenzugriff im SAN, 154 Datenübertragungsraten beim Backup, 297 Datums-Klassifizierung, 245 Decapsulation, 279 Decru Lifetime Key Management, 5 dedizierte Einheit, 152 dedizierten Fileservern, 151 dedizierten Routern, 151 dediziertes Backupnetz, 188 Deep Archive, 29 definierten Aufbewahrungszeiten, 27 Definition der Projektziele, 86 Definition der Schutzklassen, 163 Definition der Sicherheitspolitik, 288 Definition des Umfangs des ISMS, 288 Degenerationsphase, VIII Deliver, 343 Delivery Management, 91, 92, 97, 123, 126 Delivery Management zum Kunden, 123 Delivery Managern, 97 Dell, XI dem Lifecycle Management, 347 DeMarco, 364 Denial of Service, 290 der Security Division, 316 DES, 65 des Informations-Lebenszyklus, 30 des ITIL Service Managements, 23, 140 Desaster Recovery, 253 Desaster Recovery Gründen, 13

384

Sachwortverzeichnis

Desaster Recovery Lösung der Datenhaltung, 181 Desaster Recovery Services, 324 Desaster-Falls, 245 Desaster-Rechenzentren, 13 Developer Kits, 5 Device Masking, 200, 201 Device-Masking, 200 Device-Steuerung, 197 Devices, 154 dezentralen Datenspeicherung, 287 dezentraler Datenhaltung, 63 Dial-Out-Funktionalität, 161 Dienstleistungs-Klassifizierung, 245 Dienstleistungsgesellschaft, 3 differentialer Momentaufnahmen, 248 digitale Archive, 157 digitale Archivierung, 156 digitalen Archivierung, 157 digitalen Signaturen, 313, 325 digitalen Signaturverfahren, 303 digitalen Unterlagen, 302 digitaler Unterlagen, 299 digitaler Zertifikate, 296 Direct Attached Storage, 255, 273 Direct-Attached-Modell, 154 Direktanbindung, 154 direkten Remote-Zugriff, 275 Direktor-Ports, 167 Direktoren, 126, 161, 162, 165, 167, 208 Disaster Recovery, IX, 88, 290, 297 Disaster Recovery-Klassifizierung, 245 Disaster Recovery-Planung, 298 Disaster Tier 3, 298 Disaster Tier 5, 298 Disaster Tier 6, 298 Disaster Tier 7, 298 Disaster Tier 8, 298 Disaster-Recovery, 155, 196, 297 Disaster-Recovery-Lösungen, 155 Disaster-Tier 0, 298 Disaster-Tier 1, 298

Disaster-Tier 2, 298 Disaster-Tier 4, 298 Discretionary Access Control:, 276 Disk, 5 Disk-Array-Einschübe, 161 Disk-Arrays, 285 Disk-Libraries, 29, 179 Disk-to-Disk, 324 Disk-to-Disk-Archivierung, 350 Disk-to-Tape, 324 Disksubsystem, 285 Distributed Lösungen, 151, 152 Distribution der Anwendungen, 119 DLM Konzeptes, 2 DMS, 58, 158, 318 DMTF, 57 DMX, 29, 315 DMX-Speichersystemfamilie, 315 Document Structuring Conventions, 311 Documentum, 315 Dogs, 35 Dokumentation, 123, 126 Dokumentation der Disaster Recovery-Prozeduren, 298 Dokumentation der Netzwerkgegebenheiten, 188 Dokumentation der SystemKonfigurationen, 298 Dokumentation und Trecking der Bänder, 298 Dokumentationen, 66 Dokumentationstool, 126 dokumentenechte Langzeitspeicherung, 26 dokumentenechte Wiederherstellung, 26 Dokumentenformate für die Archivierung von Mail-Dokumenten, 140 Dokumentenmanagement, 58 doppelte Backplane, 168 DoS-Attacken, 273, 290 Downtimeplanung, 126 Downtimes, 322

Sachwortverzeichnis

DPW, 244 DR-Fall’s, 297 DR-Site, 297, 298 drahtlosen Zugang, 278 Drives, 157 DSC, 310 DSC-Kommentare, 310 DSL-Zugänge, 31 Dublettenreduktion, 158 Duplizieren, 155 Durchführung der Ausschreibung, 88, 119, 150 Durchführung der Migration, 126 Durchführung der Serverumzüge, 123 Duty-Cycle, 293 DWDM, 123, 126 DWDM-Netzwerk, 123 Dynamic Multipathing Software, 173 dynamische Hot-Spares, 160 Dynamische Klassifizierungskonzepte, 251 dynamischen Speicherprovisionierung, 286 dynamischer Pfad-Failover, 160 E-Mail, 299–301 e-Mail, 158 E-Mail-Accounts, 2 E-Mail-Anwendungen, 251, 292 E-Mail-Archivierung, 345 E-Mail-Server, 53 E-Mails, 12, 41, 345 EAP, 279 Ebenen der Virtualisierung, 49 ECC, 22, 25, 315 Eckpunkte für die Auswahl einer NAS Lösung, 151 ECM, 58, 59, 158, 290, 343 ECM-Lösungen, 343 ECM-Markt, 316 ECM-Software, 343 ECM-Systeme, 156 ECM-Systems, 158 ECSON, 324

385

Edge Label Switch Router, 278 Edge LSRs, 278 Edge Switch Access Control List, 278 EDS, 253, 356 EDV, 3 effizientes Management, 156 EGA, 57 Egress Router, 278 eigenständige Service Areas, 188 eigenständige Teilprojekte, 126 Einbau von FC-HBA’s, 126 Einbruchversuch in ein System, 275 Einbrüche ins Firmennetz, 290 Eindringlings-Warnsystem, 62 eines Cluster-Members, 152 Einfluss auf die Datensicherung, 153 Einflüsse auf das Releasemanagement, 126 Einführung eines geschäftsorientierten Informations-Managements und des Information Lifecycle Managements, 69 Einführung jedes ILM-Konzeptes, 44 eingeschränkte Skalierbarkeit, 152 eingeschränkte Skalierbarkeit des Gesamtsystems, 152 Eingriff in ihre Arbeitsfähigkeit, 153 Einhaltung der Compliance Anforderungen, 7 Einhaltung der Compliance der Datenhaltung, 86 Einhaltung der gesetzeskonformen Aufbewahrungsfristen, 302 Einhaltung der SLA’s, 123 Einhaltung der vereinbarten Meilensteine, 82 Einsatz von Clustern, 152 Einsatz von externen Speichersystemen, 165 Einsatzmittelplanung, 106 Einsatzszenarien, 14 Einsatzzweck einer Firewall, 274 Einschränkung des zur Verfügung stehenden Datenspeicherbereichs, 153

386

Sachwortverzeichnis

Einsparungen, 4 Einzel-Server/Cluster-Migrationen, 126 Einzelbewertung, 208 Einzelkriterien, 208 Einzelkriteriums, 202 Einzelunternehmen, 208 Electronic document file format for long-term preservation, 312 elektronische Archivierung, 58 elektronische Dokumente, 298 elektronische Erklärungen, 299 elektronische Rechnung, 299 elektronische Repräsentationen papierner Geschäftsdokumente und Belege, 298 elektronische Signatur, 325 elektronischen Archiven, 303 elektronischen Dokumenten, 299 elektronischen Signaturverfahren, 303 elektronischen Unterschrift, 296 elektronischer Informationsträger, 303 elementarer Katastrophen, 14 ELSR, 278 Email Archivierung, 343 Email solutions, 317 Embedded Applications, 321 EMC, 249, 250, 344, 346 EMC Control Center, 315 EMC Documentum Content Intelligent Services, 344 EMC2 , 94, 315, 316 EMC2 CLARiiON, 29 EMC2 TimeFinder, 29 EMC2 , XI EMC2 , 141, 202, 233, 316–318, 346, 355 EMC2 CENTERA, 29 EMC2 ’s, 22, 25 EMEA, 346 EMULEX, 161, 165 Encapsulated Postscript, 310 End-to-Site-VPN, 275

Endanwender, 153 Engenio, 250 Engpass Tapedrives, 180 Enron, 7 Enterprise Content Management, 58, 290, 343 Enterprise Content Management solutions, 317 Enterprise Content Management) Systeme, 157 Enterprise Klasse, 17, 20, 23, 25, 29, 316 Enterprise Segment, 320 Enterprise Speichersysteme, 167 Enterprise Storage, 315, 318 Enterprise und Midrange Storage Systemen, 202 Enterprise Vault, 346 Entscheidungsgremium, 81 Entscheidungskriterien zur Hardware Library, 202 Entscheidungskriterium, 202 Entscheidungsmatrix, 119, 123 Entscheidungsmatrix zur Anbieterauswahl, 208 Entscheidungsmatrix zur Integration in ein hochverfügbares TSM, 208 Entscheidungstabelle, 202 Entscheidungstabelle für die Auswahl der Datensicherungstechnik, 208 Entscheidungstabelle für HardwareStorage, 202 Entscheidungstabelle zur Anbieterauswahl, 201 Entscheidungsträger, 44 Entscheidungsunterstützung, 2 Entwicklung der Ausschreibungsunterlagen, 119 Entwicklung der Informationsspeicherung, 4 Entwicklung des Pflichtenhefts, 119 Entwicklung des Storage Marktes, 326 Entwicklungsschritte der IT, 9

Sachwortverzeichnis

EPS, 308, 310, 311, 313 EPS-Daten, 310 EPSI, 310 Erfassung unstrukturierter Daten, 12 Erfassungsphase, 17 Erfüllung der Compliance Anforderungen, 140 Erfüllung gesetzlicher Vorschriften, 158 Erfüllungsgrad, 208 erhöhtem Managementaufwand, 157 erhöhter Security-Anforderungen, 278 Erkennen eines Einbruchsversuches, 275 Erkennen von Inhalt zu Datenschutz und Compliance, 318 Ermittlung der SAP-Datenbanklast für einen Testvergleich bei Inbetriebnahme des SAN, 232 Ermittlung des Gesamtbedarfs an Speicher, 163 Ernst & Young, 356 ERP, 1 ERP-Systeme, 13, 29, 154 ERP-Systems, 21 Ersatzservers, 174 Ersatzsystem, 177 Erstellen eines Snapshots, 231 Erstellung, 29 Erstellungs, 10 Erstellungsphase, 14, 16, 18, 34 Erstellungszeitpunkt, 12 ersten drei InformationslebenszyklusPhasen, 21 erweiterten Zugriffssteuerung, 276 Erweiterung des Filesystems, 230 ESCON, 321, 322 Eskalationsbehandlung, 83 Eskalationsstufe 2, 83 Eskalationsstufe 3, 83 Eskalationstufe 1, 83 Essential Data, 61 EU-Richtlinie, 7

387

Event Log, 152 Eventzyklen, 22, 25 Exabytes, 18 Exchange, 199, 345 Exchange-Servern, 188 Exit-Champion, 78 Experten Group, IX ext2, 276 ext3, 276 Extensible Access Method, 249 Extensible Authentication Protocol, 279 eXtensible Markup Language, 306 externe Festplattensysteme, 154 externe Speichermanagement, 152 externe Speichermedien, 13 externe Speichersysteme, 154 externen Speichers, 150 externen Speichersystemen, 161, 255 externer online Speicher, 151 externer Plattenkapazitäten, 150 externer Speichersubsysteme, 4 externes Speichersystem, 151 Fabric, 285 Fabric-Umgebung, 285 Fail-Save-HBA, 225, 226, 229 Failover, 152, 350 failover, 351 Failover-Gruppen, 152 Failoverkonzept, 172, 173 Failoverstrategien, 199 Failovertests, 227 Failovertests Cluster, 223 FalconStor, 296 Falconstor, 210 falsche Bilanzen, 7 falschen Kopie, 18 FAN, 347, 348 FAN-Konzept, 348 Fan-Out, 161 FAS-Familie, 318 FC, 63, 273, 274 FC Platten, 154 FC-Festplatten, 253

388

Sachwortverzeichnis

FC-HBA’s, 126 FC-Laufwerke, 293 FC-Platten, 293 FC-Protokoll, 273 FC-SANs, 63 FC-Schnittstelle, 293 FC-SP, 63 FC-Speichersysteme, 318 FC-Switch, 286 FC-Technik, 253 FC-Verkabelung, 277 FCIP, 150, 154, 273 FCSW Devices, 196 Feedbackrunden, 112 Fehlerrisikos, 141 Ferndiagnose, 161 Festplatte, 292 Festplatte des Notebooks, 2 Festplatten, 19, 294 Festplatten IDs, 200 festplattenbasierendes Archivmedium, 158 Festplattenkapazität, 4 Fiberchannel Support, 161 Fibre Channel, 63, 126, 154, 274, 321, 324 Fibre Channel Controller, 154 Fibre Channel Direktoren, 168 Fibre Channel FCP, 285 Fibre Channel HBA’s, 199 Fibre Channel SAN’s, 154 Fibre Channel SAN-Ports, 168 Fibre Channel Switched Fabric, 182 Fibre-Channel, 167 Fibre-Channel-Protokoll, 273 Fibre-Channel-spezifische SecurityProtokoll, 63 Fibre-Channel-Switches, 285 Fibre-Festplatten, 180 Fibre-Miniswitch, 195 FICON, 321, 322, 324 File Area Networking, 347, 348, 350 File Lifecycle Management, 347, 350 File Lifecycle Management-Ansatz., 350

File Lifecycle Manager, 350 File Serving Devices, 348 File Sharing, 151 File- und Blockzugriff, 151 File-basiertes Information Lifecycle Management, 347 File-Management- und Kontrollservices, 349 File-Managementlösung, 350 File-System-Archivierung, 251 Filer, 179, 200 Filerbereich, 180 Fileserver, 150, 153 Fileserver-Funktionalität, 151 Fileserverbasis, 153 Fileservern, 151 Fileservice, 151, 176 Fileservicebereich, 153 Fileservices, 158 Filesystem, 158 Filesystemkopie, 200 finalen Vertragsverhandlung, 123 Finanzinstituten, 3 Finanzmittelplanung, 107 Firewall, 62, 274 Firewalls, 274 Firewalltechnologie, 275 Firmware, 161, 173, 286 Firmware Releasestände, 165 Firmwarefehlern, 173 Firmwarefehlern im Bereich der Speichersysteme, 173 Firmwareupdates, 162 Firmwareupgrades, 168 Fixed Content, 324 fixed Content, 24 fixed content, 25, 323 Fixed Content Archivierungs- und Dearchivierungssoftware., 26 Fixed Content Objects, 324 Fixed-Content, 157 Fixed-Content Bereichen, 156 Flexibilität der Geschäftsumgebung, 154 FLM, 350

Sachwortverzeichnis

Folgen einer Verletzung der Archivierungspflicht, 302 formatiertem Text, 310 Frage- und Antwortstunde, 119 Fragen zur Ausschreibung, 187 Frauenhofer-Studie, VI FreeBSD, 276 freies Format, 304 Freigabe der Kapazitäten, 126, 140 Freigabe muss die Dokumentation, 126 Fremdunternehmen, 123 Frontend-Controller-Port, 200 Frontenddirectoren, 161 FSC, XI, 184, 318 FTP-Server-Prozess, 276 Fujitsu Siemens Computers, XI, 318 Fujitsu-Siemens, 346 Full-Backup, 201 15-Zoll Format, 3 Funktionsfähigkeit, 126 Fälschungssicherheit, 303 führenden Speichersystemanbietern, 2 ganzen Seitenlayouts, 310 garantierte Bandbreiten, 275 garantierte Wiederherstellzeit, 292 GB, 3 GBIC’s, 162 GDPdU, 299, 302 GdPdU, XIII GeBüV, 303 Gefängnis, 7 geheimen Schlüssel, 296 geheimen Schlüssels, 296 Geheimhaltungserklärung, 187 Generalisierter Testplan, 210 Generationenmodell, 239 Generische Klassifizierungsansätze, 239 genormte, integrierte Verschlüsselungslösungen, 5 GEOSPAN-Cluster, 210

389

geringe Wertschätzung der eigenen Daten, 62 geringeren TCO, 155 geringste Administration, 157 Gesamtbedarfs an Speicher, 163 Gesamtkosten, 155 Gesamtprojektleitung, 126 Gesamtprojektplan, 83 Geschäfts-Policies, 271 geschäftsbezogene Dokumente, 15 Geschäftsfeldklassifizierung, 246 Geschäftskontinuität, 297 Geschäftskorrespondenz, 300, 301 geschäftskritischen Informationen, 6 Geschäftsprozesse, XII Geschäftsprozesse des Unternehmens, VIII geschäftsvorfallbezogener kaufmännisch relevanter Dokumente, 10 geschäftsvorfallrelevanter Informationen, 27 geschäftszentrierten IT-Prozesse, XI Gesellschaft für Projektmanagement, 73 Gesetz zur Kontrolle und Transparenz im Unternehmensbereich, XIII Gesetze, 299 Gesetze und Richtlinien für die Datensicherung, 299 Gesetzesbereichen, 157 gesetzeskonforme Archivierung von unveränderlichen Daten, 325 Gesetzgeber, 7, 157 Gesetzgebungen, 27 gesetzlich zwingenden Dokumentation von Geschäftsvorfällen, 301 gesetzliche Anforderungen, 158 gesetzliche Auflagen bezüglich des Datenschutzes, 62 gesetzlichen) Anforderungen, V gespeicherten Informationen, 150 gespiegelten Systemen, 20 Gestaltung der IT-Services, 7 gesteigerte Skalierbarkeit, 155

390

Sachwortverzeichnis

gesunkene Wiederverwendungswahrscheinlichkeit, 22 gesunkenen Informationswert, 22 getrennte Rechenzentren, 195 getrenntes Administrationsnetz, 181 Gewichtigkeit für die Entscheidungsfindung, 202 Gewichtung der einzelnen Kriterien, 208 Gewährleistung der Compliance, 25 Gewährleistung der Hochverfügbarkeit, 199 Gewährleistung direkter Zugreifbarkeit, 20 Gewährleistungsfristen, 10 GGF, 57 GIF, 308, 309 Gigabit Ethernet-Netzwerk, 154 GIS-Systemen, 185 Global Namespace, 350 Global Namespace Konzept, 350 Global Namespace Lösung Tapestry, 351 Global Sourcing, 15 GNOME, 276 GOBS, 299, 301, 302 GoBS, XIII GPM, 73, 79 GPM/IPMA, 78 GPO’s, 152 Grad der Compliance, 209 Grad der Compliance der Unternehmens-IT, 7 Grade der Compliance, 198 Grads an Datensicherheit, 292 Gramm-Leach-Bliley, 274 Graphics Interchange Format, 309 Greenfield Approach, 239 Grundsätze ordnungsmäßiger DVgestützter Buchführungssysteme, XIII Grundsätzen ordnungsgemäßer Buchführung, 301

Grundsätzen ordnungsgemäßer DVgestützter Buchführungssysteme, 299 Grundsätzen zum Datenzugriff und zur Prüfbarkeit originär digitaler Unterlagen, 299 Gruppenlaufwerke, 154 gängigen Sicherheitsstandards, 276 gängigen Systemlieferanten, XI günstigere Medien, 15 Hackerangriffe, 63 HACP, 324 Haftung, XII Haftungsfolge, 299 Haftungsrisiken, 66, 209 Handels- und Steuerrechts, 301 Handelsgesetzbuch, XIII, 299 handelsrechtlichen und steuerrechtlichen Grundsätzen, 301 Handelsverkehr zwischen Kaufleuten, 299 Hard-Zoning, 285 Hardware, 208 Hardwareausfall, 176 Hardwareausfalls eines Servers, 174 Hardwarehersteller, 154 Hardwareinfrastruktur, 14, 16, 19, 25 Hardwareinfrastruktureffizienz, 18, 24, 27 Hardwarekomponenten, 123 Hardwarekonfiguration für die SANLösung, 185 Hardwareplattform, 324 HASH-Algorithmen, 325 Hash-Algorithmus, 65 Hash-Wert, 296 Haupt-Backup-Server, 195 Havariefall, 195 HBA, 165, 255 HBA-Ports, 167 HCAP, 324–326 HCMP, 202 HDAs, 13 HDS, IX, XI, 29, 94, 141, 281, 320

Sachwortverzeichnis

Henley basiertes Projektmanagement, 74 Henley Projectmanagement Course, 74 Hersteller, 5, 119, 123, 141, 152, 202, 315 Hersteller im Speichermarkt, 315 Hersteller-Q&A’s, 119 Herstellerangaben, 202 Herstellerangebote, 119 Herstellern, 119, 320 herstellerspezifische Datenbanken, 183 Herstellerunabhängigkeit, 304 heterogene Speicherumgebungen, 322 heterogenen Altsystemlandschaft, 141 heterogenen Datenmanagement, 350 Hewlett Packard, 94, 316, 317 HGB, XIII HiCommand Administrationsframework, 320 HiCommand Software, 320 HiCommand Tiered Storage Manager, 324 Hierarchic Storage Management, 153 Hierarchical Storage Management, V, 239, 290 hierarchischen Speichermanagement, 346 Hierarchisches Storage Management, 251 High automated, business-integrierte Solution – Server exklusiv/shared, 298 High-Cost, 351 High-End Bereich, 316 High-Performance-Systeme, 184 hinreichend Server- und Speichersystemkapazität, 20 Hinzufügen eines Filesystems, 230 HIPAA, 274 Historienwerte, 160 Hitachi, 249 Hitachi Content Archive Platform, 324, 325

391

Hitachi Content Archiver Software, 324 Hitachi Data Systems, IX, XI, 94, 202, 250, 281, 316, 317, 320, 322, 324, 326 Hitachi Universal Volume Manager, 322 Hitachi-Produktlinie, 320 Hitachi-SANs, 320 hochausfallsicheren Produktivsysteme, 13 hochbelastete Storageports, 199 hochbelasteten Servern, 199 Hochperformante Speicheranwendungen, 29 Hochproduktivdaten, 70, 86, 88, 184 Hochsicherheitssystemen, 276 hochverfügbare Daten, 167 hochverfügbare Server- (Cluster), 25 hochverfügbare Server-(Cluster), 22 Hochverfügbare Services, 169 Hochverfügbare Speichersysteme, 323 hochverfügbaren Archivsystemen, 88 hochverfügbaren SAN, 196 hochverfügbaren und abgesicherten Netzwerkinfrastruktur, 26 Hochverfügbarer Speicher, 159 Hochverfügbarkeit, 151, 152 Hochverfügbarkeit der Stromversorgung, 195 Hochverfügbarkeit des TSM, 198 Hochverfügbarkeitsdaten, 253 Hochverfügbarkeitsgründen, 152 Hohe Datenverfügbarkeit, 150 hohe Netz-Verfügbarkeit, 292 hohe Verfügbarkeit, 13, 156 hohe Verfügbarkeit der Anwendungen, 172 hohem Informationswert für das Geschäft des Unternehmens, 34 hohen Bedeutung der Datenverfügbarkeit, 293 hohen personellen Aufwand, 150 hoher Performance, 20 Homeshares, 154

392

Sachwortverzeichnis

HOPs, 168 Host basierende Kopie, 164 Host Bus Adapter, 167, 255 Host Bus-Adapter, 123 Host Connectivity, 87 Hostbasierende Migrationsverfahren, 141 hostbasierenden Migrationsverfahren, 141 Hosts, 274 Hot-Spare Platte, 164 Hot-Standby-Datenbank mit Nachlauf, 173 Hot-Standby-System, 176, 177 Hot-Standby-Systems, 177 HP, XI, 94, 141, 249, 250, 316, 317, 345 HP-UX, 46, 276 HP/UX, 161 HSM, V, 153, 239, 251, 290 HTML, 305–307 http, 325 Hypertext Markup Language, 306 höchste Verfügbarkeit, 157 I/O-Subsystem, 123 IBM, XI, 46, 74, 94, 184, 249, 250, 317, 344, 345 IBM DS8xxx, 29 IDC, 322, 324 IDC-Klassen, 322, 323 identischen remote Systemen, 13 identischer Hardware, 152 IDS, 62, 275 IEEE Adresse, 285 IETF, 57, 278 iFCP, 154 ILM, VI, VIII–XI, 1, 52, 66, 67, 119, 240, 252, 274, 281, 287, 292, 299, 315, 318, 343, 347, 348, 355, 356 ILM als Marktstrategie, 315 ILM als Modell mit dem Fokus Speicherung der Information, 58 ILM als Prozessmodell, 58 ILM Initiative, 316

ILM Solution Tapestry File Lifecycle Manager, 350 ILM-Ansätze der Dienstleister, 355 ILM-Archivierungs- und tiered storage Lösung, 94 ILM-Automation, 57 ILM-aware-Anwendungen, 240 ILM-Entscheidungsmatrix, XI ILM-Implementierung, 315, 326 ILM-Integration, 344 ILM-konform, 298 ILM-konforme Backup-Umgebung, 290 ILM-Konzept, 42, 67 ILM-Konzepte, 351 ILM-Konzeptes, X, 66, 209, 290 ILM-Konzepts, 290, 291 ILM-Lösung, 290 ILM-Markt, 316 ILM-Modell, 37 ILM-Modelle, 1 ILM-Modellen, 343 ILM-Projekt, XII, 66 ILM-Projekte, XII, 71 ILM-Projekten, 60, 67 ILM-Projektes, 67 ILM-Strategie, XI, XIV, 291, 315, 318, 351 ILM-Tool, 344 Ilumin, 345 IM Logic, 346 IM/ILM-fähige Hard- und Softwaresysteme, XI Image-(Raw) Sicherungen, 180 Images, 210 Implementierung, 119 Implementierung der ArchivierungsGeschäftsprozesse, 31 Implementierung der Geschäftsprozesse, XI Implementierung der Geschäftsprozesse und tiered Speicherinfrastruktur, 71 Implementierung eines ITGrundschutzes, 6

Sachwortverzeichnis

Implementierung von Information Management, 69 Implementierung von Sicherheitszellen, 181 Implementierung von Tiered-Storage, 326 Implementierungs- und Testphase, 123 Implementierungsvarianten, 151 Implementierungsvarianten von NAS-Appliance, 151 In-Bound Security, 182 Incident-Management, 23, 26 individuelle Definition von Daten-, Storage- und Backup-Klassen, 291 Informatik und, 3 Information als Produkt, VIII Information als Produktionsfaktor, VI, VIII Information Capture, 316 Information Delivery, 316 Information den Produktcharakter, VI Information Lifecycle, 3, 41 Information Lifecycle als speziellen Produktlebenszyklus der Information, 7 Information Lifecycle Management, V, VIII–X, XII, XIII, 1, 3, 30, 31, 69, 315, 316, 320, 322, 324, 326, 351, 355, 361 Information Lifecycle ManagementStrategie, 350 Information Lifecycle Managements, XI, XIII, 34 Information Lifecycle Phasen, 29 Information Lifecycle und ITSysteme, 10 Information Lifecyle Management, VI, X Information Lifestyle Management, 240 Information Management, XII, 4, 8, 34, 316

393

Information Management Tools, XI Information Retention, 316 Information Security Management System, 287 Information Server, 318 Information Technology Practice, 355 Information-Lifecycle-ManagementStrategie, 291 Informationen aus Crem-Systemen, 13 Informations Lebenszyklus, 30, 168 Informations- und Information Lifecycle Managements, XII Informations-Istaufnahme, XI Informations-Lebenszyklus, 10, 29, 34, 35 Informations-Lebenszyklus-Phasen, 269 Informations-Lebenszyklus-StrategieMix, 15 Informations-Portfolios, 35 Informations-Zeit-Diagramm, 10 Informationsfluss, 156 Informationsgesellschaft, 10 Informationsinfrastruktur, 8 Informationslebenszyklusphasen, 20 Informationsmanagement, VI InformationsmanagementDienstleistungen-Klassifizierung, 246 Informationsmanagements, 35 Informationsobjekten, 2 Informationsportfolio, VIII Informationssicherheit, 155, 196 Informationstechnologie, 7, 157 Informationsverbrechen, 63 Informationswachstum, 4 Informationswert im Lebenszyklus, 18 Informationswert-Anpassung, 21, 24, 27 InformationswertAufbewahrungszeit-Matrix, 30, 32, 34 Infrastruktur, 123, 153

394

Sachwortverzeichnis

Infrastruktur des Storagepools, 123 Infrastrukturanpassungen, 4 Infrastruktureffizienz, 17, 19, 22 Ingress Router, 278 inhomogene Betriebssystemlandschaften, 198 Inhouse-Rechenzentrumsbetrieb, 181 inkompatible Managementsysteme, 5 inkrementellen Kopieraktion, 199 inkrementeller Establish, 160 inkrementeller Kopiervorgang, 200 Input- und Output-Management, 58 Installationsreferenzen, 5 Instant-Messaging, 345 Integration, 5, 152 Integration der NAS Software, 152 Integration in ein MS-Windows Umfeld, 152 Integration von Fileservices, 151 Integratoren, XI integrierten Datenmodell, 2 integrierten Speicherlösungen, 318 Integrität der gespeicherten Informationen, 303 intelligenten Disk-Array, 285 intelligentes Archivierungsverfahren, 153 intelligentes externes Speichersystem, 151 Intelligenz in den Speichersystemen, VI Intelligenz von Clients, V intern anschließbaren Magnetplatten, 155 international tätigen Konzernunternehmen, 3 interne Controlling, 140 Interne Redundanz, 162 interne Redundanz der Komponenten, 161 internen Speichermedien, 155 Internet, 31, 275, 300, 311 internet Small Computer System Interface, 4 Internet-Protokoll, 273

Interoperabilität, 5, 154 Interswitch-Links, 165 Intrusion Detection System, 62 Intrusion Detection Systeme, 275 Intrusion Prevention Systeme, 275 Intrusion-Detection, 346 Inventarisierung, 119 Inventur, 119 Involvierung der Kunden, 126 IOPS, 291, 293 IP, 5, 273 IP Storage, 52 IP-Layer-Security, 63 IP-Protokoll, 273 IP-Protokollbasierten Paketen, 275 IPS, 275 IPsec, 63 IS1200, 318 ISACA, 77, 233 iSCSI, 4, 63, 150, 154, 255, 257, 273, 285, 321, 324 iSCSI-SANs, 63 iSCSI/FCIP, 150 ISL, 168 ISL’s, 167, 168 ISL-Leitungen, 167 ISMS, 287 ISO 12234-2:2001, 307 ISO 15930, 312 ISO 15930-6:2003, 312 ISO 17799, 64, 75, 288, 289 ISO 20000, 76, 245 ISO 27000, 289 ISO 9000, 287 ISO 9001, 72, 287 ISO-Norm, 308, 309 ISO-Norm PDF/X, 313 ISO-SGML-Norm, 306 ISO/CD 19005-1, 312 ISO/IEC 17799, 287 ISO/IEC 27000, 287 ISO/IEC 27001, 287, 288 ISO/IEC 27004, 287 ISO/IEC 27005, 287 Isolierung des Storage, 278

Sachwortverzeichnis

ISOVEL-Klimaschränke, 195 IT-Archivierungsprozesse, 31 IT-Grundschutz, 75 IT-Grundschutzes, 6, 75 IT-Grundschutzhandbuch, 75 IT-Infrastructure-Library, 7 IT-Infrastrukturplanung, 44 IT-Kosten, 46 IT-Primärtechnik, 20 IT-Risk-Management, 66 IT-Security-Policy, 63 IT-Sekundärtechnik, 22 IT-Strategien für das Informationsmanagement, 8 IT-Strategien für die Archivierungsphase, 26 IT-Strategien für die Bewahrungsphase, 23 IT-Strategien für die Verdichtungs/Nutzungsphase, 21 IT-Strategien-Mix, 16, 30, 35 IT-Strategien-Mix im Informationslebenszyklus, 17 ITIL, 7, 17, 57, 74, 76, 126, 245 ITIL Service Managements, 20 ITIL-basiertem Change Management, 126 ITIL-Basis-ProzessKostenmanagements, 77 ITIL-Projekte, 76 ITSEC, 276 ITSMF, 57 ITU, 308 IXOS, 184, 233, 254 jeweils gültigen Releasestand, 16 JFS, 276 Joint Photographic Experts Group, 309 JPEG, 309 JPEG 2000, 309 Jukebox/DVD-Lösungen, 202 Jukeboxen, 157 juristischen Grundlagen, XII

395

K-Fall, 13, 184, 297 K-Fall Absicherung, 172 K-Fall Schutz, 88, 176 K-Fall Schutzes, 167 K-Fall-Szenario, 184 K-Fall-Übungen, 297 K-Fall., 177 Kapazitätsmanagement, 92 Kapazitätsmanagement Synergien, 100, 105 Kapazitätsplanung, 119, 350 Kapazitätsplanung für die Neuumgebung, 119 kaskadierten Switchen, 168 Kaskadierung, 168 Katastrophenanforderungen, 181 Katastrophenfall, 63 kategorisieren, 153 kaufmännischen Bestätigungsschreiben, 299 KDE, 276 Kennzahlenermittlung, 7 Kerberos über TCP, 152 Kernforderung den Backup- und Wiederherstellprozesses, 291 Keyfaktor Security, 62, 273 Kick-Off Meetings, 119 Kick-Off-Veranstaltung, 90 Kick-Off-Workshop, 92, 93, 112 Kienbaum, 357 Klartexttunnel, 275 Klassifikation der Daten und Anwendungen, XI Klassifikation nach Autorisierung, 270 Klassifizierung, 244, 346, 349 Klassifizierung der Daten, 254 Klassifizierung mithilfe von Metadaten, 270 Klassifizierung nach dem Inhalt der Dateien, 270 Klassifizierung nach Metadaten, 270 Klassifizierung nach Server/Anwendungen, 257

396

Sachwortverzeichnis

Klassifizierung und Suche auch für Snapshot-Backups, 318 Klassifizierung von Informationsobjekten, 2 Klassifizierung von Speicherressourcen, XI Klassifizierung über Metadaten, 269 Klassifizierungskonzepte, 60, 235 Klassifizierungskriterien, 169 Klassifizierungsmodelle, 291 Klassifizierungspfad, 271 Klassifizierungsprozesses, 303 Klassische Sicherheitskonzepte, 274, 278 klassischen Security-Ansätzen, 65 Klima, 195 KM, 72, 79 Knoten, 152 Kommunikationsmustern, 275 Kompatibilität, 208 Kompatibilitätslisten, 183 kompensierbaren Ausfällen, 172 kompletter Spiegel einer Produktivplatte, 159 Komplexität der Umsetzung, 351 komplikationsfreie Fallback-Lösung, 200 Komponentenimplementierung, 162 Kompressionsverfahren, 307 Konfigurationsgespräch, 126 Konfigurationsmanagement, 72, 79 Konfigurationsorientierte Tests, 222 Konfigurationsrichtlinien, 126, 140 Konfigurationsrichtlinien für die Neuumgebung, 140 Konqueror, 276 Konsensrunden, 90 konsequenten Betriebsführung, 286 Konsistenz der Geschäftsprozesse des Unternehmens, 18 Konsolidierung, 88, 150, 154, 155, 196 Konsolidierung des Personals, 155, 196 Konsolidierungs- und Compliance Projekte, 119

Konsolidierungsprojekt, 150 Kontinuierliche Datensicherung, 274, 277 kontinuierliche Datensicherung, 277 kontinuierliche Qualitätsmanagement, XI, 71 kontinuierliche Qualitätssicherung, 66, 209 kontinuierlichen Datenschutzes, 248 Kontinuierlicher Refresh, 239 KonTraG, XIII, 7 Konzept für die Kontrolle und Durchsetzung von Zugriffsrechten auf IT-Systeme, 279 Konzeptions- und Designphase, 123 Konzeptionsphase, 123 Koordination von Fremdunternehmen, 123 Kopieren, 126 Kopiermechanismus, 233 Kosten, 150, 208 Kosten der Hardwareinfrastruktur der Informationshaltung, 13 Kosten der Information im Lebenszyklus, 14 Kosten der Information über ihren Lebenszyklus, 12 Kosten der Informationsgewinnung, VIII, 12 Kosten der Prozess-Infrastruktur, 13, 14 Kosten der Prozess-Infrastruktur der Informationshaltung, 13 Kosten der Software-Infrastruktur der Informationshaltung, 13 Kosten der Softwareinfrastruktur, 14 Kosten im InformationsLebenszyklus, 12 kostenangepassten Speicherung von Informationen, V Kostenbewusstsein, 24, 27 Kosteneffizienz, 8 Kosteneinsparungspotenziale, 46 Kostengesichtspunkten, 2 kostenintensiven Primärtechnik, 22

Sachwortverzeichnis

Kostenmanagement, 15 Kostenmanagement von Dienstleistungen, 15 Kostenplanung, 107, 169 Kostenreduzierung, 86, 180 kostensensitive Massendaten, 323 kostensensitives Datenmanagement, 1 Kostensteuerung, 112 Kostenziele, 88 kraft Handelsbrauchs, 300 Krcmar, 67 Kreditvergaberichtlinien, 7 Krypto-Algorithmus, 295 Kundenstammdaten, 10 Kurve der Wiederverwendungswahrscheinlichkeit erstellter Daten, 21 Kühlung, 123 Label Switch Router, 278 Label Switching, 278 Lampertz-Zellen, 181 LAN, 63, 278, 296 LAN-free Backup, 179 LAN-free) Sicherungen, 179 LAN-freie, 179 LAN-Switch, 285 langfristige Aufbewahrung von Daten, 29 langfristige Aufbewahrungsfristen, 24 langfristige Lieferantenbeziehungen, 202 langfristige Speicherung und Aufbewahrung, 27 langfristigen Archivierungslösung, 157 Langlebigkeit, 157, 158 Langzeit-Archivdaten, 303 Langzeitarchivierung, 202, 308, 309, 314 Langzeitarchivierung von Daten, 315 Langzeitarchivierungsformat, 310 Langzeitstabile Formate für Pixelgrafiken, 307–309

397

Langzeitstabile Formate für Seitenbeschreibung und beliebige Grafiken, 311 Langzeitstabile Formate für textbasierte Informationen, 305 Langzeitstabile Formate für VektorGrafiken, 311 Langzeitstabile Formate für Vektorund kombinierte Grafiken, 310 langzeitstabiles Datenformat, 307, 308 Lastanforderung, 176 Lastausgleich für Server- und Speichersysteme, 155 Laufzeitverhalten, 119 Lebenszyklus, VI, VIII, 12, 13, 16, 156 Lebenszyklus der Information, 10 Lebenszyklus des Produktes Information, XII Lebenszykluskonforme Datenspeicherung, 86 Lebenszyklusphase, 14 Lebenszyklusphasen, 21, 24, 27 Legato, 315 Leistungsergebnis, 2 Leistungserstellungsprozess, 2, 16 Leistungserstellungsprozesses, 15 Leistungsfähigkeit, 152 Leistungskennzahlen, 321 Leistungsportfolio, 85 Leistungspotenzial, 2 Leistungsverträgen, 169 Leistungsziele, 88 Leitungskapazität, 167 Lenkungsausschuss, 81, 82, 108 Level der Implementierung von Security-Konzepten, 5 Libraries, 13 Library Funktionalität, 197 Lieferant, 202 Lieferanten, 5, 126, 183, 202 Lieferantenauswahl, 88 Lieferantenunternehmen, 183 Lieferung der angebotenen Hard-, Software, 123

398

Sachwortverzeichnis

Lifecycle Management von Filebasierten Daten, 347 Lifecycle Management-Ansatz, 350 Limitierung des E-Mail-Accounts, 2 LINUX, 200 Linux, 19, 46, 151, 161, 184, 188, 199, 276 Lister, 364 LKM, 5 Load-Balancing, 151, 159, 173, 197 Local Mirror, 159 Logica CMG, 357 Logical Unit Number, 285 Logical Unit Number)-Masking, 63 logische Festplatten, 154 logische Platteneinheit, 285 Logische Wiederherstellzeit, 32 logische Zerstörung der Daten, 173 logischen Abbilds des Originalbildes der Datenplatte, 159 lokale Ablage, 2 Lokale Migration der Daten, 198 lokale Spiegel, 324 lokalen Ersatzservers, 174 Lotus, 345 Lotus Notes, 158, 188, 199, 234, 299– 302 Low-Cost, 351 Low-Cost-Storage, 350 LSI, 141 LSI Logic, XII LSI-Logic, 94, 317 LSI-Logic Inc.,, XII LSR, 278, 279 LUN, 285 LUN Masking, 285, 286 LUN Zoning, 285 LUN’s, 161 LUN-Binding, 285 LUN-Größen, 164, 165 LUN-Masking, 285, 286 LUN-Security, 285 LUN-Zugangs, 286 LUN-Zugriffstabellen, 286 LWL-HBA’s, 198

LWL-Karten, 161, 165 LWL-Verkabelung, 197 LZW-Kompression, 308 Löschen von Daten, 290 MAC, 279 Magnetband-Libraries, 13 Magnetbandarchivierungen, 24 Magnetbandbibliotheken, 25, 29 Magnetbandkassetten, 292 Magnetbandlaufwerke, 159, 165 Magnetbandlösungen, 202 Magnetbänder, 19, 297 Magnetbändern, 318 Magnetplatten, 19 Magnetplatten(-systeme, 29 Mail, 300 Mail-Archivierung, 346 Mailbox, 300 Mailboxen, 302 Mails, 302 MAN, 278, 290 Man-in-the-Middle-Attacke, 296 Manage, 343 Managebarkeit, 157 Management, 151, 154, 155 Management der Speicher- und Netzkomponenten, 286 Management der Speichersystemhardware, 208 Management der StorageInfrastruktur, 280 Management des Fehlerrisikos, 66 Management des fluktuierenden Datenwerts, 317 Management des kontinuierlichen Geschäftsbetriebs, 288 Management Framework, 326 Management Schnittstellen, 280 Management unstrukturierter Daten, 318 Management von Datenmengen, 154 Management von File- und Blockzugriff, 151

Sachwortverzeichnis

Management von unstrukturierten Daten, 60, 235 Management-Framework, 322 Management-System-Standard, 287 Management-Tools, 156, 197 Management-Zugang, 286 Management-Zugangspunkte, 280 Managementphilosophie, VIII Managementsystem, 123 Mandatory Access Control, 276, 279 Mangel an Visibilität, 12 manuelle Inventur, 119 Manuelles Failback, 224, 227 Manuelles Failover, 223, 227 Mapping der SNAP-Devices, 209 Markt für Speichersysteme, XII Marktbeobachtungen, 156 marktfähige ILM-Produkte, X Masking, 286 Masterplans, 84 Materna GmbH, 357 Matrixorganisationen, 106 maximal mögliche Offline-Zeit der Applikation, 199 Maximale Hardwareausfallzeit, 261 Maximale logische Wiederherstellzeit, 261 Maximaler geplanter Datenverlust, 32, 266 McData, XI, 161, 250 McKinsey&Company, 357 MD5, 65 MDY, 346 MDY-Software, 346 Media-Streaming, 292 Mediaservern, 210 Medical solutions, 317 medienunabhängige Codierung von Textinhalten, 307 Mehrbenutzersystemen, 279 Meilensteine, 103 Messung der Storageklassen, 239 Meta-Datenbasierte Klassifizierung, 247 Metadaten, 158, 270, 314

399

Metadaten zu den Archivdaten, 158 Methode 635, 89 Metropolitan Area, 278 Metropolitan Area Network, 290 Micro- und Flarecodes, 30 Micro-Code-Changes, 280 Microcode-Updates, 161 Microcodeimplementierung, 160 Microsoft, 19, 97, 152, 307 Microsoft Exchange, 234 Microsoft Management Framework, 152 Microsoft Office, 307 Microsoft Project 2003, 103 Microsoft Tool Visio2000, 167 Microsoft Windows, 150, 277, 309 Microsoft Word, 307 Midrange, 315, 316 Midrange Bereich, 317 Midrange Klasse, 22, 25 Midrange Magnetplatten(-systeme), 29 Midrange-Segment, 320 Migration, XIII, 26, 71, 87, 88, 123, 126, 141, 291, 349 Migration auf neue HWTechnologien, 158 Migration der Anwendungen auf die Neuumgebung, 140 Migration der Daten, 199, 324 Migration der Daten auf ein Neusystem, 198 Migration der Daten durch lokales COPY, 199 Migration der Serversysteme, 123 Migration mit Springersystem, 200 Migration von Exchange, 201 Migration über Springersysteme, 141 Migrationen, 140, 141 Migrations- und Rückfallverfahren, 123 Migrations- und Rückfallverfahren je Server, 123 Migrationsphase, 123 Migrationsprojekt, 65

400

Sachwortverzeichnis

Migrationsprojekten, 141 Migrationsstrategie, 198 Migrationsunterstützungsleistungen, 197 Migrationsverfahren, 98, 126, 140, 141, 198, 200 migrieren, 351 migrierenden Server/Cluster-Systeme, 126 migriert, 17 minimalen Verzögerung, 14 Mirroring, 29 Mischkalkulation, 239 Mission Critical Data, 322 Mission-Critical Anwendungen, 29 Mitarbeiter, 62 Mitarbeiterschutz, 300 Mitglieder der SNIA, 315 mittelständischen Unternehmen, 3 MMC, 152 Modell, 72, 73 Modells, 73 Modemzugang, 161 Moderne Speichersysteme, V modernen Datenspeicherung, 1 Modifikation der ARP-Tabellen, 296 Modifikationsdatum, 153 Modifikationsdatum der Datei, 153 Monitoring, 91 Moor, 32, 34 Moore, 32 Motivation der Belegschaft, 66 Mountpoints, 200 MPLS, 278 MPLS Label Stack, 279 MPLS Netzwerkes, 278 MPLS Paketen, 279 MPLS Tunnels, 279 MPLS-Netzwerkes, 278 MPLS-Tunnel, 278 MS-Exchange, 158 MS-Project 2003, 105 Multi-Protokoll Kompatibilität, 321 Multi-Tier Information Lifecycle Management Landschaft, 31

Multi-Tier-Storage, 346 Multiliterale Sicherheitsmodelle, 276 multiple Plattformen, 151 multiple Zugriffspfade, 13 Multiprojektmanagements, 106 Muster für Konsolidierungs- und Compliance Projekte, 119 mySAP, V Möglichkeit zur Reorganisation fragmentierter RAID-Gruppen, 160 Namensauflösung, 222 Namespaces, 348, 349 NAS, VI, X, 4, 5, 52, 63, 76, 150–154, 202, 253, 257, 273, 275, 277, 278, 289, 290, 321, 324, 348 NAS Lösung, 152 NAS Servern, 152 NAS-Appliance, 151 NAS-Appliances, 151 NAS-basierten, 151 NAS-Lösung, 159 NAS-Lösungen, 159, 317 NAS-Markt, 318 NAS-Speichernetze, 63 NAS-Systeme, 159 NAS-Technologie, 180 NAS-Umfeld, 318 nationalen und internationalen Rechtsvorschriften hinsichtlich Archivierung, 325 nativer ACL-Unterstützung, 276 Nautilus, 276 NDMP Backup, 180 NDMP-Protokoll, 179, 180 NDMP-Sicherungen, 180 nearline, 24 Nearline Data, 323 Nearline Daten, 70, 86, 88, 167, 184, 253, 268, 323 Nearline Speicher, 159 Nearline Techniken, 21 Nebeneffekt der Speicherkonsolidierung, 155, 196 NetApp, XI, 318

Sachwortverzeichnis

Netware, 46 Network Appliance, 250, 292, 318, 370 Network Appliance Filer, 351 Network Appliance-Umgebungen, 350 Network Appliances, XI, 318 Network Attached Storage, VI, X, 4, 52, 150, 151, 253, 255, 273, 290 Network Intelligence, 316 Netz, 151 Netzeingänge des Plattensystems, 286 Netzwerk, 150, 154, 188, 255 Netzwerk aus Speicher-Devices, 154 Netzwerk- und SAN-Infrastruktur, XI Netzwerkadministratoren, 280 Netzwerkarchitektur, 188 Netzwerkbenutzer, 154 Netzwerke, 123, 150 Netzwerkgegebenheiten, 188 Netzwerkimplementierung, 188 Netzwerkinfrastruktur, 151 Netzwerkmedien, 150 Netzwerkprotokolle, 150 Netzwerkspeicher, 196 Netzwerkspeichersysteme, 155 neues SLA Konzept, 169 Neugestaltung des Backupverfahrens, 179 Neustarts der IT-Services, 297 Neuumgebung, 119, 123, 140 Newsmaster, 280 NFS, 150, 325, 348 NFS-Protokoll, 151 ngriffsmuster, 297 nicht löschbar, 157 niedrigste Wiederverwendungswahrscheinlichkeit der Daten, 24 Non-Compliance, 7 Non-Critical Data, 61 normalen Zugriffssteuerung, 276 Normierung der Geschäftprozesse, 86 Notwendigkeit von Serverumzügen, 123 Novell, 161 Novell Open Enterprise Server, 46 NPES, 314

401

NSC, 321 ntegrität der gespeicherten Informationen von Gesetzes wegen, 303 Nutzen der einzelnen IT-Services, 77 Nutzung, 29 Nutzungsphase, 10, 14 Nutzungszeitraum, 10 NV-RAM, 286 OASE, 57 OECD Guidelines, 287 OECD Guidelines for the Security of Information Systems and Networks, 287 OEM, XII, 316 Off-Site Redundanz, 321 offenem Zugriff, 63 offenes Mail-Relay, 280 öffentlichen Schlüssel, 296 Office-Dokumente, 41 Offline Data, 324 Offline-Sicherung des Altsystems, 201 Offline-Zeit der Applikation, 200 Offline-Zeiten, 199 Offline-Zeiten für die Migrationschanges, 199 OLTP, 291 OLTP-Anwendungen, 154 OLTP-Systeme, 29 OLTP-Systems, 21 online, 24 Online Austausch HBA, 223 Online Backup,, 31 Online LUN-Erweiterung, 160 online Speicher, 151 Online Techniken, 21 Online-Datenschutz, 293, 298 Online-Langzeitarchiv, 253 Online-Migration, 126 Online-Mikro-Code-Upgrades, 65 Online-Publishing-Systemen, 307 Online-Systemen, 251 Online-Transaction-Based-Processing, 291 Online-Zugriff auf Storage, 290

402

Sachwortverzeichnis

onlinemirror, 200 Open Source, 46 Open-Systems Umgebung, 322 operationellen Daten, 2 operativen Umsetzung der Klassifizierung, 252 optimale Auslastung der ITInfrastruktur, 8 Optimale Business Continuity, 13 optimale Performance, 155 optimalen Kosten, 5 Optimierung der Business Continuity, 321 Optimierung der Geschäftsprozesse, 71 Optimierung von Arbeitsabläufen, 66 Optimierung von Kommunikationsstrukturen, 66 Optimierungspotenzial, 303 Optimizer Funktion, 160 optische Medien, 19, 316 Optische Speichermedien, 29 Oracle, 97, 126, 234 organisatorischen und technischen Anforderungen für die Archivierung, 303 Originalbild, 307 OSD, 249 OSHA, 27 Outerbay, 345 Outsourcing, 8 packet signing, 152 Paketfilter, 274 Papierarchiv, 303 Parity-Platte, 164 passiven Infrastruktur, 123 Passwortschutz, 64 Passwörter, 297 Patchung der Firmware, 199 Path-Failover-Software, 173 PDCA Models, 287 PDF, 311 PDF-Features, 312 PDF-Format, 186

PDF-Probleme, 313 PDF-Viewer, 312 PDF/A, 312, 314 PDF/A-Dateien, 314 PDF/X, 312, 313 PDF/X-3, 312 PDF/X-Konformität, 313 Performance, 126, 160 Performance der Speichersysteme, 126 performancebedingte Migrationsnotwendigkeit, 164 Performanceplanung, 119 performanter Datenbankmanagement-systeme, 21 permanente und unterbrechungsfreie Datenmigration, 322 Personalaufwandes, 141 Personalkosten, 157 Petabyte, 3, 4 Pflichtenheft, XI, 185 Pflichtenheftes, 88, 150, 201 Pflichtenhefts, 119 Phase der Umsetzung, 123 Phasenmodell, 103 physikalische Größe, 3 physikalische Wiederherstellzeit, 176, 261 physikalischen Anschluss der HBA’s, 199 physikalischen Fehlern, 13 physikalischen Plattengrößen mischbar, 161 physikalischen Portnummern, 285 physikalischen Speichermedien, 13 physikalischer, 119 physikalischer Ports, 285 Physische Wiederherstellzeit, 32 PIWU, 78 PIWU-Prozess, 79 Planungs- und Konzeptionsphase, 123 Planungsphase für Serveraktivitäten, 123

Sachwortverzeichnis

Planungsphase Migrationsverfahren, 126 Platten, 165 Platten-ID’s, 200 Plattenausfällen, 65 Plattenkapazitäten, 150 Plattenlaufwerken, 154 Plattenlayout, 123 Plattenplatzbedarf, 188 Plattenzugriffspfade, 182 Plattform Services, XIII Plattform zur Langzeitarchivierung von Daten, 315 Plattformneutralität, 304, 308 plattformübergreifendes Datenformat, 308 PM, 72, 79 PM-Kanon, 79 PM-Kompetenzen, 78 PMI, 78 PNG, 308, 309 Point-in-time Copies – Server exclusive/shared, 298 Point-in-Time Kopien, 321 Point-in-Time-Replikationen, 29 Point-to-Point, 154 Policies, XI, XIII, 325, 350, 351 policy-basierte Infrastrukturanpassung, XII policy-basierten Infrastrukturanpassung, XI Port Based Network Access Control, 279 Port Zoning, 285 Port-Zoning, 285 Portable Document Format, 311 Portable Network Graphics, 308 Portfolio, 72 Portfolioanalyse, 34 Portfolios, IX Portscanns, 275 Portzoning, 182 Postmaster, 280 PostScript, 310, 311 Potentiale in Werte umsetzen, 78

403

potenzielle Angreifer, 5 Powderhorn 9360, 195 Power OFF Failover, 224, 228 Pre-Scripting, 179 Preis-Leistungsverhältnis, 123 preiswerte Archivierungstechnik, 25 preiswertere Sekundärtechnik, 22 PreLife, 184, 188 PreLife-Umgebungen, 16 Preserve, 343 Presite, 162, 197 Presite-Besprechungen, 162 PriceWaterhouseCoopers, 358 Primary, 180 Primär-Speichertechnologien, 29 primären Speichermedium, 154 Primärstorage, 177 Primärsystems, 176 Primärtechnik, 14, 23, 25 PRINCE II, 78 PRINCE2, 74, 75 private Mail, 300 Private- und Public-Keys, 65 Privatmail, 300 Problem Children, 34 Problem Management, 24, 27, 140 Produktionsfaktors, VI Produktionsnetz, 188 Produktionssteuerung, 92, 123, 126 produktionswirtschaftlichen Grundmodelle, 2 Produktiv-Rechenzentrums, 172 Produktivdaten, 303 Produktivplatte, 159 Produktlebenszyklus, VI, VIII, XII, 24 Produktportfolio, 315, 316, 326 Professional Services, 326 Projekt- und ProjektmanagementAnsatz, 69 Projekt-Exit-Management, 78 Projekt-Kick-Off Meeting, 84 Projekt-Lenkungsausschuss, 102 Projektauftrag, 86 Projektausschreibung, 185 Projektforschritt, 82

404

Sachwortverzeichnis

Projektfortschritt, 112 Projektgremien, 81 Projektinformationswesen, 108 projektkritischen Stakeholder, 90 Projektkultur, 112 Projektlaufzeit, 93 Projektmanagement, 71, 83, 183 Projektmanagement als Dienstleistung, 73 Projektmanagement-Ansätzen, 72 Projektmanagement-Meetings, 110, 112 Projektmanagement-Modell, 106 Projektmanagement-Team, 82 Projektmeeting, 110 Projektmeilensteinen, 84 Projektorganisation, 67, 69 Projektphase, XI Projektplan, 119 Projektsteuerung, 112 Projektstrukturierung, 100 Projektumfeldanalyse, 90 Projektverlauf, 119 projektweiten Präsentation, 141 Projektziele, 88 Projektänderungsantrag, 85 Projektänderungsauftrag, 85 Projektänderungsprüfung, 85 Promote Mirror Funktionalität, 159 Protection Policies, 325 Protokolle, 151 Proxyserver, 274 Prozess-Infrastruktur, 14 prozessbasiert automatisch gelöscht, 18 Prozessinfrastruktur, 17, 23 Prozessing, 126 Prozesskette des ITIL Service Managements, 26 Prozesskostenrechnung, VII Prozessorientierung, V prozessuale Kompetenz, 24, 141 PRrojects IN Controlled Environments, 74 Präsentation, 141

PSP, 101 Public Schlüssel, 296 Public-Key-Infrastructure, 63 PWC, 358 QLOGIC, 165 Qlogic, 161 QM, 66 QoS, 278 QS, 66, 72, 79, 209 Quality of Service, 322 Qualität der Information, 12 Qualität der Ressourcenauslastung, 110 Qualitäts- und Risikomanagements, 66, 209 Qualitätsmanagement, 15, 66 Qualitätssicherung, 65, 66, 72, 79, 126 Qualitätssicherung nach SOW, 126 Quotas, 153 Radius-Server, 279 RAID, 159, 321, 324 Raid, 164 RAID-Absicherungsmechanismen, 163 RAID-Level, 158, 161 RAID-Schutz, 13 RAID-Schutzklassen, 163 RAIDsets, 161 Rand-RouterZugriffssicherungslisten, 274 Randbedingungen, 87 Rastergrafiken, 310 Raumplanung, 123 Raumtechnik, 123 RAW-Image, 198 RBAC, 279, 280 Reaktionszeit, 32 Reaktionszeiten, 264 Real-Time Kopien für Backups und schnelles Desaster Recovery, 321 Realisierung der Ferndiagnose, 161 Realisierung von Langzeitarchiven mit SATA-Techniken, 202

Sachwortverzeichnis

Realisierung von Langzeitarchiven über Content Adressable Space, 202 Realisierung von Langzeitarchiven über Jukeboxes/DVD, 202 Realisierung von Langzeitarchiven über Magnetbandtechnologien, 202 Rechenzentren, 123, 168, 195 Rechenzentrumsbetrieb, 181 Rechner mit Netzwerkschnittstellen, 274 Rechnernetzen, 279 Rechtliche Anforderungen an die Archivierung, 298 rechtlichen Anforderungen, 158, 181 rechtlichen Gründen, 157 Rechtspflichten, 299 rechtsrelevante elektronische Erklärungen, 299 Rechtssicherheit, 300 Reconfigureboot, 177 Record Management, 58 Record-Managementspezialisten, 346 Records Management, 343 Recover der Datenbanken, 200 Recovery, 238, 293 Recovery Point Objective, 244 Recovery Point Objectives, 249 Recovery Time Objective, 244 Recovery Time Objectives, 249 Recovery-Architektur, X Recovery-Mechanismen, 199 Recovery-Mechanismen der Datenbank, 176 Redo Log shipping, 266 REDO-Log, 200 Reduktion der Daten, 15 Reduktion der Performance, 152 Reduktion der Risiken der NonCompliance, 7 redundant, 152 redundant gespeicherter Informationen, 158 redundante Konfigurationen, 151

405

Redundanz, 167 Redundanzabsicherung, 173 reduzierte Verfügbarkeitsanforderung, 22, 25 Reduzierung des Verwaltungs- und Administrationsaufwandes, 151 Reference Information Management, 345 Reference Information Storage System), 345 Referenzdaten, 29 Referenzmonitor, 276 regelbasierte Datenhaltung in Prozessen, 350 Regeln, 350 Regelung der Sicherheit von Informationssystemen und Netzwerken, 288 Regelungen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen, XIII Regelwerk der Storage Networking Industry Association, XI Regress, XII Regularien, 157 reguläre Zugriffsrechte, 276 ReiserFS, 276 rekonstruieren, 2 Release Management, 16, 21, 25 Release-Management, 20, 24, 27, 141 Releasemanagement, 126 Releasewechsel, 2, 21 remote gespiegelten Daten, 6 Remote Mirror, 159 Remote Mirroring, 126 remote Mirroring, 25 remote Mirroring Verfahren,, 22 Remote Rechenzentrum, 177 Remote Speichersysteme, 173 Remote Speichersystems, 177 Remote- oder Branch-Offices, 349 Remote-Access-VPN, 275 Remote-Systeme, 14 Remoteplatten, 177 Remoteseite, 174

406

Sachwortverzeichnis

Remotestandort, 176, 180 Remotestandortanbindungen, 167 Remotesystem, 177 Remoteüberwachung, 162 Reorganisation fragmentierter RAIDGruppen, 160 Replikation, 29, 158, 322, 349 Replikationsjob, 348 Replizierung, 290 Reporting, 64, 350 Reportingfunktionalität, 160 Repository, 345 Ressourcen- und KommunikationsRisiken, 97 Rest-Aufbewahrungszeit, 34 Restore, 151, 159, 231 Restore eines Primärsystems aus einem SNAP, 209, 218 Restore eines Systems aus dem SNAP Spiegel, 209 Restore eines Systems aus dem SNAP-Spiegel, 220 Restores, 321 Resynchronisation, 164 Retention Manager, 318 Retention Policies, 325 Review, 123, 140 Revisions- und Datensicherheit, 301 Revisionsbaumstämmen, 280 revisionssichere Datenablage, 158 Revisionssichere Dokumentenablage, 158 Rich Media solutions, 317 Richtlinien, 299, 351 Riijndael-Algorithmus, 295 RIM for Databases, 345 RIM for Files, 345 RIM for Messaging, 345 Risiken der Non-Compliance, 9 Risiko eines Datenverlustes, 277 Risikoanalyse, 93 Risikoidentifikation, 288 Risikomanagement, 65–67, 209, 289 Risikominderung, 67

Risk & Regulatory Management Programms für Finanzinstitute, 355 RISS, 345 Roadmap des Marktes, 326 robocopy, 200 Rohdaten, 14 Roland Berger Strategy Consultants, 358 Role Based Access Control, 279 Rollback, 200 Rollbackverfahren, 200 Router, 274, 296 Routing, 279 RPO, 244, 249 RTO, 244, 249 RZ-Infrastruktur, 14, 20, 22, 25 RZ-Primärtechnik, 123 Rückfalllösung, 126 Rückgang von Störfällen, 91 SAIN, 324, 325 SAM-Modell, 58 SAN, VI, 4, 52, 63, 76, 123, 126, 150, 154–156, 198, 202, 240, 253, 255, 257, 273, 275, 277, 285, 286, 289, 290, 318, 321, 348 SAN Equipments, 208 SAN File System, 344 SAN Infrastruktur, 347 SAN plus Array of Independent Nodes, 324 SAN zweipfadig anzubinden, 165 SAN’s, 154, 172, 198 SAN-Anbindung, 197 SAN-Architektur, 199 SAN-basierendes Backup-Verfahren, 180 SAN-basierten Backup/Restore Verfahren, 155 SAN-Basis, 154 SAN-Client, 179 SAN-Direktoren, 152, 168, 173, 182, 195 SAN-Erweiterung, 123 SAN-Fabric, 13, 165

Sachwortverzeichnis

SAN-Fabrics, 5, 165 SAN-gestützte Kopie, 164 SAN-Infrastruktur, 183, 286 SAN-Infrastrukturen, 154 SAN-Komplettlösungen, 185 SAN-Komponenten, 179, 183 SAN-Konsolidierung, 185, 186 SAN-Konzept, 165 SAN-Kopien, 164 SAN-Lieferanten, XI SAN-Lösung, 155 SAN-Lösungen, 155 SAN-Markt, 320 SAN-Platten, 199, 200 SAN-Plattformen, 315 SAN-Ports, 168 SAN-Security, 182 SAN-Speicher, 156 SAN-Speichersysteme, 155, 156 SAN-Switches, 152, 181 SAN-Tests, 233 SAN-Umfeld, XI, 318 SAN-Verkabelung, 126 SAN-Wachstums, 320 SAN-Zoning, 285 SAN/NAS-Entscheidung, 202 SAN/NAS-Lösungen, 317 SANCOPY-Funktionalität, 160 SANs, X, 277, 278, 290 SAP, 97, 126, 185, 234 Sarbanes Oxley, 158 Sarbanes Oxley Act, XIII, 27 Sarbanes-Oxley, 7, 274 Sarbanes-Oxley Act, 28 SAS, 248 SATA, 293 SATA Platten, 25 SATA Technologie, 29 SATA- und FC-Technology, 161 SATA-Magnetplatten, 233 SATA-Platten, 180, 293 SATA-Techniken, 202 Scalable Vektor Graphics, 311 Scheefer, 344

407

Schlüssel zur Steuerung von Projekten, 79 Schlüsselverwaltung, 296 schnelle Integration in bestehende Netzwerke, 151 Schutz der Informationen, 155 Schutz vor Ausspähung oder Missbrauch, 6 Schutz vor Computerviren, Worms und Trojanern, 181 Schutz vor einen Eindringen von Außen, 62 Schutz vor Löschung vor Fristablauf, 325 Schutz vor Verlust der archivierten Daten, 325 Schutzklassen, 163, 169 Schutzklassen für die Datenplatten, 169 Schätzklausur, 105 SCM, 1 SCSI, 87 SCSI-Festplatten, 293 SCSI-Platten, 199, 200 SCSI-Protokoll, 285 SEC, 27, 274 Second Study on Digital Data Creation, 18 Secondary System- und Speichertechnologie, 23 Secondary-Storage, 180 Secure Tape Transport Service, 296 Secure-Shell, 63 Security, 66, 119, 316 Security based Klassifizierung, 247 Security der Daten, 62 Security Descriptor, 277 Security im SAN, 182 Security Konzept, 181, 198 Security Strategie, 297, 298 Security- und User-Policies, 301 Security-Anforderungen, 140 Security-Instrumenten, 278 Security-Konzept, X Security-Management, 280, 287

408

Sachwortverzeichnis

Security-Management-Plan, 274 Security-Management-Planung, 281 Security-Maßnahmen, 289 Security-Plan, 281 Security-Policies, X Security-Risiko, 280 Security-Sicht, 280 Security-Umfeld, 347 Segmentierung, V SEI, 77 Seitenbeschreibungssprache für Internet-Browser, 306 Sekundär-Speichertechnologien, 29 Sekundärspeicher, 153, 154 Sekundärtechnik, 23, 25 Selbst-tragendes-Archiv, 158 selbstständig Archivierungsfehler erkennen und beheben, 159 semimanuelle Skriptsteuerung, 176 Sensible Data, 61 separates Netzwerk aus SpeicherDevices, 154 Sequenzieller Datenzugriff, 292 Serial Attached SCSI, 248 Server, 123, 126, 154, 155 Server Access Control List, 276 Server- und Speichersystem, 152 Server- und Speichersystemkapazität, 17, 23 Server- und Storagemigrationen, 123 Server-(Cluster, 20 Server-free Backup, 180 Server/Cluster-Migrations-Teilprojekt, 140 Serveraktivitäten, 123 Serveranbindung an das Storagesystem, 167 serverbasiertes Kopieren, 126 serverbezogene Migration, 123 serverbezogenen Migrationsaktivitäten, 112 Servercluster, 126 Serverdokumentation, 126 Serverkonsolidierung, 155, 196 serverless Backup, 151

serverless Backup und Restore, 151 Servermigration, 126, 141 Servermigrations-Teilprojekte, 126 Servern, 150, 154 Servers, 126 Serversysteme, 13 Serverumgebung, 188 Serverumzüge, 123 Service Desks, 32, 262, 264 Service Level Aggreements, 91 Service Level Agreement, 291 Service Level Agreements, 13, 169, 245 Service Level Konzeptes, 169 Service Level Management, 245 Service Support, 22 Service-Desk, 26 Service-Wertigkeiten, 169 Serviceanforderungen, XIII Servicemodulen, 169 Serviceorientierung der Software, V Services, 123 Services zur Implementierung von ILM, 317 SGML, 305–307 SGML-Datei, 305 SGML-Software, 305 ShadowImage, 322 Shared Storage Option, 180 Shareholder-Value-Gedankens, XII Sharepoint-Server, 346 Shredding Policies, 325 sichere Informationsverbreitung und Informationsaufbewahrung, 299 Sicheres Verschlüsselungsverfahren, 295 Sicherheit, 5, 63, 154 Sicherheit der Informationsübertragung, 65 Sicherheit seiner digitalen Daten, 62 Sicherheits-Software, 62 Sicherheitsfunktionen, 5 Sicherheitskonzepte, 62 Sicherheitskopien, 292 Sicherheitsmaßnahmen, 75

Sachwortverzeichnis

Sicherheitsprotokolle, 63 Sicherheitsreboot, 201 Sicherheitsstandard bei physikalischem Zugriff, 182 Sicherheitstechnologien, 63 Sicherheitsverletzungen, 63 Sicherheitszellen, 181, 182 Sicherstellung der Datenintegrität der Metadaten, 325 Sicherstellung der K-Fall Fähigkeit, 184 Sicherung, 62, 63, 150 Sicherung des Leistungspotenzials, 15 Sicherung direkt im SAN, 179 Sicherung von Snapshots, 198 Sichtbarkeit von Festplatten, 285 Siebel, 185, 234 7-Bit-EPS, 310 Simulation des Laufzeitverhaltens für die Neuumgebung, 119 simultanen Zugriff auf die Dateien, 150 Single Point of Failure, 151, 168, 298 Single-Cluster, 324 Site-to-End, 275 Site-to-Site, 275 Skalierbarkeit, 151, 157 Skalierung der IT-Infrastruktur, 8 Skalierung der IT-Infrastruktur innerhalb der Budgetgrenzen, 4 Skalierung sämtlicher Ressourcen zur Verwaltung der Komplexität, 5 Skalierungsmöglichkeiten, 230 SLA, 91, 119, 123, 152, 156, 169, 196, 245, 290, 291, 322 SLA Matrix, 169 SLA’s, 91, 92 SLA-Management, 20, 24, 27 SLA-relevanten, 169 SLA-Vereinbarungen, 179 SLM, 245 SMI-konformen Speicherverwaltung, 347 SMI-S, 320

409

SMI-S Standard, 141 SMI-S Storage Management Standards, 320 SMP, 316 SMTP-Server, 245 SNAP, 179, 209 SNAP der Spiegeldevices, 209 SNAP der Spiegeldevices und Mapping der SNAP-Devices an Backupserver, 219 Snap Funktionalität, 154 SNAP Primär und Mapping an Backupserver, 216 SNAP’s, 173, 179 SNAP-Funktionalität, 159 SNAP-LUN’s, 179 SNAP-LUNS, 161 SNAP-Technik, 180 SNAP-Technologie, 180 SNAP-Technology, 179 SNAP-Verfahren, 181 SnapSearch, 318 Snapshot-Backups, 318 Snapshot-Technologien, 13 Snapshots, 6, 22, 25, 29, 123, 198, 248, 277, 324 SNIA, XI, 141, 150, 242, 244, 286, 315–317, 320, 346 SNIA Business Transactions, 242 SNIA-konform, 317 SNIA-Roadmap, 56 SNIA-Standard, 249 SNIA-Standards, 315 SNMP, 162 SNMP-Unterstützung, 161 SO/IEC 27003, 287 SOA, V Soft-Zoning, 285 Software, 154, 208 Software Engineering Institute, 77 Software-Infrastruktur, 13, 14, 16, 21, 24 Software-Releasewechseln, 25 Softwarefehler des Speichersystems, 173

410

Sachwortverzeichnis

Softwareinfrastruktur, 16, 25 Softwarelieferanten, 126 Solaris, 46, 161, 184, 188, 276 Soll-Backup-SAN Anbindung, 168 Soll-Serveranbindung, 166, 167 Soll-Serveranbindung im SAN, 166 Solvency, 158 Sonderbedingungen, 32 SOW, 85, 126 SOX, XIII, 355 Spamfilter, 301 Speicher, 151, 154 Speicher für die IT, 316 Speicher-Devices, 154 Speicher-Pool, 155 Speicheradministrator, 156 Speicheradministratoren, 351 Speicherarchitekturansatz, 321 Speicherauslastung durch Konsolidierung, 155 Speicherbedarf, 3 Speicherbranche, 316 Speicherebenen, 32 Speichergesamtkapazität, 155 Speicherindustrie, 29, 63, 321 Speicherinfrastruktur, 202 Speicherkapazität, 321 Speicherkapazitäten, 303 Speicherklasse, 270 Speicherkonsolidierung, 155, 196 Speicherkonsolidierungsprojekte, 4 Speicherkonzept, 150 Speicherkosten, 2, 155 Speichermanagement, 156, 197 Speichermanagement-Umgebung, 126 Speichermanagementmechanismen, 321 Speichermarkt, 202, 315 Speichermarktes, 202 Speichermedien, 63 Speichermöglichkeiten, 154 Speichernetz, 290 Speichernetze, 63, 273 Speichernetzen, 240 Speichernetzes, 253

Speichernetzwerk-Virtualisierung, 52 Speichernetzwerke, 150, 290 Speichernetzwerken, 275 Speicherplattform, 202 Speicherplattformen, 70 Speicherplatz, 153 Speicherplatz im Fileserver, 153 Speicherpools, 286 Speichersegmente, 285 Speichersoftware, 29 Speichersubsystemen, 4 Speichersystem, 13, 151 Speichersystemdokumentation, 126 Speichersysteme, 13, 29, 30, 150, 155, 164, 183, 208, 255 Speichersysteme in Fiber Channel Technologie, 164 Speichersystemen, 141, 150, 156, 161 Speichersystemhardware, 208 Speichersystemhersteller, 181 Speichersystemherstellern, 199 Speichersystemkapazität, 25 Speichersystemkonsolidierung, 94 Speichersystemsoftware, 173 Speichertechnologie, 5, 20, 26 Speicherumgebung, 320 Speicherung, V, 16, 311, 355 Speicherverwaltung, 151 Speichervirtualisierung, 160, 321 Speichervirtualisierungselementen, 321 Speichervolumen, 156 Speichervolumens, 1 Spiegel, 248 Spiegel-LUN, 215 Spiegelplatten, 177 Spiegelplatten des Remote Speichersystems, 177 Spiegelung, 159 Spiegelungs- und BusinessContinuity Software, 30 Split Brain, 226, 229 Split Mirror Technik, 180 Split Mirror Technology, 179 Spreaded Cluster, 210

Sachwortverzeichnis

spreaded Cluster, 177 Spreading, 161 Springersysteme, 98, 141 SRDF, 29 SRM, X SSL-Verbindung, 296 SSL-verschlüsselte Verbindungen, 296 Stabilität, 151 Stand der Speichertechnik, 292 Standard Gateways, 324 Standard Generalized Markup Language, 305 Standard-Sicherheitsmaßnahmen für typische IT-Systeme, 75 Standard-Sicherheitsniveau für ITSysteme, 75 Standardisierte APIs, 5 Standardisierungen, 66 Standardisierungsgremium, 63 Standardkatalog von Verfahren für zukünftige Migrationen, 141 Standards zur Implementierung, XI Standardsbasierte Klassifizierung, 248 Standby-Backup-Server, 195 Standby-Komponenten, 152 Standby-Server, 152 Standby-Verfahren, 152 Standish Group, 66 Standort, 123 standortübergreifenden Sicherung, 180 Startphase, 81, 92 Stateful Inspections, 274 Statische Klassifizierungsmodelle, 240 Statusberichte, 82, 84 Statusberichts, 112 Statusgespräche, 108 Statusinformationen der einzelnen Teilprojekte, 110 statuskonforme Kopie, 12 Statusmeetings, 112 Statusänderungen, 10

411

Steigerung der Effizienz der Geschäftsprozesse, 7 Steigerung der Infrastruktureffizienz, 16, 25 Steigerung des Kapazitätsbedarfes an Festplattenplatz, 3 Steuerpflichtige, 302 Steuerungs- und Administrationssoftware, 25 Steuerungszielen, 289 STK-Tapedrives, 195 Storage, 58, 61, 119, 123, 141, 235, 246, 290 Storage Anschlusstechnologie, 324 Storage Area Network, VI, 13, 156, 253, 255, 273 Storage Area Network-Technologien, 154 Storage Area Networks, X, 4, 52, 154, 181, 197, 290 Storage Controller, 286 Storage Geschäft, 317 Storage Infrastruktur, 5 Storage Investitionsstau, 320 Storage Konsolidierung, 185 Storage Lösungen, 318 Storage Managementkonzept, 1 Storage Networking Industry Association, 242, 320 Storage Netzwerk, 285 Storage Schutzklassen, 163 Storage Security, 273 Storage Tiers, 324 Storage Umfeld, 316, 317 Storage und Security Konzept, 119 Storage-Administration, 280 Storage-Cells, 345 Storage-Herstellern, 60 Storage-Infrastruktur, 17, 20, 22, 25, 289 Storage-Klassen, 290, 291 Storage-Klassifizierungskonzepte, 235 Storage-Managements, 286 Storage-Migrations, 71 Storage-Netzwerk, 275

412

Sachwortverzeichnis

Storage-Netzwerken, 279 Storage-on-Demand, 286 Storage-Resource-Management, X Storage-Ressourcen-Management, 291 Storage-Router, 55 Storage-Sicherheit, 63 Storage-Systeme, 280 Storage-Umfeld, 362 Storage-Virtualisierung, 53 Storageagent, 179 Storageagenten, 180 Storageanbieter, X Storagebasierende Migrationsverfahren, 141 storagebasierenden Migrationsverfahren, 141 Storagefunktionalität, 159, 197 Storagehersteller, 173 Storagekonsolidierung, 187 Storagemigrationen, 123 Storagenetzes, 277 Storagepools, 123, 188 Storageports, 168 Storageseitig, 126 Storagesystem, 161, 167 Storagesysteme, 168 Storagesystemen, 88, 167 Storagesystemhersteller, 126 StorageTek, 60, 94, 141, 195 StorageWorks Produktfamilie, 316 StorageX, 350, 351 Store, 343 Strafen, 158 strafrechtliche Verfolgung, 158 Strategie der Unterstützung der Geschäftsprozesse, 23 Strategie für die Informationswert, 18 Strategie-Mix, 16 Strategien des Information Management, 8 Strategien Mix, 18 Strategien-Mix, 16, 19, 21, 24 strategische Herausforderung an die IT der Gegenwart, 6

Strategische ILM-Modelle, 57 strategische Planung eines Archivsystems, 158 Streaming, 153 Strom, 123 STTS, 296 ständige Verfügbarkeit, 62 Störfallauslösung durch Benutzermeldung, 264 Störfallauslösung durch Betriebsalarm, 264 Störungen, 24, 140 Störungsfall, 22, 25 Suche nach Informationen, 2 SUN, 46, 94, 184, 250 SUN (StorageTek), XI Sun Microsystems, 60, 249 SUN/Storagetek FLX, 29 SVG, 311, 313 Switch-Downtime, 162 Switche, 13 switched Backend über Crossbar Switch, 320 switched SAN Umgebung, 87 Switchen, 167 Switches, 161, 162, 165, 173, 208 Switchhersteller, 181 Switchportkarten, 168 Switchports, 165, 167 Symantec, 65, 250, 346 Symmetrix, 29 synchron oder asynchron zu spiegeln, 277 synchrone Sicherung, 277 synchrone und asynchrone Abgleiche mit zentralen Systemen, 18, 21, 24, 27 Synchrone und asynchrone Spiegelung, 29 synchrone vs. asynchrone Remote Kopien, 324 synchronem Spiegelungsverhalten, 177 Synchronisieren, 155 synthetische Backups, 198

Sachwortverzeichnis

System Management Initiative, 316 Systemabsturz, 42 Systemadministratoren, 280 Systeminformationen, 162 Systemkomponenten, 152 Systemmanagementumgebung, 22, 25 Systemmigrationen, 97 systemübergreifenden Seitenbeschreibung, 311 Sättigungsphase, VIII Tag Switching, 278 Tagged Image File Format, 307 Tagged PDF, 313 TagmaStore, 29 TagmaStore Network Controller, 321 TagmaStore Universal Storage Platform, 321–323 TagmaStore Universal Storage Plattform, 322 Tape, 316 Tape Libraries, 123, 208 Tape Library, 285 Tape-Drives, 295 Tape-Emulation, 180 Tape-Libraries, 167, 188, 197 Tape-Library, 180 Tape-Librarylizenzen, 180 Tapedrive der Library, 180 Tapedrives, 165, 168, 174, 179, 180, 197 Tapes, 5, 294 Tapestry FLM, 350 Tapestry StorageX, 351 Target, 285 TCO, 155 TCO-basierten Kosten- und Leistungsverrechnung, 77 TCO-Betrachtung, 9, 30 TCO-Betrachtungen, 28 TCO-Reduzierung, 57 TCSEC, 276 Teamarbeit, 112 Teambildung, 90, 112

413

technisch und rechtlich sichere Aufbewahrung, 299 Technische Anforderung Storagesysteme, 161 technische Entwicklung der Speichersysteme, 4 technischen Realisierungsansätze, VI technischer Support, 5 technisches Projektmanagement, 72, 79 Technologieauswahl, 150 technologiegetriebene Speicherkonsolidierung, 4 Technologiewechseln, 158 Technologieänderungen, 157 technologische Entwicklung von Speichersystemen, 156 technologische Weiterentwicklungen, 123 Teilabnahme von Projektmeilensteinen, 84 Teilergebnisse, 2 Teilprojekt, 123 Teilprojekt Administration, 102 Teilprojekt Infrastruktur, 102 Teilprojekt Infrastruktur (und Netzwerke), 123 Teilprojekt Kapazitätsmanagement, 101 Teilprojekt Produktionssteuerung, 102 Teilprojekt SAN, 102 Teilprojekt Servermigration, 102, 123, 126 Teilprojekt Storage, 102 Teilprojekte Servermigration, 123 Teilprojekten, 119 Teilprojekten Servermigration und Storage, 141 Teilprojektes SAN, 123 Teilprojektplan, 126 Teilziele, 88 Terabyte, 3 Terminalservice, 16 Terminplanung, 105

414

Sachwortverzeichnis

Terminziele, 89 Tertiär-Speichertechnologien, 29 Tertiärtechniken, 123 Test der Datentypisierung und Archivierung, 233 Test der Migration, 198 Testkonzept, 119, 199, 209 Testnetz, 188 Testplan Windows Cluster, 221 Tests aller Backup-Einrichtungen, 298 Text-Dokumente, 12 Thumbnail, 307 Tier 1, 32 Tier 1 Storage, 29 Tier 2, 32 Tier 2 Storage, 29 Tier 3, 32 Tier 3 Speicher, 233 Tier 3 Storage, 29 Tierd-Storage-Modells, 61, 235 tiered IT-Plattform, 23, 26 tiered IT-Plattformen, 17, 23 tiered IT-Plattformen., 26 tiered Speicherinfrastruktur, XI, 71 tiered Speicherumgebung, 253 Tiered Storage, 60, 236, 251–253, 321, 322, 324, 355, 356 tiered Storage, 355 tiered storage, 269 Tiered Storage Ansatz, 322 Tiered Storage Ansatzes, 316 Tiered Storage Architekturen, 317 Tiered Storage Konzept, 320 Tiered Storage Technologien, 29 Tiered Storage Umgebung, 321 Tiered Storage Umgebungen, 321 tiered Storagesystemen, 18, 21, 24, 27 Tiered-Storage, 344 Tiered-Storage Ansatz, 185 Tiering, 324 Tiering von Kapazitäten, 324 TIFF, 307–310 TIFF Spezifikationen, 307 TIFF Technical Notes, 308

TIFF-Bildes, 307 TIFF-Dateien, 307 TIFF/EP, 307 TIFF/IT ISO 12639:2004, 307 Time to Market, 15 Tivoli, 22, 25 Tivoli Storage Manager, 160, 174, 197, 345 Tivoli-Management Plattform, 161 Tivolis, 345 TK-Unternehmen, 3 Toll-Collect, 66 Total Cost of Ownership, 76, 151, 355 Total Storage Productivity Center for Data, 345 Totalverlust, 169 Tracks, 164 traditioneller Bandbibliotheken, 296 Traffic Engineering- und Quality of Service-, 278 Transaction Integrity – Server exclusive/shared, 298 Transaktionen, 154 transaktionsorientierte Leistung, 180 transaktionsorientierte Leistung der Storagesysteme, 180 transparent im SAN, 180 Transparent Migration Manager, 318 transparent Zugriff, 351 transparente Bereitstellung des Spiegels am Host, 159 transparente Zugriff, 153 transparenten Zugriff, 351 transparentes und regelbasiertes Information Lifecycle Management von Dateibeständen, 348 Transparenz der Verwaltung, 168 Transparenz- und Publizitäts-Gesetz, XIII TransPubG, XIII Treiber, 157 Trends im Speichermarkt, 315 Trennen der Arbeitslast zwischen File- und Blockorientierten Zugriffen, 152

Sachwortverzeichnis

Trennung aller Netzwerkverbindungen, 226, 229 Trennung beider FC-Verbindungen zum Speichersystem, 226 Trennung der HBA’s, 165 Trennung einer FC-Verbindung zum Speichersystem, 225, 229 Trennung vom Public LAN, 225, 228 Triple-DES, 65 Trojanern, 181 TRU64, 161 TrueCopy, 322 TrustedBSD, 276 TrustedSolaris, 276 Try and Buy Lösung, 186 Try & Buy Konzept, 183 Try-and-Buy, 199 Try-and-Buy Option, 186 TSM, 160, 180, 195, 208 TSM-Administrationsserver, 174 TSM-Einbindung, 186 TSM-Server, 179, 180, 198 Tunnel, 275 Twin location automated, businessintegrierte Solution, 298 typischen Lebenszyklus von Informationen, 10 Typisierung, 324 täglichen Arbeitszeit, 2 über SAN angeschlossene Speichermedien, 155 über Storage Area Networks, 150 Überwachung, 152 Überwachung der Grundfunktionalitäten, 181 Überwachung des Gesamtsystems, 151 Umfeldanalyse, 73 Umkopierungsaktivitäten, 25 Umschalten zu Notfallrechenzentren, 14 Umschalten über ein Cold-StandbySystem., 177

415

Umschaltung auf ein Cold-StandbySystem, 176 Umschaltung auf ein Hot-StandbySystem, 176 Umschaltung durch ein Clustersystem, 177 Umschaltung mit Cold–StandbySystem, 177 Umschaltung per Cluster, 176 Umschaltung vom Primärstandort auf den Remote Standort, 177 Umsetzung der Projektänderung, 86 Umzug, 123 unerwarteten Ausfallzeiten, 24, 140 ungeplante Produktionsunterbrechung, 65 ungesicherter Klartexttunnel, 275 Universal Star Network, 321 Universal Storage Platform, 322, 324 University of California, Berkeley, 18 UNIX, 151, 165, 200, 210 Unix, 19, 150, 276, 351 Unternehmenskennzahlen, 7 unternehmenskritischen Geschäftsprozesse, 66, 209 Unternehmenszahlen, 7 Unterschied der Split Mirror Technik gegenüber der SNAP-Technik, 180 unterschiedliche Schutzklassen für die Datenplatten, 169 unterschiedliche ServiceWertigkeiten, 169 unterschiedliche Stati der auftragsbezogenen Informationen, 10 unverfälschbare Langzeitarchivierung, 158 unverändert, 157 Updates, 16 USP, 322 USV, 195, 202 V-Modell, 72, 79 V-Modell und V-Modell-XT basiertes Projektmanagement, 72

416

Sachwortverzeichnis

V-Modell-XT, 72 V-Modells, 79 Value driven Klassifizierung, 248 Vektorgrafiken, 310 Verantwortung, 123 verbesserte Servicelevel, 157 Verbesserung der Security, 285 Verbindung zum Remote Mirroring, 126 Verbindung zum Remotespeicher, 167 Verdichtung, 29 Verdichtungs, 10 Verdichtungs- und Nutzungsphase, 19 Verdichtungsphase, 10, 14, 34 vereinbarten Projektgrößen, 82 Vereinfachung, 86 Vereinfachung der Administration der Softwareinfrastruktur, 16, 25 Verfahren für eine Datensicherung und Wiederherstellung, 153 Verfahren zur Daten-Speicherung, XIII Verfahren zur Zugangskontrolle auf Dateien oder Dienste, 279 Verfahrenshandbuch, 126 Verfügbarkeit, 5, 151, 157, 160 Verfügbarkeit der Speichersysteme, 182 Verfügbarkeitsklassen, 174, 182, 267 Verhinderung von Mehrfachkopien, 21 VERITAS, 347 Veritas, 65 Verlauf des Informationswertes, 32 verlustbehaftete Kompression, 309 verlustfreien Komprimierungsalgorithmus, 308 Vermeidung von Single-Points-ofFailure, 199 vernetzte, mehrstufige Speicherlandschaft, 290 vernetzten Dateispeichersystemen, 351 verschlüsselte Übertragung, 275

Verschlüsselung, 64 Verschlüsselung der Daten, 294 Verschlüsselung des Backups, 294 Verschlüsselung von Daten, 63 Verschlüsselungs, 5 Verschlüsselungskonzepte für Backup-Daten, 297 Verschlüsselungsmechanismen, 273 Verschlüsselungsprozesse, 296 Verschlüsselungsverfahren, 65 Versorgung mit Sekundär, 123 Verteilte Netzwerke, 298 verteilten Speicher-Umgebung, 278 verteilter Speichersysteme der Zukunft, 345 vertraglichen Relevanz, 123 Vertragsmanagement, 126 Vertragsverhandlung, 123 Vertraulichkeit und Konsistenz von Daten zu sichern, 279 Verwaltbarkeit der Gesamtumgebung, 156 Verwaltbarkeit und die Flexibilität der Geschäftsumgebung, 154 Verwaltung, 150, 153 Verwaltung der Daten, 346 Verwaltung der Zugriffsrechte, 276 Verwaltung von vernetzten Dateispeichersystemen, 351 Verwaltungskosten, 150 4-stufige SLA Matrix, 169 24/7 Zugreifbarkeit, 6 vierten Herausforderung an die IT, 7 Virenschutz, 181 Virtual Private Machines, 322 Virtual Private Network, 275 Virtual-Tape, 295 Virtual-Tape-Library, 295 Virtualisierung, V, XIII, 60, 322 Virtualisierung für den Online-, Nearline- und NAS-Bereich, 42 Virtualisierung heterogener Speichertechnologien, 321 Virtualisierung im Online-, Nearlineund NAS-Bereich, 53

Sachwortverzeichnis

Virtualisierung von intern und extern angeschlossener Speicherkapazität, 321 Virtualisierungs-Modell, 52 Virtualisierungsstrategien im FileUmfeld, 348 Virtualisierungstechnik, 315 Virtualisierungstechnologie, VI, 322 virtuelle Backup-Volumes, 295 virtuelle Festplatten, 285 virtuelle Magnetbänder, 29 Virtuelle Private Network, 274 virtuelle Privatnetze, 274 virtuelle Speichersysteme, 323 virtuelle Subnetzwerke, 285 virtuellen LANs, 285 virtuellen Tape-Librarys, 179 Virtuelles Magnetband, 324 Visualisierung der Portfolio Analyse des Informations Managements, 30 VLAN, 181, 285 VMWare, 315 voll compliant Archivierungssystem, 184 Voll- und Inkrementellen-Backups, 198 Voll-Restore aus dem Backup, 200 Vollkopien, 248 Vollportfolio, 318 Vollsortimenter, 202, 315, 317, 320, 326, 346 Volume-Replikationsmöglichkeiten, 155 Volumemanagement-Kommandos, 200 Vorbereitung und Durchführung der Ausschreibung, 150 Vorgehen zur Bieterauswahl und Beauftragung, 186 vorgesehenen Backup-Verfahren, 198 vorhandene Serverlandschaft, 188 Vorläuferphasen, 23 Vorschaubild, 307

417

Vorschriften für die Archivierung digitaler Dokumente, 302 Vorteile von Tape- und Disk-Backup, 295 Vorteile von über NAS angeschlossenen Speichermedien, 151 Vorteile von über SAN angeschlossenen Speichermedien, 155 VPN, 275 VPN-Client, 275 VPN-Gateway, 275 VPN-Server, 275 VPNs, 274 VTL, 179, 180, 295 VTL-Backup, 180 VTL-Instanz, 295 VTL-Lösung, 297 VTL-Lösungen, 296 VTL-Produkt, 346 wachsende Kostendruck, 1 Wachstum der Informationsmengen, 3 Wachstum des Archivs, 158 Wachstums- und ChangeManagement, 155 Wachstumsphase, VIII Wahl des Migrationsverfahrens, 199 WAN, 63, 273, 278, 290 WAN-Verbindungen, 167 Wartungsanforderungen, 182 Wartungsfall, 161 Wartungspersonals, 177 Wartungsverträge, 182 Wasser, 123 Web-Format, 308 WebDAV, 325 Webmaster, 280 Wechselmedien, 19 Wedlich, 346 weniger kostenintensive Medien, 17, 20 wenigsten kostenintensive Medien, 23 Wert der Daten nach Moore, 33 Wert der Information, IX, 12

418

Sachwortverzeichnis

Wert der Informationen, XI Wertanalysen, VII Wettbewerbsfähigkeit, 7 Wettbewerbsvorteil, 15 Wettbewerbsvorteile, 15 Whiscy-Syndroms, 92 Wide Area File Services, 349 Wide Area Network, 290 Wide Area-Technologien, 349 widersprechen, 299 Wiederfinden des Datums, 153 Wiederherstellbarkeitsforderung, 10 Wiederherstellung, 153 Wiederherstellung des primären, 209 Wiederherstellung eines primären Servers, 209, 213 Wiederherstellung nach einem Totalausfall, 348 Wiederherstellung primärer Standort, 214 Wiederherstellungsprozess, 291, 292 Wiederherstellungsreihenfolge, 179 Wiederherstellungszeitziel, 32 Wiederherstellzeiten, 169, 179 Wiederverwendungswahrscheinlichkeit, 34 Wiederverwendungswahrscheinlichkeit, 25 Wiederverwendungswahrscheinlichkeit erstellter Daten, 19, 24 Windows, 46, 151, 160, 161, 351 Windows , 165 Windows Advanced Cluster-Umfeld, 210 Windows NT, 277 Windows Object Manager, 277 Windows Systeme, 19 Windows-Clusterbedingungen, 200 Windows-Filesysteme, 210 wirtschaftlichen Ausnutzung der Archivkapazität, 158 Wissen und Information 2005, VI Wissensreservoir, 2 WLAN, 296 WLANs, 275, 279

Workload Balancing, 322 World Wide Name) Zoning, 285 World Wide Web Consortium, 306 Worldcom, 7 WORM, 316 WORM-Disk-basierenden ContentSpeicher, 345 WORM-Jukebox-Systeme, 159 Worms, 181 WWN, 286 WWN Zoning, 285 WWN-Zoning, 285 WWPN-Zoning, 182 WWPN-Zoning im SAN, 183 Wörterbuch-Attacke, 297 XAM, 244 XAM-Klassifizierung, 249 XFS, 276 XML, 306, 307, 311, 313 z/OS, 19 z/Series Mainframes, 19 10-jährige Aufbewahrungspflicht, 10 Zeitalter des E-Business, 1 zeittoleranten Daten, 292 zeitzonenüber-greifendes Geschäft, 6 zentrale Datenspeicherungen, 274 zentrale Steuerungsgremium des Projektes, 82 zentralen Administration, 150 zentralen Administration des Gesamtsystems, 155 zentralen Datenhaltung, 278 Zentralen Datenspeicherinfrastrukturen, 278 zentralen Datenspeicherung, 274 zentralen Management, 152 zentraler Administration, 151 zentrales Management, 154 zentralisierte Speichersysteme, 150 zentralisiertes, 151 Zentralisierung der Datenhaltung, 150

Sachwortverzeichnis

Zero or little data loss – Server exclusive/shared, 298 Zerstörung der Daten, 173 Zertifikate, 64 Zertifizierungslehrgängen, 78 Ziel der Senkung der TCO, 24 Ziele der Strategischen IT-Planung, 44 Zielerfüllungsgrad, 202 zielgerichteten Speicherung, 1 Zoning, 63, 176, 200, 201, 215, 285, 286 Zoning der HBA’s, 200 Zoning des SAN, 182 Zoning im SAN, 176 Zoning im SCSI-Protokoll, 285 Zoningänderung, 177 zu archivierenden Daten, 270 Zugangskontrollen, 273 Zugriff auf herstellerspezifische Datenbanken, 183

419

zugriffsberechtigten Server, 286 Zugriffskontrolle, 64 Zugriffsmustern, 350 Zugriffsrechte, 349 Zugriffsschutz, 325 Zugriffssoftware, 5 Zugriffstabellen, 286 Zukunftssicherheit der Daten, 157 Zulässige Archivierungsformen, 301 Zuordnen der LUN’s, 200 Zuordnen der LUN’s zu den Hosts, 200 Zuordnung von SLA Modulen pro Anwendung, 170 Zusatzsoftware, 153 Zuschlag, 123 Zutritts- und Gebäudeschutz, 123 2-Standort-Prinzip, 159 Zwei-Rechenzentren-Konzept, 181 Zwischensicherung, 13