Leitfaden zur Einführung einer automatisierten Softwareverteilung

Inhaltsverzeichnis

I. Abkürzungsverzeichnis

II. Tabellenverzeichnis

III. Abbildungsverzeichnis

1 Einleitung und Motivation

2 Wirtschaftlichkeit
2.1 Kosten bei manueller Installation
2.2 Kosten bei Einsatz einer Softwareverteilung
2.3 Nutzenaspekte
2.3.1 Vorteile
2.3.2 Nachteile

3 Anforderungskatalog einer Software-Verteilung
3.1 Installation ohne Interaktion (unattended Installation)
3.2 Individualisierbarkeit
3.2.1 Maschinenspezifische Parameter
3.2.2 Differenzierung in Funktionstypen
3.3 Protokollierung und Nachvollziehbarkeit
3.3.1 Logging
3.3.2 Verteilaufträge
3.4 Fehlermanagement
3.4.1 Meldung von Verteilfehlern
3.4.2 automatische Korrektur
3.4.3 Rollback
3.5 Scheduling
3.6 Lokale Sicherheit
3.7 Plattformunabhängigkeit
3.8 Skalierbarkeit
3.9 Bandbreitenmanagement
3.10 optionale Softwarekomponenten / Software On Demand
3.11 Reparierfähigkeit
3.12 Lizenzmanagement
3.13 Löschen von Software

4 Inventarisierung
4.1 Inventarisierung der Hardware
4.2 Inventarisierung der Software

5 Verteiltechniken
5.1 Push-Technik
5.2 Pull-Technik

6 Softwarepakete
6.1 Installation / Konfiguration mit Scripten
6.2 Verteilung mittels Paketen
6.3 Status-Rückmeldung (Return-Code)
6.4 Integration und Verteiltests

7 Installationen via Softwareverteilung
7.1 Betriebssystem
7.2 Gerätetreiber
7.3 Anwendungen
7.4 Updates und Fehlerkorrekturen
7.5 Individuelle Einstellungen und Anpassungen

8 Ebenen der Verteilsteuerung
8.1 atomare Verteilung
8.2 Verteilung auf Produkt-Ebene
8.3 Verteilung auf Release-Ebene

9 beteiligte Softwarekomponenten
9.1 Server-Komponenten
9.2 Client-Komponente
9.3 Verwaltungssystem und Bedienoberfläche

10 Netzstruktur
10.1 Netzsicherheit
10.2 SV in LANs
10.3 SV in WANs

11 Software-Images
11.1 zentrale Images
11.2 dezentrale Images (Mehrstufige Verteilung)
11.3 lokale Imagehaltung

12 Kritische Würdigung

13 Zusammenfassung

IV. Literaturverzeichnis

Anhang A: Markübersicht von Softwareverteillösungen

Anhang B: Beispiel einer Antwortdatei zur unattended Installation

Erklärung:

Ich versichere an Eides Statt durch meine Unterschrift, dass ich die eingereichte Diplomarbeit selbstständig, ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder sinngemäßaus veröffentlichten und nicht veröffentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit hat in dieser oder ähnlicher Form oder auszugsweise im Rahmen einer anderen Prüfung noch nicht vorgelegen.

Bühl, 01.10.2004

Rüdiger Kelkel

I. Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten^{1 * 2}

II. Tabellenverzeichnis

Tabelle 1: Beispiel einer Datenbasis für einen Computer zur SV

Tabelle 2: Beispiele von SV-Funktionstypen

Tabelle 3: Beispiele für Log-Datei-Einträge

Tabelle 4: einige Ziele eines Scheduling-Algorithmus

Tabelle 5: Return-Codes des Windows Installers

Tabelle 6: Aufbau einer Anwendung aus atomaren Paketen

Tabelle 7: Beispiel-Release der Version x.y

Tabelle 8: Dienstoperationen im Client/Server-Modell

Tabelle 9: Beispiele einiger Portnummern

III. Abbildungsverzeichnis

Abbildung 1: Aufteilung der Kosten eines PCs, Quelle Gartner Group

Abbildung 2: Einblick in ein MSI-Paket

Abbildung 3: Software Lifecycle-Phasen: Installation und Betrieb

Abbildung 4: Release-Fortschreibung: Branching und Merging

Abbildung 5: Client/Server-Modell

Abbildung 6: abgehörte Übertragung

Abbildung 7: sicherer Kanal

Abbildung 8: Zentrale Imageversorgung

