Die Entwicklung des Softwaredistributionsservers
Werner Steinmann
In diesem Beitrag soll wieder einmal auf die Stellung des Software Distribution Servers swd.tuwien.ac.at bei der Verteilung von Software an der TU eingegangen werden. Über diesen Server wird diejenige lizenzierte Software verteilt, die nicht über andere, speziell eingerichtete Server im Rahmen der Institutsunterstützung angeboten wird. Es wird versucht, einen Überblick zur Entwicklung des Servers, zum aktuellen Stand und zu den geplanten Erweiterungen zu geben. Eine detailliertere Darstellung verschiedener Aspekte ist u.a. in älteren Ausgaben der PIPELINE aus der damals gültigen Sicht festgehalten, und aktuelle Ankündigungen etc. sind in relevanten Newsgroups at.tuwien.*, Aussendungen o.ä. zu finden.
Exemplarisch seien verschiedene Bereiche aufgezählt:
* Aufteilung auf verschiedene Server
* Entwicklung des Plattenplatzes
* Versionen der Verteilungssoftware
* Betriebssystem Upgrades
* Entwicklung des Backups
* Personalkapazitäten
* Varianten des Zugriffes
* Frühwarnsystem
Im Oktober 1992 wurde von Günter Houdek in der PIPELINE 8 unter „Neuer Software Server“ die noch im Einsatz befindliche Vorgängermaschine der swd.tuwien. ac.at von heute vorgestellt: Eine SPARCstation 4/330, auf der damals das Angebot an Software für die TU konzentriert war. Die Akkumulation von Services auf dieser Anlage führte aber bald zu immer unbefriedigenderem Betriebsverhalten, zu Security-Problemen usw.
Im Juni 1995, als Georg Gollmann „Neue Server der Abt. Institutsunterstützung“ in der PIPELINE 16 ankündigte, waren zwischenzeitlich schon Notlösungen zur Verteilung der Campus-Software im Entstehen begriffen, z. B. das Ausweichen mit ms.tuwien.ac.at auf einen von Paul Torzicky betreuten Plattform-Server. Ende 1995 konnte dann noch eine Reserve- bzw. Testmaschine für die neu installierte swd.tuwien.ac.atbeschafft werden. Diese hat schon viele gute Dienste geleistet. Zum einen kann im laufenden Betrieb an der swd.tuwien.ac.at sehr wenig adaptiert werden (neue Software-Versionen testen oder erstellen, Vorbereiten von Hardware- Komponenten wie Disks (burn in) oder interfaces, ...), zum anderen schien das Halten von Ersatzteilen günstiger als vergleichbare Wartungsverträge mit vernünftigen Antwortzeiten – zumindest nach den vorliegenden Angeboten. Damit konnte auch z.B. die Übersiedlung von der Gußhausstraße ins Freihaus vor einem Jahr oder die Inbetriebnahme eines StorageWorks RAID Array 410 ohne wesentliche Standzeiten bewerkstelligt werden.
Der Plattenplatz für die Software-Distribution an der TU Wien hat sich von aus heutiger Sicht bescheidenen Anfängen (weniger als 1 GB) über mehrere Stufen zum momentanen Stand von über 100 GB entwickelt, wobei am Anfang auch noch die Verteilung mit Datenträgern eine gewisse Bedeutung hatte. Ein markanter Wendepunkt war die Lieferung von 2 SPARCstation 20 (je 2x50 MHz SuperSPARC CPUs, 64 MB RAM, 1GB System Disk, je 2 SCSI und je 2 Ethernet Interfaces) im April 1995, um für Software-Distribution und anonymous ftp eigene Server zur Verfügung zu haben.
Davor waren diese Bereiche noch viel stärker als heute mit den anderen Services der Institutsunterstützung vermischt. Bis zum Ende des Jahres 1995 waren die ursprünglich als ausreichend erachteten 8 GB für die zu verteilende Software schon wieder zu verdoppeln, um mit den Anforderungen Schritt zu halten. Beim Plattenplatz ist auch zu berücksichtigen, daß während von den Lizenznehmern auf Produkte zugegriffen wird, oft von mehreren Mitarbeitern neue Pakete aufbereitet und getestet werden. Als der Bedarf nach Plattenplatz sukzessive weiterwuchs, wurde noch für 1996 ein RAID Subsystem geplant und am 2. Dezember 1996 nach einer ausführlichen Testphase in Betrieb genommen. Allein die Verkabelung von vielen Geräten an den SCSI Bussen war davor schon zu einer äußerst unangenehmen Fehlerquelle geworden. Die 24 Slots, die nach damaligem Stand mit 1, 2 oder 4 GB Disks bestückt werden konnten, sollten wieder für eine Weile reichen (d. h. im Vollausbau für ca. 80 GB, nach Abzug von parity und spare Disks für die Betriebsart RAID Level 3/5). RAID Level 3/5 bedeutet bei den verwendeten StorageWorks RAID Arrays, daß durch geeignete Parameterwahl der Hardware Level 5 in Richtung des Verhaltens von Level 3 getrimmt werden kann.
Gerade noch rechtzeitig bevor sich trotzdem wieder Engpässe abzeichneten, konnte durch einen Firmware Upgrade des RAID Controllers die Verwendung der auch gerade verfügbar werdenden passenden 8 GB Disks realisiert werden. Die Voraussetzungen an passende Platten schränken die Auswahl merklich ein. Der derzeit letzte Stand ist die Anschaffung eines weiteren RAIDs, eines DEC StorageWorks RAID 450, das noch dieses Jahr in Betrieb gehen soll. Es handelt sich um ein Nachfolgemodell zum bereits im Einsatz befindlichen RAID Array 410 mit ähnlichen Spezifikationen. Es kann z. B. von 32 auf 128 MB Cache aufgerüstet werden. Und damit ist unser wiederkehrendes Problem des single point of failure – solange nicht beide RAID Systeme voll ausgelastet sind – wieder ein bißchen geringer.
Parallel mit dem Plattenplatz hat sich auch die Software für den Zugriff auf die Produkte der Distribution entwickelt: Die Anfänge gehen auf Scripts und Adaptierungen zum ftp daemon der Washington University (wu-ftpd) durch Martin Gräff zurück; d. h. auch, daß neben der Verteilung durch Datenträger nur das ftp Protokoll zur Verteilung genutzt wurde.
Die große Umstellung begann auch hier mit der Installation des dedizierten Software Distribution Servers im Jahre 1995. Udo Linauer und Gerhard Kircher entwickelten auf der Basis von Hard Links und ODS (Solstice online disk suite) das System SDS2, das neben ftp auch die Unterstützung von verteilten Filesystemen bieten sollte; konkret wurde an Samba zur sogenannten Direktinstallation gedacht. Die Schnittstelle zur Lizenz-Datenbank unter GemStone wurde von Georg Gollmann zur Verfügung gestellt und für die ersten Inkarnationen des Informationssystems zu den Produkten war ich verantwortlich. Aber es dauerte kein Jahr bevor die Grenzen dieses Ansatzes deutlich wurden, d. h. SDS2 skalierte schlecht mit den wachsenden Datenmengen und die dringenden Verbesserungen mündeten in SDS3, basierend auf dem Loopback File System (lofs) unter Solaris. Vorausgegangene kleinere Änderungen und Umstellungen von Shell Scripts auf Perl brachten nicht den gewünschten Erfolg; sogar Systemprogramme wie fsck verlangten nach viel virtual memory und ließen sich durch bloße Zugabe von swap space aber nur mit mäßiger Performance ausführen. Auch das Cache im RAID System brachte bei den alten Update-Scripts keine ausreichende Verbesserung. Eine Erweiterung zu SDS3 bedeutete die Installation über WWW, zu der Walter Selos eine 16-bit Helper Applikation (in Forth) für Web-Browser beisteuerte. An der Weiterentwicklung der derzeit angebotenen Möglichkeiten wird bereits wieder gearbeitet.
Die Funktionen des oben erwähnten ODS werden auf Metadevices angewandt, die zum Teil analog zu den Virtual Devices der jetzt verwendeten RAIDs (mirrorsets, stripesets usw.) sind. Metadata heißen die Konfigurations- daten in beiden Fällen und werden in reservierten Spuren auf den Disks abgelegt. Die RAID Level sind in unserem Fall spürbar effizienter in Hardware gelöst, ganz abgesehen von den zusätzlichen Hardware-Funktionen, die die StorageWorks Systeme bieten, z. B. hot swap von Komponenten. Auf die optionale Failover-Funktion von einem defekten auf den überlebenden redundanten Controller wurde aus Kostengründen verzichtet; auf das optionale Failover von einem ausgefallenen Host auf eine stand by Maschine natürlich ebenfalls. Aber auch ODS als betriebssystemnahes Software-System hat Möglichkeiten, wie das Erweitern (growfs) von Filesystemen im Betrieb oder UFS File System Logging zum problemloseren Aufsetzen nach einem Crash, auf die wir gerne zurückgreifen.
Die SPARCstation 4/330 wurde noch unter SunOS betrieben, ein BSD nahes UNIX System, das später in Solaris 1.x umbenannt wurde. Als das neue Software Distribution Service auf der SPARCstation 20 installiert wurde, ist auch gleichzeitig der Übergang zu Solaris 2.4 vollzogen worden. Bis Version 2.3 hatten wir nicht den Eindruck, daß Solaris 2.x, dieses an System V angelehnte System, unseren Anforderungen an die Stabilität bei einem Server entgegenkam. Aber nachdem sich SunSoft immer mehr auf Solaris 2.x konzentrierte und neuere Entwicklungen darauf beschränkt werden, blieb uns längerfristig keine Wahl, falls wir nicht überhaupt auf ein ganz anderes System wechseln wollten.
Mit dem RAID Array 410 standen wir vor der Entscheidung, ob wir es gleich mit dem damals neuen Solaris 2.5.1 (inklusive wichtiger patches) wagen sollten. Probleme am News-Server mit ähnlicher Konfiguration machten uns eher skeptisch. Die doch ziemlich lang dauernden Tests waren schließlich erfolgreich. Weniger erfolgreich waren hingegen bisher unsere Versuche zum Performance Tuning (siehe Adrian Cockcroft: Sun Performance and Tuning).
Als Backup wurden am Anfang QIC und DAT (DDS1) eingesetzt (auf der ehemaligen swd- und ftp- und tex- usw. -Maschine vor 1995); oder es wurden einfach Distributionsmedien kopiert und archiviert. Mit der Installation von swd.tuwien.ac.at erfolgte der Umstieg auf DAT hp-1533 (DDS2), doch konnte diese Erweiterung mit dem Ansteigen des Plattenplatzes nicht Schritt halten. Die Entwicklung bei den DLTs ging dann doch so rasch weiter, daß wir mit Beginn des Jahres 1997 ein DEC DLT TZ88 20/40 GB in Betrieb nehmen konnten. Das Backup der vorhandenen Datenmengen ist in dem Sinne zu verstehen, daß ein Aufsetzen nach größeren Problemen möglichst rasch erfolgen kann. Bezüglich „rasch“ kommt es aber im Ernstfall nicht nur auf die optimale Konfiguration dieser einen Device an – obwohl man da beachtliche Geschwindigkeitsunterschiede bei verschiedenen Blockgrößen etc. feststellen kann – sondern noch viel mehr auf ein ganzes Bündel begleitender organisatorischer Maßnahmen: wichtige Telephonnummern, verfügbare Ersatzteile usw. Die erhöhte Ausfallssicherheit durch Einsatz entsprechender RAID Level ist jedenfalls kein Ersatz für ein Backup auf Bänder. Ein Verwalten und Archivieren von (älteren) Software-Versionen ist jedoch bisher damit nicht gelöst. Und somit sei allen ans Herz gelegt, auch selber Backups vor allem der älteren noch verwendeten Software-Pakete anzulegen.
Vor der Inbetriebnahme von swd.tuwien.ac.at waren ein wesentlicher Teil der Software-Distribution und das anonymous ftp-Service auf dem Server für SUN Support beheimatet und wurden u.a. von Günter Houdek nebenher betreut. Seit der Aufteilung dieser Services kümmert sich Antonin Sprinzl um den anonymous ftp-Server, der SUN Support blieb bei Günter Houdek und swd habe ich übernommen. Mit Gerhard Kircher und Udo Linauer stehen zwei weitere Mitarbeiter zur Verfügung, die den Betrieb gerade dieses Servers in Urlaubszeiten oder bei Krankheitsfällen möglichst lückenlos abdecken, zusätzlich zu ihren sonstigen Aufgaben. Diese Qualität des Services im Zuge der sogenannten Sparmaßnahmen in absehbarer Zeit noch zu gewährleisten, wird immer schwieriger.
Zugriffsvarianten nach Rechnern: Juli 95 bis Juni 97
Zugriffsvarianten nach Benutzern: Juli 95 bis Juni 97
Der Zugriff auf die zu verteilende Software war ursprünglich auf ftp und die Verteilung von Medien beschränkt. Für die verschiedenen Betriebssysteme wurden aber auch nach und nach entsprechende Verteilungsmechanismen aufgebaut bzw. ausgebaut, wo es sinnvoll und nötig erschien. So kann man z. B. auf den Novell Server S11NOVELL unter IPX, auf den OpenVMS Server EVAXSW:: über DECnet oder auf den Apple Archiv Server macos.tuwien.ac.at über Apple Protokolle zugreifen; meist zusätzlich zu den TCP/IP Protokollen, weil eben gewisse Funktionen oft in spezifischen Prozeduren der jeweiligen Hersteller vorgesehen und gelöst sind. Beispiele sind License Manager, Remote Installa- tion oder Dokumentation.
1995 kam auf dem neu installierten swd.tuwien.ac.at Samba für die Direktinstallation zusätzlich zur Verteilung über ftp dazu. Im nächsten Jahr konnte dann online über WWW bestellt werden und heuer ist auch die Installation der Software über WWW verfügbar geworden. Es war auch immer der Zugriff über (PC)NFS möglich bzw. es werden immer noch Medien verliehen und kopiert, doch sind diese Verteilungsmechanismen nur bei Versagen der anderen Varianten im Einsatz.
Apropos Versagen: Leider gibt es natürlich immer wieder Fälle, die in den angebotenen Zugriffsmöglichkeiten nicht vorgesehen sind: Probleme mit der Kodierung der (langen) Dateinamen, Änderungen in der Verschlüsselung der Passwords (z. B. nach Windows NT Service Pack 3) oder generell das Anwachsen der Datenmengen, so daß sie von Instituten mit nicht ausreichender Netzwerkanbindung nicht mehr vernünftig bewältigt werden können, usw. Soweit diese Probleme von uns behoben werden können, versuchen wir immer, rasch darauf zu reagieren. Relativ häufig ist der Fall, daß der Zugriff mit (neuen) Geräten versucht wird, die keine DNS Eintragung besitzen, d. h. an der TU noch nicht bei hostmaster@ noc.tuwien.ac.at angemeldet wurden. Da aber auf swd.tuwien.ac.at nach Domain Namen und nicht nach IP Adressen gefiltert wird, werden diese Versuche abgewiesen. Bei nicht rechtzeitigem Eintreffen von Lieferungen oder defekten Medien kann es hingegen natürlich (oft genug) passieren, daß ein Produkt schon im Handel ist, wir aber einfach wirklich noch nichts zu verteilen haben.
Sobald die Benutzer Probleme beim Zugriff auf swd.tuwien.ac.at haben, ist bereits Feuer am Dach. Darum wurden im Laufe der Zeit vorbeugende Maßnahmen immer weiter verfeinert und ausgebaut, die potentielle Schwachstellen frühzeitig aufdecken sollen. Die einfachste Methode ist natürlich die intensive Benutzung der Maschine durch die Mitarbeiter des Bereiches Institutsunterstützung selbst, z. B. beim Aufspielen der Software und durch Testinstallationen der Produkte. Dann gibt es periodische Updates mit ftp.tuwien.ac.at und der Lizenzdatenbank unter GemStone; damit ist ein rudimentärer Test der Connectivity gewährleistet. Bei der Netzanbindung ist aber der Software Distribution Server nur ein Glied in der sprichwörtlich schwachen Kette. Zur Temperaturüberwachung verwenden wir ein System, das von Walter Selos entwickelt wurde; aber auf Ausfälle der gesamten Klimaanlage, wie zu Weihnachten 1996, sind wir (noch) nicht vorbereitet. Für die diversen (Zugriffs-)Protokolle gibt es jeweils Log-Files, die mit Prozeduren von Udo Linauer ausgewertet werden. Der Plattenplatz wird mit einem Cron Job überwacht. Die Verteilungssoftware enthält einige Sanity Checks, die z. B. Bedienungsfehler wie falsche Eingaben oder Inkonsistenzen im File System eruieren helfen. Neben dem Sichten von Log-Files wie syslog sind zum Teil auch automatisierte Alarme über Mail oder SNMP vorgesehen, z. B. als Option bei der verwendeten USV oder den RAIDs. Als ein vom TUNET unabhängiger Informationskanal wird die gezielte Verwendung von Pagern überlegt und würde z. B. von den verwendeten RAID Systemen bereits unterstützt.
Die Lebensdauer und sinnvolle Ausbaufähigkeit der momentanen Konfiguration ist absehbar. Die in der PIPELINE 21 – erst vor einem halben Jahr! – skizzierten Ausbauvarianten sind nämlich zum größten Teil bereits Wirklichkeit: Der Umstieg von 4 auf 8 GB Disks bei Erweiterungen und die Beschaffung eines weiteren RAIDs sind im Gange; neu vorgesehen ist jetzt auch noch der Einsatz von ATM, da der Netzanschluß in nächster Zeit schon ein Engpaß werden könnte.
Darum werden ernsthafte Anstrengungen notwendig sein, eine neue Anlage zu beschaffen und zu konfigurieren, um eine nahtlose Weiterführung der Software-Verteilung zu sichern. Dabei wird natürlich versucht, die bisher bewährten Methoden beizubehalten und gegebenenfalls zu adaptieren und nicht alles von Grund auf neu zu entwickeln. Auf die sich ständig ändernden Verteilungsmechanismen der Firmen ist aber ebenso Rücksicht zu nehmen wie auf die mögliche Verwendung von Medien wie DVD und MO oder CD-ROM Wechslern usw. Es hat sich auch immer wieder gezeigt, daß viele Eigenschaften, die typischerweise dedizierten Server-Maschinen zugeschrieben werden, auch bei der jetzigen Anlage wünschenswert wären bzw. im Laufe der Zeit ohnehin – soweit eben möglich – irgendwie integriert werden mußten, um die Ausfallsicherheit zu erhöhen oder die Wartbarkeit zu verbessern.
Viele Beiträge wurden nach und nach überarbeitet und für Anleitungen zum Bezug von Campussoftware verwendet, andere zeigen wie oft sogar für die Eingeweihten sich die ursprünglichen Vorstellungen von Jahr zu Jahr stärker wandeln als erwartet. Oder allein die Anzahl der Autoren gibt z. B. ein Bild davon, daß es in diesem Bereich einer intensiven Zusammenarbeit bedarf.
PIPELINE 8, Oktober 1992
Günter Houdek, p. 11-12, Neuer Software-Server
Helmut Mayer, p. 12, Informationen über Dienste des Software-Distribution
Servers SWD
PIPELINE 9, Jänner 1993
Albert Blauensteiner, p. 6, Die Software-Server der Abt. Institutsunterstützung
Guenter Houdek, p. 7, Ausbau des Software-Servers
PIPELINE 12, Februar 1994
Günter Houdek, p. 37, Ausbau des Software-Servers und SunOS-Tuning
Georg Gollmann, p. 38, Serverstrategie der Abteilung Institutsunterstützung
Georg Gollmann, p. 38-39, GemStone an der Abteilung Institutsunterstützung
PIPELINE 15, Februar 1995
Antonin Sprinzl, p. 27-30, Informationsangebot
der Abteilung Institutsunterstützung: Spektrum, Bezugsmöglichkeiten
PIPELINE 16, Juni 1995
Albert Blauensteiner, p. 21, Campussoftware:
Veränderungen im Bezug
Georg Gollmann, p. 33, Neue
Server der Abt. Institutsunterstützung
PIPELINE 17, Oktober 1995
Udo Linauer, p. 5-7, Der
neue Campussoftware-Server
Milan Knezevic, p. 7-8, Direktinstallation
vom Campussoftware-Server
Tony Sprinzl, p. 17-18, Goodie
Domain Service der Abteilung Institutsunterstützung
PIPELINE 18, Februar 1996
Helmut Mayer, p. 13, Online
Bestellung von Campussoftware
PIPELINE 21, Februar 1997
Werner Steinmann, p. 11-13, Softwaredistributionsserver
SWD
Udo Linauer, p. 14-15, Statistiken
der Softwaredistribution (SDS2)
PIPELINE 22, Juni 1997
Albert Blauensteiner, p. 8, Direktinstallation
von Campussoftware über WWW