Vor knapp zwei Jahren billigte die COMPUTERWOCHE (in CW 52/89) nur solchen Rechenzentren eine Überlebenschance zu, die ihre Großrechner in Netzwerkhierarchien, Micro-Mainframe-Links und in "Computer-Computer-Verbindungen" einbringen. Wie steht es aber um die Überlebenschancen von Firmen und Dienstleistern, die mehr als ein Großrechenzentrum betreiben?
Sie sollten wohl folgerichtig die gleichen Konzepte genauso integrativ, aber eben entsprechend umfassender gestalten. Ein wesentlicher Aspekt dabei ist das Softwaremanagement quer durch alle Rechenzentren.
Vier Maßnahmen drängen sich auf:
- Vernetzung innerhalb eines RZ
- Vernetzung der RZ untereinander
- Standardisierung der RZ
- Zentrales Softwaremanagement
In den meisten Fällen realisiert ist die Vernetzung der Systeme innerhalb jedes Rechenzentrums. Als zweite Stufe erfolgt sinnvollerweise die Kommunikation der einzelnen Rechenzentren untereinander. Zweck der Übung: Ein leistungsfähiges Datennetz mit technischem Rückgrat aufzubauen.
Eine Standardisierung der RZs ist Voraussetzung
Ein dritter Grad der Kompatibilität wird durch die Standardisierung der RZs hinsichtlich Ausstattung und Leistung erreicht. Die Normierung umfaßt einheitliche Betriebssystemumgebungen, Netzwerkdienste, Sicherheitsroutinen und definierte Arbeitsleistungen und bildet damit eine zuverlässige Basis für optimale Auslastung der vorhandenen Kapazitäten im Netz sowie für Back-up Lösungen und "desaster recovery". Für den Anwender spielt es keine Rolle mehr, aus welchem Standort im Verbund eine Leistung abgerufen wird. Diese "Austauschbarkeit" der Rechenzentren nimmt auch einem GAU im Rechenzentrum seinen Schrecken. Im Fall der Fälle steht ein ebenbürtiger Zwilling zu Verfügung.
Die vierte Stufe ergibt sich zwangsläufig als Folge der ersten drei. Ein Verbund standardisierter Großrechenzentren wird sinnvollerweise auch die Auswahl, Testphasen, Anpassungen, Verteilung und Fehlerbearbeitung von Systemsoftware einheitlich, das heißt möglichst zentralisiert, regeln. Zum einen, um dem Gebot der Wirtschaftlichkeit zu folgen. Zum anderen, um auch im Softwarebereich eine möglichst weitreichende Normierung zu erreichen. Für das lokale RZ verbleibt das Feintuning von Systemumgebung und kundenspezifischen Anwendungen.
Ein solches Vorgehen empfiehlt sich insbesondere für international operierende Unternehmen oder für DV-Dienstleister mit multinationalen Kunden, die in mehreren RZ gleiche Anwendungen fahren.
Im Idealfall ist im Unternehmen eine Abteilung ausschließlich für Softwaremanagement zuständig. Dieses zentrale Team führt permanente Marktanalysen durch und definiert, welchem Anforderungsprofil eventuelle neue Systeme entsprechen müssen. Wichtiger Grundsatz: Software wird dann eingekauft, wenn der Mehraufwand für einen Wechsel durch Mehrleistung der Applikation gerechtfertigt erscheint oder aber Gefahr besteht, den technologischen Anschluß zu verlieren.
Wie sieht es mit der Entwicklung eigener Programme aus? Hier ist Zurückhaltung angesagt. Selbst für Unternehmen mit 20 Großrechenzentren hat es sich im Regelfall als unwirtschaftlich erwiesen, Systemsoftware selbst zu erstellen.
Oberstes Auswahlkriterium für neue Pakete ist deren Funktionalität. Wie paßt ein Produkt in das bestehende Umfeld und in die eigenen langfristigen Pläne? Die Gleichung, daß die funktionellste Software auch am ehesten den Anforderungen entspricht, geht nicht unbedingt auf. Durchaus möglich: Das zweit- oder gar drittplazierte System fügt sich am trefflichsten in die vorhandenen Gegebenheiten ein. In einem solchen Fall fällt die Wahl dann auch auf das objektiv betrachtet "schlechtere" Paket.
Ebenfalls bewertet wird die Bereitschaft des Herstellers künftig seine Systeme nach den Erfordernissen des potentiellen Käufers auszurichten und/oder unternehmensspezifische Modifikationen sowie Erweiterungen vorzunehmen.
Auch das Standing des Softwareherstellers spielt eine Rolle. Wie sehen seine Überlebenschancen in den nächsten fünf oder zehn Jahren aus? Schließlich stellt Systemsoftware für Großrechnereinsätze eine langfristige Investition dar.
"Eingefrorene Software" als Basis des Alphatests
Mit der Auswahl der Software sind die Aufgaben der Zentralstelle noch lange nicht abgeschlossen. An einen ersten Funktionstest des Systems schließt sich eine weitere Prüfphase innerhalb der Betriebssystemumgebung an. Nun fällt die Entscheidung: Ist das Produkt geeignet oder nicht?
Auf die Definition von Schnittstellen und Standards, eventuelle Änderungen oder Zusatzpakete, auf Analyse des Schulungsbedarfes und exakte Dokumentation folgen die letzten Testphasen:
Der Alphatest geht von einer "eingefrorenen" Software aus. Es erfolgen keine Änderungen mehr. Das gesamte System wird noch einmal vollständig überprüft. Diese Phase sieht auch Probeläufe mit ausgesuchten Anwendungsprogrammen vor.
Zum Betatest installiert ein einzelnes RZ das neue Paket und prüft die Zusammenarbeit von Software und Betriebssystem. Anschließend erfolgt der Einsatz im produktiven Betrieb: Das RZ betreibt für zwei Wochen sämtliche Anwendungen unter der neuen Software.
Nur wenn der Betatest einwandfrei verläuft, erhält das System ein Zertifikat. Sinnvoll: In regelmäßigen Zyklen verteilt die Zentralstelle komplette Sortimente mit ausgewählter Software inklusive ausführlicher Dokumentationen und Installationsbeschreibungen an den Standort.
Eine "Kontinentale Zwischenstufe" nötig
In einem weltweiten Netz, dessen Zentrale sich beispielsweise in den USA befindet, bietet sich vor der Verteilung an einzelne RZ ein Umweg über eine "kontinentale Zwischenstufe" an. Beispielsweise ein europäisches Test-Center. Ziel ist es eine noch weitergehende Standardisierung zu erreichen. Ein Europa-Gremium legt den erforderlichen EG-Standard fest. So kann das weltweite Konzept elegant auf ausschließlich kontinentale Belange gleichermaßen effizient angewandt werden.
Das Verfahren läßt sich ausbauen. Beispielsweise kann jedem europäischen RZ ein bestimmter Schwerpunkt zugeordnet werden. Softwareprodukte aus diesem Bereich werden dann von diesem Center of Competence aus europaweit betreut und an die einzelnen RZ verteilt.
Trotz doppelter Standardisierung verbleiben natürlich Aufgaben für das jeweilige lokale RZ. Neben kundenspezifischen Anforderungen sind auch national unterschiedliche Normen zu berücksichtigen. Fallen sehr komplexe Softwareänderungen an, empfiehlt es sich, vor dem Einsatz den Ernstfall zu simulieren.
Was passiert, wenn Fehler auftauchen? Es ist sinnvoll, mit der Analyse und Behebung von Fehlern an zentral bereitgestellter Software wiederum eine zentrale Hilfsstelle zu betrauen. Diese wird das Problem reproduzieren und dann versuchen, die Software zu korrigieren. Nach einer Prüfung durch das fehlermeldende RZ wird die verbesserte Systemversion präventiv an alle Netzteilnehmer verteilt.
Unterschiedliche Kunden und Anwendungen erfordern jedoch zum Teil sehr spezifische Software oder generieren spontanen Handlungsbedarf, der keinen Zeitaufschub bis zum nächsten Verteilungszyklus duldet. Folge: Das betroffene RZ kauft eigene Systeme, installiert und testet diese. Nach erfolgreicher Inbetriebnahme erfolgt die Rückmeldung über das kontinentale Test-Center an die Zentrale. Damit schließt sich der Kreislauf des zentralen Softwaremanagements für vernetzte Rechenzentren.
Insgesamt stellt diese Vorgehensweise sinnvolle Zukunftsstrategie für Betreiber und Nutzer dar. Denn Wirtschaftlichkeit, Verfügbarkeit, Standardisierung, Optimierung von Ressourcen, reibungsloser Back-up und lückenloses Disaster-Recovery trennen die Spreu vom Weizen. Oder was in diesem Fall als Vergleich näherliegt, den Elefanten vom Mammut. Die Überlebenschancen des letzteren hat die Geschichte hinlänglich bewiesen.