Abbildung 9: mehrstufige Imageverteilung

Abbildung 10: Dezentrale Imageversorgung

Abbildung 11: Marktübersicht Softwareverteilungslösungen

1 Einleitung und Motivation

Unternehmen, deren EDV-Landschaft sich ausweitet und die mehr und mehr die Computertechnologie nutzen, stehen irgendwann vor der Aufgabe, diese Computersysteme effizient d.h. mit geringem manuellen Aufwand verwalten zu können. Hierzu haben sich am Markt einige Standardlösungen etabliert; man spricht von Systems Management Software. Hierzu hört auch die Verteilung von Software.

Denn das von Hand Bespielen und Updaten von Computern stellt sich als eine zeit- und somit kostenaufwendige Aufgabe dar; viele Rechner müssen quasi mit denselben Softwarekomponenten versorgt werden, also eine sich mehrmals in gleicher Weise wiederholende Tätigkeit. Hinzu kommt, dass oftmals die Geräte über mehrere Standorte verteilt sind; der Standortwechsel des EDV-Personals stellt dann einen weiteren Zeit- und Kostenfaktor dar.

Wenn eine gewisse Anzahl von Computern im Unternehmen eingesetzt wird, entsteht somit die Notwendigkeit, diese automatisiert mit Software zu versorgen. Sowohl die Erstversorgung mit dem Betriebssystem, mit Systemsoftware und Anwendungen als auch das spätere Aktualisieren der Software durch Fixe (Fehlerkorrekturen) und Updates soll automatisiert erfolgen, ohne großen manuellen Aufwand des EDV-Personals.

Auch soll im Falle eines Ausfalls eines Computersystems schnell und ohne allzu großen Aufwand ein Ersatzrechner bespielt werden können, der bestenfalls über die gleiche Betriebssystem-Installation und identische Anwendungsprogramme verfügt.

Die Infrastruktur einer automatischen Softwareverteilung (kurz SV) spiegelt sich in einem verteilten System wider; es arbeiten Komponenten zusammen, die sich auf vernetzten Computern befinden und kommunizieren.³ Diese werden in dieser Arbeit genannt und beschrieben.

Ziel der vorliegenden Arbeit ist es, allgemein aufzuzeigen, welche Systemkomponenten grundsätzlich notwendig oder optional sind, um eine automatische Softwareverteilung zu realisieren. Es werden Ansätze unterschiedlicher Konzeptionen erläutert. Es wird ein Leitfaden an die Hand gegeben, der hilft, die Anforderungen an eine SV zu definieren und Standardlösungen an diesen zu messen.

Ziel ist es nicht, die am Markt verfügbaren Standardprodukte zu untersuchen, gegeneinander abzuwägen oder in einem Unternehmen einzuführen. Dennoch ist eine Betrachtung einzelner Teilaspekte mitunter hilfreich, die Funktionen und Konzepte der automatisierten SV besser zu verstehen.

Aufgrund des sehr hohen Marktanteils an Computern mit Microsoft Windows Betriebssystemen wird stellenweise auf Eigenheiten und Besonderheiten in diesem Umfeld detaillierter hingewiesen. Dennoch gilt das hier konzeptionell Erarbeitete auch für andere Umfelder.

2 Wirtschaftlichkeit

Hauptziel beim Einsatz von Systems Management Software ist es, EDV-Systeme von zentraler Stelle aus effizient verwalten und gleichzeitig die Betriebskosten für Änderungsund Konfigurations-Management zu senken.

Es gilt, die Kosten für das Systems Management durch eine entsprechende Lösung zu minimieren, die optimal in die jeweilige Umgebung passt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufteilung der Kosten eines PCs, Quelle Gartner Group⁴

Da eine automatisierte Softwareverteilung als Teil einer Systems Management Lösung implementiert wird, gilt das Gesagte in vollem Umfang auch für diese.

Gegenüberzustellen sind die Kosten, wenn Software manuell installiert wird und die Kosten, wenn man die Software automatisiert verteilt.⁵

Softwareverteilungen lassen sich unterschiedlich stark automatisieren. Eine Minimallösung könnte beispielsweise darin bestehen, über ein Netzwerk eine Datensicherung zurückzuspielen und diese dann nachzukonfigurieren, indem man z.B. den Computernamen, die IP-Adresse und ähnliches anpasst. Die Maximallösung hingegen ist in der Lage, Rechner komplett zu bespielen und zu konfigurieren. Denkbar ist sogar, dass mittels einer EDV-Anwendung eine Bespielung komplett vorbereitet wird, Parameter wie die IP-Adresse, notwendige Hardware-Treiber etc. werden EDV-unterstützt ermittelt und in Verteilpläne eingebaut, mit dem Ergebnis, dass nach der Verteilung ein voll konfigurierter Rechner zur Verfügung steht, mit dem sofort gearbeitet werden kann.

