Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

19.10.1977

Rekonfigurierbarkeit

Die vorliegende Folge befaßt sieh mit der "Rekonfigurierbarkeit", worunter die Herstellung einer lauffähigen Anlage zu verstehen ist, wenn ein Hardware- oder Softwaremodul ausfällt oder neu hinzukommt.

Rekonfigurierbarkeit der Hardware

- Verarbeitungsprozessoren, E/A-Prozessoren, Speichermoduln von Haupt-, Sekundär-, Tertiär- und Massenspeicher und so weiter müssen während des laufenden Rechenzentrumsbetriebes entlastet beziehungsweise von Information geräumt werden können, abgeschaltet werden können und (etwa nach Reparatur) wieder zugeschaltet werden können, wobei keine Betriebsunterbrechung des Rechenzentrumsbetriebes nötig werden darf. Das Betriebssystem hat die dazu nötigen Fähigkeiten der Hardware in geeigneter Weise zu unterstützen.

- Bei Ausfall eines Verarbeitungsprozessors sollen die anderen dessen Funktion mitübernehmen können. Bei Ausfall eines Speichers (etwa Trommel) soll ein anderer (etwa Platte) dessen Funktion übernehmen gegebenenfalls mit langsamerem Zugriff. Alle peripheren Geräte und Satellitenrechner sollen Verbindungen zu mindestens zwei E/A-Prozessoren haben (Mehrfachanschluß, so daß die Geräte bei Ausfall eines E/A-Prozessors weiterhin voll betreibbar sind.

- Es soll ein permanenter Funktionstest aller Einheiten stattfinden und bei Ausfall automatisch auf Weiterbetrieb ohne das Modul umgestellt werden (automatische dynamische Rekonfiguration). Solange bei jeder lebenswichtigen Modulart wenigstens noch eines funktionsfähig ist und ein nötiges Minimum an Speicher auf allen Hierarchiestufen verfügbar ist muß Rechenbetrieb, wenn auch mit verminderter Leistung möglich sein.

- Hardwarewartung und gegebenenfalls nötige "Generalüberholungen" von Anlagen (etwa alle vier Jahre) sollen so erfolgen, daß - unter Inanspruchnahme der dynamischen Rekonfigurierbarkeit - Prozessoren, Speichereinheiten, periphere Geräte und so weiter im laufenden Betrieb aus der Anlage genommen werden und durch ein bereitstehendes oder in kürzester Zeit vom Computerhersteller anzulieferndes Austauschmodul ersetzt werden. Es geht nicht an daß zum Beispiel bei Ausfall eines von N Speichermoduln tagelang mit N-1 Moduln Betrieb gemacht werden muß, weil die Wartungsmannschaft "vor Ort" repariert (und dabei womöglich noch diverse Male stundenweise die gesamte Anlage blockiert um auszuprobieren, ob die Reparatur des Moduls erfolgreich war, oder gar um erst die Fehler zu orten - was heute leider noch häufig der Fall ist.

Modularität der Rekonfigurierbarkeit der Software

- Eine elementare Forderung für die gesamte Systemsoftware ist: Modularität plus Selbstdokumentation plus leichte Durchschaubarkeit der Funktion für das Rechenzentrum. Dies beinhaltet indirekt, daß die gesamte Software komplett in geeigneten höheren Sprachen zu schreiben ist. Dabei soll das Betriebssystem (BS) in einer "PS-Implementierungssprache" und das Programmiersystem (PS) in einer "PS-Implementierungssprache" geschrieben sein. Beide Teile sollen durch eine saubere Schnittstelle getrennt sein, so daß etwa das PS (und alle Compiler, Datenbanksystem) bei behalten werden können, wenn Hardware und/oder BS erneuert werden (Nachfolgesystem). Genauso konnte ein verbessertes BS nachgeschoben werden, und PS + Hardware bleiben erhalten. Anzustreben ist hier eine Hardware, die herkömmlichen Assembler nicht kennt (sprachorientierter Rechner).

- BS und PS sollen dynamisch rekonfigurierbar sein. Das heißt daß Softwaremodule im laufenden Betrieb aus dem Codesharing genommen, blockiert und gelöscht werden, die neuen Module eingefahren und freigegeben werden. Dies soll für alle Module gehen, ausgenommen es ist logisch unmöglich (Beispiel: gewisse Teile des BS-Nucleus). Anwendung: Tausch von Compilern, Datenbanksystem, Jobcontrollanguage, Benutzerverwaltung.

- Ersetzen, Sichern, Reorganisation der "Konstantenbereiche" von BS und PS (etwa Programmbibliothek, Benutzerlisten, Accountingdaten) muß ohne Rechenbetriebsunterbrechung bei voller Datensicherheit möglich sein.

- Ersetzen von Teilen oder des gesamten Bestandes permanenter und temporärer Dateien und der Datenbankinhalte (etwa im Fall zerstörter Dateien oder von Datensätzen), Auslagern von Teilen, falls eine Platte ausfällt oder aus dem Betrieb genommen werden soll, Sicherungsarbeiten, Platzbereinigungen (Reorganisation) und verwandte Arbeiten müssen im laufenden Betrieb geschehen können, wobei Schutz und Sicherheit der Daten voll gewährleistet sind.

Abschlußbemerkung zur Aufsatzserie

Mit diesen Forderungen zur dynamischen Konfigurierbarkeit von Hardware und Software schließt die CW Nr. 30 begonnene Forderungsserie ab. Es sei noch mal daran erinnert, daß hiermit nicht etwa ein vollständiges Pflichtenheft zur Konstruktion der nächsten Rechnergeneration vorgelegt werden sollte. Die Aufsatzserie stellt vielmehr eine stichpunktartige Liste von Forderungen dar, die man heute als Kunde verlangen kann und soll, weil diese Dinge nach dem Stand der Kunst machbar sind, ohne daß dies mit utopischen Kosten verbunden ist. Für die meisten Forderungen läßt sieh sogar ein Beispiel j angeben, wo die Realisierung schon vorliegt. Was aber für das Rechenzentrum nötig ist ,ist im Gegensatz dazu die Realisierung möglichst viele der oben genannten Forderungen in einem: System, um die Effizienz, Betriebssicherheit und Benutzerfreundlichkeit von Rechenzentren zu verbessern.