Die Moden ändern sich. Was heute "in" ist, ist morgen passé; was heute "out" ist, ist morgen der letzte Schrei.
EDV unterliegt genauso Modeströmungen wie jede andere menschliche Aktivität. Trendige Ideen kommen in Mode und fallen schon bald in Ungnade. Gute Ideen dagegen mögen zeitweise aus der Mode kommen, letztendlich aber sind sie zeitlos. So ist es wenig überraschend, dass das heutige EDV-Milieu zum Ausgangspunkt zurückgekehrt ist; große Hersteller und Analysten preisen die Vorzüge der Serverkonsolidierung im Bezug auf die Investitions-Gesamtkosten (Total Cost of Ownership, TCO). Ebendiese Hersteller und Analysten haben oft vor kurzem noch zentralisierte Systeme mit mehreren Aufgaben für "tot" erklärt, und stattdessen behauptet, dass die Zukunft in kleinen Systemen liegt, die befreit von der Last einer zentralen Kontrolle arbeiten. Es wurde argumentiert, dass eine Befreiung von einer zentralen Kontrolle Vorzüge habe.
Was damals und auch heute oft außer Acht gelassen wird, ist, dass die Verringerung der TCO und Verbesserung der Skalierbarkeit durch Serverkonsolidierung (und, was das betrifft, sogenanntes Utility Computing) dieselben System- und Betriebs-Disziplinen erfordert, die in der Eile zur Dezentralisierung der EDV so sehr verunglimpft wurden. Was nicht bedacht wurde, und oft verlorenging, war das Verständnis dafür, dass die Koexistenz auf einem einzigen System und Betriebssystem eine Menge Disziplin und Achtsamkeit erfordert, die auf kleinen Systemen gelegentlich außer Acht gelassen werden kann. Die begrenzte Umgebung eines Systems mit nur einer Funktion kann die Bedeutung von Abgrenzung verschleiern. Tatsächlich sind aber die Disziplin und Achtsamkeit bei der Erzwingung wohldefinierter Grenzen der Schlüssel zur Verwirklichung des heiligen Grals der Kosteneffizienz: Agilität.
OpenVMS hat sich seit seinen Anfängen darin hervorgetan, eine verläßliche und sichere Plattform für sehr verschiedene Umgebungen zu bieten, und unterstützte leicht eine Menge von anderweitig unabhängigen Funktionen auf einem einzigen integrierten System.
Heute reicht die Spanne der OpenVMS-Systeme von sehr kleinen VAX-basierten Systemen bis zu High-End-Alphas und den angekündigten Itanium-basierten Systemen. Es gibt heute viele Anwendungen, die etliche Hardware-Generationen mit minimalen Änderungen überwunden habe; die Umstellung von VAX auf Alpha mittels Image-Übersetzung, und auf ähnliche Weise wird eine Übersetzung des resultierenden Alpha-Images auf Itanium funktioneren. Wohlgemerkt: eine Neu-Kompilierung würde diesen Applikationen gut tun, aber die Übersetzungstechnologie ist hinreichend effizient, so dass der Arbeitseinsatz anderweitig besser aufgehoben ist.
Die Diskussion, an welche Stelle die Image-Übersetzung bei den möglichen Migrations-Strategien gehört, verdient einen eigenen Beitrag, den ich mir für einen zulünftigen Zeitpunkt aufhebe. Was wichtiger ist, und kritisch für den Durchschnitts-Systemmanager und -Benutzer, sind die Techniken, die Applikationen verwenden, um unter OpenVMS "gute Bürger" zu sein. Dieses gute Bürgertum ist der unbekannte Grund hinter großen Einsparungen beim TCO und Verbesserungen bei der Skalierbarkeit.
Erfolgreiche Anwendungen setzen die von OpenVMS bereitgestellten Benutzerumgebungen und Sicherheitsfeatures ein, um flexibel zu sein, aber dennoch sicher. Das zentrale Feature, das Skalierbarkeit und robusten Betrieb ermöglicht, ist, ist der Brickwall-Schutz [etwa gemauerte Trennwände, d.Ü.], die absolute Abschottung verschiedener Benutzerprozesse.
Insbesondere sichert der Brickwall-Schutz die Integrität der Schutzmechanismen, die den Zugriff auf Dateien und die Systemhardware kontrollieren. Eine breite Palette einzeln steuerbarer Privilegien bestimmt den Zugriff auf den globalen Systemzustand. Dadurch bietet ein richtig aufgesetztes System dem Benutzer eine Umgebung, die sicher ist vor Störungen durch andere, die das System nutzen.
Die Benutzerumgebung ist parametrisiert, d.h. sie wird für jeden Benutzer auf Basis der in der UAF (User Authorization File) enthaltenen Information angepasst. Diese Parametrisierung ermöglicht es, dass verschiedene Benutzer dramatisch verschiedene Umgebungen wahrnehmen, von denen jede auf Einstellungen in der UAF zurückgeht (oder, was das betrifft, die Mitgliedschaft in einer bestimmten UIC-Gruppe, oder jede andere Folge von in der UAF gespeicherten Daten).
Eine der ersten Regeln ist, dass es für erweiterte Privilegien in der OpenVMS-Welte nur wenige Gründe gibt. Die überwältigende Mehrheit von OpenVMS-Anwendungen braucht nur in seltenen Fällen erweiterte Privilegien; Zugriffsrechte auf bestimmte Dateien sind in den meisten Fällen mehr als adäquat. In der Realität habe ich in über 25 Jahren nur sehr wenige Situationen gesehen, in denen Privilegien jenseits von NETMBX und TMPMBX für eine Applikation wirklich nötig waren. Die Steigerung der Systemverfügbarkeit und sinkende Anzahl von notwenigen Reboots stehen in direkter Abhängigkeit mit der Limitierung von privilegiertem Zugriff auf Teile des Systems. Mit einer relativ kleinen Investition in die Planung und Sicherheit ist es durchaus möglich, große OpenVMS-Systeme zu verwalten. Diese Systeme unterstützen Scharen von hunderten oder tausenden von Benutzern, mit einer Fülle von Funktionen, die alle ihre eigenen Startup- und Shutdown-Funktionen haben, alle in den Sicherheitsdomänen eines einzigen Systems. Dies alles kann ohne eine aufwendige Mannschaft von Systemprogrammierern erreicht werden. Im Gegensatz zu anderen Systemen bringt OpenVMS alle Bausteine mit, die nötig sind, solche eine Umgebung sicher aufzusetzen.
Frühere Kolumnen haben die Verwendung von logischen Namen behandelt, das Thema von kommenden Kolumnen werden die grundlegenden (Gruppen/User) und die erweiterten Sicherheits-Fähigkeiten (Rightslist-Identifier und ACLs) sein, mit denen man eine Umgebung einrichten kann.
Die allgegenwärtige Verwendung von SYS$SYSTEM, SYS$STARTUP, SYS$LOGIN, SYS$SCRATCH und anderen logischen Namen bieten einen ähnlich starken Hebel. OpenVMS ist ein gutes Beispiel, warum Einfachheit und Klarheit wirklich der Schlüssel zur Verringerung der TCO sind.
Zusammengefasst sind die traditionell empfohlenen Vorgehensweisen zum Aufsetzen und Verwalten eines OpenVMS-Systems dieselben, die bei der Serverkonsolidierung die Basis der TCO-Vorteile bilden.
Vorhergehende Artikel in dieser Reihe von Robert Gezelter:
Fallstricke von F$LOCATE und anderen Funktionen
Logische Namen (Teil 5)
Logische Namen (Teil 4)
Logische Namen (Teil 3)
Logische Namen (Teil 2)
Logische Namen (Teil 1)
Über den Autor:
Robert Gezelter, CDP, Software Consultant, Gastredner und Schulungsleiter hat mehr als 25 Jahre internationaler Consulting-Erfahrung im privaten und öffentlichen Sektor.
Mr. Gezelter ist ein st regelmäßiger Gastredner auf technischen Konferenzen weltweit, z.B. HPETS (früher DECUS). Seine Publikationen umfassen Artikel in Network World, Open Systems Today, Digital Systems Journal, Digital News und Hardcopy. Auch hat er am Computer Security Handbook, 4. Auflage (Wiley, 2002) mitgearbeitet.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1978 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Mr. Gezelter ist per Email zu errreichen unter gezelter@rlgsc.com.
Original auf www.openvms.org
|
![[OpenVMS Swoosh]](/images/OpenVMS_VSI_72x88.png)
de.OpenVMS.org![[Future Forward]](/images/swoosh160w.jpg)