Eine Softwareverteilung ist tendenziell natürlich umso kostenintensiver, je leistungsfähiger sie ist. Plant ein Unternehmen also eine SV, so ist zu berücksichtigen, was automatisiert werden soll und was noch manuell getan wird. Je mehr und jeöfter Computer zu verteilen sind, umso eher lohnt es sich, stärker in die Automatisierung zu investieren.

2.1 Kosten bei manueller Installation

Grundsätzlich lassen sich Kosten in Personal, Technologie- und Prozesskosten aufteilen. Personalkosten sind in der Vergangenheit gestiegen und werden dies vermutlich auch weiterhin tun. Technologie hingegen wird, wenn man gleiche Kapazität und keinen Technologiewechsel unterstellt, günstiger. Prozesskosten sind stark individuell, lassen sich aber durch Automation senken.⁶

Bei einer manuellen Installation fallen „nur“ die Kosten für die Erstinstallation und Installation von Updates an. Diese bestehen nicht lediglich aus reinen Personalkosten, sondern auch Reisekosten etc. müssen ggf. mitberücksichtigt werden. Diese Kosten sind nahezu proportional zur Anzahl der Systeme; Einsparungen aufgrund einer großen Anzahl von Installationen sind sehr gering.

2.2 Kosten bei Einsatz einer Softwareverteilung

Die Anzahl der Kostenpunkte ist hier deutlich größer; im Wesentlichen sind diese:

1. Beschaffungs- oder Entwicklungskosten aller notwendigen Softwarekomponenten
2. in der Regel zusätzliche Hardware
3. Schulung
4. Implementierung des Systems
5. Wartung des Systems
6. Herstellung von verteilfähigen Paketen (Softwarekomponenten)
7. Verteilung der Pakete

Bei einer größeren Anzahl von Systemen fallen die nichtproportionalen Kosten 1 - 6 zunehmend weniger ins Gewicht verglichen mit den Gesamtkosten. Die proportionalen Kosten, nämlich die Verteilung der Pakete (Punkt 7) ist sehr viel kostengünstiger als das manuelle Bespielen eines Rechners. Im Hinblick auf die Gesamtkosten ergeben sich also Skalenerträge oder Kostendegressionseffekte.

Unter Kostengesichtspunkten ist natürlich anzustreben, dass die oben genannten Posten möglichst gering ausfallen. Dabei ist unter anderem darauf zu achten, dass die vorhandene teuere Hardware optimal genutzt werden kann und dass die Herstellung von verteilfähigen Paketen überschaubar ist und nicht ein benutzerunfreundliches und fehleranfälliges Unterfangen wird.

Wie bei allen größeren IT-Projekten ist eine ausführliche Kosten/Nutzen-Analyse unumgänglich. Hierbei wird das Vorhaben wirtschaftlich beurteilt. Und zwar werden dabei die Auswirkungen unter Berücksichtigung relevanter Nebenwirkungen während der Zeit der Einführung vorausschauend ermittelt und dann auf den Zeitpunkt des Nutzungsbeginns bezogen in Geldgrößen bewertet.⁷

2.3 Nutzenaspekte

Beim Einsatz von Systems Management Lösungen, also auch bei einer automatisierten SV, stehen zwar Kostenaspekte im Vordergrund, aber auch die Vor- und Nachteile sind gegenüberzustellen. Die wichtigsten sollen folgend skizziert werden.

2.3.1 Vorteile

Einheitlicher Softwarestand: Werden Computersysteme automatisiert installiert, so besteht die Möglichkeit, Rechner auf einem definierten Stand zu halten. Man kann auf diese Weise vermeiden, dass ein “Wildwuchs“ entsteht. Auf allen Rechnern ist beispielsweise die gleiche Version eines Softwareproduktes installiert. Ferner kann man Konfigurationen gleichhalten, was bewirkt, dass sich die Systeme ähnlich verhalten. Beides ist bei manueller Installation nur sehr schwer und mit großem organisatorischem Aufwand zu realisieren, und dies umso stärker, je mehr Mitarbeiter mit diesen Aufgaben betraut sind.

Erreichbarkeit: Mit einer SV können sehr viele Systeme, die räumlich sehr weit auseinander stehen, innerhalb einer kurzen Zeitspanne durch wenig EDV-Personal mit Software verteilt werden. Als Beispiel mag hier eine Sparkasse oder Volksbank genannt werden, welche 1000 Systeme in einem Umkreis von 50 km betreibt. Es ist leicht einzusehen, dass diese nicht von Hand installiert bzw. aktualisiert werden können.

Verbesserter interner Support: Interne Support-Anfragen entstehen oft durch defekte bzw. zerstörte Installationen oder Konfigurationen. Mit dem Einsatz einer SV ist es in der Regel möglich, schnell etwas nachzuverteilen, um den Fehler zu beseitigen. Zwar helfen Fernwartungs-Tools, mit denen man einen Rechner von der Ferne sehen und bedienen kann, beim Diagnostizieren, aber eine beschädigte Installation kann hiermit nur in seltenen Fällen oder nur mit sehr großem Aufwand korrigiert werden.

Benutzerfreundlichkeit: Für das EDV-Personal fallen deutlich weniger Routineaufgaben an. Neben den zeitlichen Aspekten ist dies auch vorteilhaft für die Motivation und Arbeitszufriedenheit der Mitarbeiter.⁸

2.3.2 Nachteile

Die Vorteile einer SV müssen dem zu betreibenden Aufwand und den Kosten gegenübergestellt werden.

Eine automatisierte SV hat, wenn sie entsprechend den Bedürfnissen eingesetzt wird, keine besonderen Nachteile. Allerdings gelten die gleichen “Probleme“ wie bei jeder EDVLösung. Denn auch ein SV-System obliegt einem Lebenszyklus und muss gepflegt und in der Regel irgendwann abgelöst werden.

3 Anforderungskatalog einer Software-Verteilung

Dieser Abschnitt beschäftigt sich mit der Frage, was eine Implementierung für eine automatisierte SV leisten kann, soll oder muss. Einem Projektteam kann bei der Auswahl (oder Entwicklung) und Einführung eines Systems dieser Anforderungskatalog als Richtschnur dienen.

An dieser Stelle sei darauf hingewiesen, dass eine gewisse Standardisierung im Hinblick auf die eingesetzte Hard- und Software als Grundvoraussetzung für ein effizientes und kostengünstiges Systems Management angesehen werden kann.

3.1 Installation ohne Interaktion (unattended Installation)

Eine Installation via SV muss auch dann ablaufen, wenn niemand an dem Rechner angemeldet ist. Dies kann zum Beispiel dann notwendig sein, wenn der Rechner während der Installation (mehrmals) gebootet werden muss.

Auch darf es in der Regel nicht der Fall sein, dass die Installation auf Interaktionen des Benutzers wartet; alle Dialoge, die während einer herkömmlichen Installation stattfinden würden, müssen durch das EDV-Personal und die SV-Lösung automatisiert werden. Denn nur so ist sichergestellt, dass auf alle Installationsfragen die korrekten Antworten gefunden werden (z.B. wäre ein Sachbearbeiter nicht in der Lage, die Netzwerkanbindung zu konfigurieren). Dies wiederum ist eine wichtige Voraussetzung für eine korrekte und einheitliche oder bestimmten Regeln unterliegende Konfiguration der verteilten EDV- Systeme.

Damit eine SV ohne Interaktion des Benutzers durchgeführt werden kann, können die erforderlichen Informationen in einer Antwortdatei hinterlegt werden (Anhang B zeigt ein Beispiel einer Antwortdatei). Oder dem Installationsaufruf werden entsprechende Parameter mitgegeben (z.B. das Installationsverzeichnis).

Unattended Installation heißt also, dass die Installationsprozedur im Hintergrund abläuft, ohne dass der Benutzer aktiv werden muss oder bei seiner Arbeit eingeschränkt wird.

Unattended Installation heißt aber nicht, dass Verteilungen ohne Informationen oder Einflussnahme der Benutzer ablaufen.

Wenn eine SV zur Arbeitszeit stattfinden würde ohne den Benutzer zu informieren, könnte dies unerwünschte Effekte mit sich bringen. Es ist leicht einsehbar, dass ein Computersystem nicht einfach selbstständig booten darf. Werden mehrere Verteilschritte gestartet, so mag es notwendig sein, den Rechner zwischen einzelnen Phasen zu booten. Ist dies der Fall, ist sicherzustellen, dass der Benutzer den Reboot unterdrücken beziehungsweise verzögern kann. Oder eine Verteilung ist aus irgendwelchen sonstigen Gründen zur Startzeit nicht erwünscht (z.B. wird mit dem System gerade eine Schulung oder Präsentation gehalten); auch dann sollte eine Verzögerung durch den Benutzer möglich sein.

Wenn eine Installation nicht erfolgreich abgeschlossen werden kann, kann eine Meldung am Bildschirm ausgegeben werden. Der Benutzer weißdann, dass der Rechner unter Umständen nicht in allen Bereichen ordnungsgemäßfunktioniert. Ob eine solche Fehlermeldung angezeigt werden soll oder ob diese doch eher Verwirrung stiftet, liegt im Ermessen des EDV-Personals.

3.2 Individualisierbarkeit

Es dürfte in der Praxis nahezu unmöglich sein, mehrere Rechner genau identisch zu installieren und konfigurieren und diese dann in einem Netzwerk gemeinsam zu betreiben. Denn in aller Regel gibt es Unterschiede bei den Konfigurationswerten.

Individualisierbarkeit bedeutet also in Verbindung mit einer SV-Lösung, dass man in der Lage ist, Rechner ganz gezielt unterschiedlich zu verteilen.

3.2.1 Maschinenspezifische Parameter

Eine komfortable und für ein großes Mengengerüst ausgelegte SV-Lösung ist in der Lage, maschinenspezifische Werte in die automatische SV einfließen zu lassen.

Ziel dabei ist, nicht für jeden Rechner, der ein bestimmtes Software-Produkt erhalten soll, eine Antwort-Datei (hier sind in elektronischer Form alle für eine unattended SV benötigten Werte oder mit anderen Worten alle Antworten, die bei einer interaktiven Installation gegeben werden müssten, hinterlegt) individuell von Hand zu erstellen. Vielmehr ist zu realisieren, dass eine Antwortdatei aus allen relevanten Daten mit Hilfe einer Schablonendatei erzeugt und zur Installationszeit mitgegeben wird.

Dies bedingt, dass alle maschinenspezifischen Werte, die für eine SV benötigt werden, in einer Datenbasis vorgehalten und gepflegt werden.

Folgende Tabelle zeigt ein Beispiel maschinenspezifischer Werte; eine solche Tabelle ist für jeden verteilbaren Rechner vorzuhalten:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Beispiel einer Datenbasis für einen Computer zur SV

Die Namen der Variablen sollten sprechend nach Inhalt bzw. Bedeutung gewählt werden. Denn wenn man diese an Software-Komponenten knüpft, stellt sich schnell das Problem von Redundanz; ein Wert wie z.B. der Name des Computers mag von vielen verschieden Komponenten benötigt werden.

Eine Schablonendatei - nennen wir sie antwortdatei1.txt - zur Individualisierung könnte nun folgendermaßen aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Soll nun unser Muster-PC bespielt werden, so ermittelt die SV-Maschine aus der Datenbasis des Rechners die benötigten Belegungen, baut aus diesen Werten und der Schablonendatei eine Antwortdatei - nennen wir sie antwortdatei1.rsp - mit folgendem Inhalt

Abbildung in dieser Leseprobe nicht enthalten

und gibt diese mit zur Installation. Die Installationsprozedur ist in der Lage, die Antwortdatei zu lesen und zu interpretieren.

Individuelle Werte können natürlich nicht nur in Form von Antwortdateien in einer SV ihre Berücksichtigung finden, sondern können als Parameter dem Aufruf mitgegeben werden. Das obige Beispiel könnte dann folgendermaßen aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Die grünen Werte sind Variablen. Das SV-System weißden Namen des Gerätes und legt eine entsprechende Log-Datei an und die beiden Betriebssystem-Variablen werden aus der SV-Datenbank ermittelt und für die Verteilung eingesetzt.

Aus Gründen der Nachvollziehbarkeit empfiehlt es sich, festzuhalten, mit welchen Werten eine Verteilung stattgefunden hat. Denn die Werte mögen sich in der Datenbank ändern und es lässt sich dann nicht mehr nachvollziehen, wie eine Komponente verteilt wurde. Und dies kann später im Zuge von Support-Anfragen der Benutzer notwendig werden.

Eine solche Datenbank ist dynamisch - auch im Hinblick auf die Variablen selbst und nicht nur ihrem Inhalt. Neue Anwendungen mögen per SV installierbar werden; diese mögen für eine unattended Installation Werte benötigen, die die Datenbasis nicht bereithält. Daher ist dafür zu sorgen - technisch oder organisatorisch - dass die Datenbasis gepflegt und bei Bedarf erweitert wird.

Anmerkung:

Neben einer maschinenspezifischer ist auch eine benutzerspezifische Individualisierbarkeit realisierbar. Dies soll aber in dieser Arbeit nicht weiter vertieft werden.

3.2.2 Differenzierung in Funktionstypen

Ferner besteht die Möglichkeit, Rechner mit einer unterschiedlichen Konfiguration von Modulen aus einem Pool von verteilbaren Softwarekomponenten zu versehen. Ein Rechner in der Lagerverwaltung ist zum Beispiel mit anderen Komponenten zu bespielen als ein Rechner, der als CAD-Arbeitsplatz dient. Die folgende Tabelle soll dies veranschaulichen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Beispiele von SV-Funktionstypen

3.3 Protokollierung und Nachvollziehbarkeit

3.3.1 Logging

Unter Logging ist quasi das Gegenstück zu einer Antwortdatei zu verstehen. Denn genauso wenig wie ein Benutzer bei einer unattended Installation Eingaben macht, genauso wenig werden am Bildschirm Ausgaben bezüglich der Verteilung an sich zur Kenntnis genommen. Die Ausgaben, die bei einer manuellen Installation am Bildschirm zu sehen sind, werden auch bei automatisierten Installationen festgehalten, allerdings meist in einem deutlich höheren Detailierungsgrad.

Um Fehler während der Verteilung oder später nicht ordnungsgemäßfunktionierende Software recherchieren zu können, muss die Verteilung protokolliert werden. Dies wird dadurch erreicht, dass eine Log-Datei während der Installation geschrieben wird, die festhält, was während der Verteilung geschieht. Hierzu werden die Ergebnisse jedes Verteilschrittes in die Log-Datei geschrieben. Dabei kann man unterscheiden zwischen Einträgen, die informativen Charakter haben, solchen, die eine Warnung ausgeben und solchen, die Fehler protokollieren.

Es folgen einige Beispiele für Log-Datei-Einträge:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Beispiele für Log-Datei-Einträge

Mit Hilfe dieser Informationen ist es oftmals möglich, schnell Ursachen für Verteilfehler oder -abbrüche zu finden. Aber auch wenn eine SV an sich ordnungsgemäßabläuft, mag es sein, dass sich das Computersystem oder eine Anwendung anschließend nicht so verhält, wie es gewünscht ist. Dann erlauben es gegebenenfalls die Informationsmeldungen der Log-Datei, den Fehler einzugrenzen oder zu finden.

Bezüglich der Realisierung des Loggings ist anzumerken, dass es bei Lösungen wie dem Microsoft Installer (vgl. 6.2 Verteilung mittels Paketen) bereits vollständig implementiert ist; man setzt einen Schalter für den Level (Detailierungsgrad) und übergibt einen Parameter zur Log-Datei (z.B. /l d:\LOG\install.txt). Anders ist dies beim Einsatz von Scripten (vgl. 6.1 Installation / Konfiguration mit Scripten). Hier muss der Entwickler selbst für das Logging Sorge tragen; es gibt aber für einige Scriptsprachen Bibliotheken, die dabei unterstützen.

3.3.2 Verteilaufträge

Nicht nur die eigentliche Verteilung an sich, also die per SV ausgeführte Installation oder Konfiguration sollte protokolliert werden, sondern auch die Beauftragung der SV. Beauftragung heißt in diesem Zusammenhang, wann welche Pakete auf welche Rechner mit welchen Parametern oder Werten aus der Datenbank zur Individualisierung (vgl. 3.2 Individualisierbarkeit) verteilt wurden.

Denn arbeitet eine verteilte Software nicht ordnungsgemäß, kann dies an einer nicht korrekten Verteilung im Sinne einer fehlerhaften Verteilbeauftragung liegen, obwohl das verteilbare Paket an sich fehlerfrei ist. Als Beispiel sei hier die Installation einer verteilten Software genannt, die mit einem Server kommuniziert, der namentlich über die SV- Datenbank in eine Antwortdatei eingebaut wird. Der Server ist in der Datenbank für ein bestimmtes Zielsystem falsch eingetragen; damit funktioniert die Software nicht, da sie falsch konfiguriert ist. Ein solcher Fehler kann zwar in der Regel auch anhand der Log- Datei der eigentlichen Installation lokalisiert werden, aber eine kompakte Darstellung der Beauftragung ist übersichtlicher als eine sehr lange Log-Datei.

Ferner kann es beim Finden von Fehlern hilfreich sein, festzuhalten, von welchem Server die Quelldateien kopiert wurden (vgl. 11.2 dezentrale Images (Mehrstufige Verteilung)). Verteilungen missglücken und werden in der Regel abgebrochen, wenn die Images nicht korrekt d.h. fehlerhaft, veraltet oder unvollständig sind. Kann beispielsweise eine bestimmte Datei gemäßdem Logging nicht kopiert werden, ist es zeitsparend, den benutzten Server über das SV-System in Erfahrung bringen zu können, ohne die in Frage kommenden Server manuell zu überprüfen.

3.4 Fehlermanagement

Nicht immer findet eine Softwareverteilung ohne Fehler statt. Denn das zu installierende Softwarepaket mag auf ein Umfeld treffen, mit dem es nicht umzugehen weiß. Denkbar wäre in diesem Zusammenhang beispielsweise, dass der Festplattenspeicher zur Installation nicht ausreicht. Oder aber es gibt Abhängigkeiten zu anderen Softwarekomponenten, die nicht erfüllt sind.

Ziel des Fehlermanagements im Zusammenhang mit SV ist es, Fehler schnell zu entdecken und möglichst schnell und effizient - also ohne großen manuellen Aufwand - zu beseitigen. Rechnersysteme, die eine SV nicht erhalten konnten, sind mehr oder weniger eingeschränkt in ihrer Einsatzfähigkeit. Im Extremfall ist ein solches System bis zur Fehlerbeseitigung gar nicht mehr nutzbar. ^*

Auch wenn SV-Pakete vor einem produktiven Einsatz ausgiebig getestet werden im Hinblick auf die Ablauffähigkeit und das ordnungsgemäße Verhalten des Systems hinterher, so können nicht 100% der Fehler gefunden werden. Denn erstens sind Referenz- Geräte “sauber“ und nicht händisch manipuliert und zweites können meist nicht alle Anwendungsfälle bis ins Detail überprüft werden (dies wäre nicht wirtschaftlich).

Wenn Verteilungen misslingen, so sind in einem ersten Schritt die Fehlerursachen und die Tragweite zu diagnostizieren. Massenprobleme sind in der Regel wichtiger als einzelne Abbrüche. Produktionseinschränkungen sind meist schlimmer als fehlende Features.

Im nächsten Schritt sind Fehlerbehebungsmaßnahmen einzuleiten und zu überprüfen. Es mag notwendig sein, Benutzer über Verteilprobleme in Kenntnis zu setzen. Wann werden sie beseitigt? Gibt es eine Umgehungslösung für ein Problem?

Wenn größere Software-Rollouts bevorstehen, sollte auch eingeplant werden, möglicherweise anschließend eine Fehlerbereinigung kurzfristig verteilen zu müssen.

Um Fehler recherchieren zu können, sind aussagefähige Log-Dateien hilfreich. Von Vorteil ist es, wenn man ferngesteuert mit Hilfe eines Ferndiagnoseprogramms auf die Rechner zugreifen kann. Solche Programme reichen von textbasierten Lösungen (z.B. Telnet) bis zur Übertragung und Fernsteuerung der grafischen Konsole zum Arbeitsplatz des EDV-Mitarbeiters. Derartige Tools sind oftmals in integrierten Systems Management Lösungen enthalten.

Um mit Verteilfehlern umzugehen, bestehen folgende Alternativen, wobei grundsätzlich am Ende das erfolgreich verteilte Paket stehen muss:

3.4.1 Meldung von Verteilfehlern

Im Falle einer missglückten Verteilung wird das zuständige EDV-Personal in einer komfortablen Art hiervon in Kenntnis gesetzt.

Denkbar ist eine zentrale Datenbank, die mit Hilfe von grafischen Tools oder Tabellen schnell einen Überblick über offene bzw. fehlerhafte Installationen liefert. (vgl. 4 Inventarisierung). Oder eine Meldung wird generiert und an zentraler Stelle gesammelt.

Aufgrund dieser Meldungen sind dann die Fehler zu untersuchen und Beseitigungsmaßnahmen einzuleiten.

3.4.2 automatische Korrektur

Ausgefeilte SV-Systeme sind in der Lage, einige Verteilabbrüche selbstständig zu beseitigen, indem sie die Ursache beseitigen und die Verteilung dann wiederholen.

Ein großer Teil der Verteilabbrüche lässt sich einfach durch einen Systemneustart und einen sofortigen neuen Verteilversuch beheben.

Wie in Abschnitt 6.3 beschrieben, lässt sich durch Return- oder Error-Codes die Fehlerursache eingrenzen oder genau spezifizieren. Diese Codes lassen sich auch maschinell auswerten und nutzen, um das System einige der Ursachen selbstständig korrigieren zu lassen. Ein Beispiel hierfür mag sein, dass ein Code vom Verteilpaket zurückgegeben wird, der auf gesperrte Dateien (Dateien, auf die von anderen Anwendungen/Prozessen zugegriffen wird) hinweist. In diesem Fall mag es ausreichen, den Computer maschinell neu zu booten und einen neuen Verteilversuch zu starten.

Ein SV-System wird nie in der Lage sein, 100% der Verteilfehler selbstständig zu analysieren und zu korrigieren. Doch wenn Standardfälle automatisiert bearbeitet werden, so entlastet dies bei entsprechenden Mengengerüsten erheblich das EDV-Personal.

3.4.3 Rollback

Kann eine SV nicht vollständig und fehlerfrei ausgeführt werden, so sollte eine Wiederherstellung des alten Zustandes (=Rollback) durchgeführt werden.

Um eine Wiederherstellung im Fehlerfall zu gewährleisten muss diese Funktion in den verteilbaren Paketen implementiert werden.⁹ Dies ist umso wichtiger, wenn ein Softwareprodukt aktualisiert wird. Denn es ist für den Benutzer in der Regel möglich, mit der alten Version, wenn auch nur eingeschränkt, weiterzuarbeiten. Bei einer abgebrochenen und unvollständigen Verteilung ist dies ohne Wiederherstellung des alten Zustandes nicht möglich.

Standard-Lösungen wie Pakete für den Windows Installer verfügen bereits über ein solches Feature; das EDV-Personal hat hier für Rollback-Szenarien keine Sorge zu tragen. Anders sieht dies aber bei Installationen und Konfigurationen aus, die mittels selbst erstellter Scripte ablaufen. Hier mag das Implementieren eines Rollback-Feature unverhältnismäßig sein, denn da der Fehler an jeder Stelle im Script auftreten kann, wäre konsequenterweise von jeder Stelle aus ein Rückweg zum Ausgangszustand zu definieren.

Der Rollback-Mechanismus löst nicht das Problem. Aber er vermag es bezüglich der Dringlichkeit deutlich zu entschärfen.^*

3.5 Scheduling

Der Begriff Scheduling wird in der EDV in Verbindung mit multitaskingfähigen Betriebssystemen verwendet. „Wenn Rechner multiprogrammierbar sind, konkurrieren oft mehrere Prozesse zur selben Zeit um die CPU. Diese Situation tritt immer ein, sobald zwei oder mehrere Prozesse gleichzeitig rechenbereit sind“. Dann ist zu entscheiden, welcher Prozess die CPU als nächstes bekommt. Der Scheduler ist hierbei die Komponente des Betriebssystems, die diese Wahl trifft.¹⁰

Diese Logik lässt sich auch auf eine Client/Server-Architektur (auf die Client/Server- Architektur eines SV-Systems wird in 9.1 und 9.2 näher eingegangen) übertragen. Denn es können mehrere Clients quasi gleichzeitig eine Anfrage an den Server stellen, der dann entscheiden muss, in welcher Reihenfolge und mit welcher Priorität er die Anfragen bedient.

Hierbei sind folgende Ziele von Bedeutung:¹¹

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: einige Ziele eines Scheduling-Algorithmus

[...]

---

¹ siehe [Rie01] S. 106

^* Windows Systeme mit 32-Bit Kern

² siehe [Rie01] S. 106

³ [CouDolKin02] S. 17

⁴ [INNEO]

⁵ [NetInstall57] S. 4

⁶ [BITKOM04] S. 6

⁷ [HaNaBeBü97] S.. 490f

⁸ vgl. [RoReDo99] S. 193-203

^* Es sei darauf hingewiesen, dass nur durch ein Testverfahren mit definierten Testfällen größere „Unfälle“ vermieden werden können

⁹ [CouDolKin02] S. 40

^* deutsch: Terminplanung

¹⁰ [TanMBS02] S. 148f

¹¹ [TanMBS02] S. 153