Udo Linauer
Nach dreijährigem Einsatz stand in diesem Sommer der Austausch des Software Distribution Servers swd. tuwien.ac.at (SUN SPARCstation 20) an. Die Leistungsfähigkeit der alten Maschine konnte den Bedarf nicht mehr decken, weiterer Ausbau war nicht mehr möglich, schließlich und endlich machten sich bereits Verschleißerscheinungen bemerkbar. Dabei wurde erstmals in diesem Bereich eine Clusterlösung angestrebt. Das Ziel der erhöhten Verfügbarkeit konnte nicht allein durch mehrere Servermaschinen erreicht werden, auch in Peripherie und Software musste investiert werden. Der folgende Artikel soll Ihnen eine kleine Chronik der Konzeption und Implementierung des neuen Software Distribution Servers bis hin zur Inbetriebnahme am 20. Juli bieten.
Für den Einsatz von PCs, insbesondere unter Linux, FreeBSD oder ähnlichen Betriebsystemen, spricht das glänzende Argument der Verfügbarkeit der Sourcen. Die Möglichkeit, selbst Hand anzulegen, wo man bis jetzt nur am Unwillen oder Unverständnis der Firmen anstand, war natürlich verlockend. Schwerwiegende Gründe sprachen aber auch gegen eine PC-Lösung. Gängige PCs sind einfach zu klein (Anzahl der Steckplätze etc.) und in keiner Weise auf Hochverfügbarkeit ausgelegt. Dedizierte Server mit Intel-Prozessoren sind alles andere als billig und vor allem ist es gar nicht so einfach, eine geeignete stabile Linux-Lösung aufzubauen, unter Umständen misslingt dies sogar gänzlich. Zeitrahmen und Risiken schienen uns schlecht einschätzbar, sodass wir von diesem Ansatz wieder Abstand nahmen.
Der Übergang auf ein radikal anderes (größeres) System scheint mit so hohem Aufwand (und entsprechenden Kosten) verbunden, dass er nur bei einer grundlegenden Änderung der Anforderungen notwendig und gerechtfertigt erscheint. Zumindest als Pilotprojekt für eine neue Generation von Dienstleistungen des EDV-Zentrums wäre es einer ernsthaften Überlegung wert: Zuverlässigkeit bei der EDV-Infrastruktur, wie man sie von anderer Infrastruktur wie Telefonie oder Strom- und Wasserversorgung gewohnt ist.
Paradebeispiele für ausfallssichere Systeme werden z.B. seit Jahren von Tandem gebaut (sogar in Österreich vertreten: http://www.tandem.at/). Die verschiedenen Modellserien inklusive Zusatzprodukte decken ein weites Spektrum ab: Für Networking und Communications bieten sie ähnliche Standards wie Motorola, und im Bankenbereich sind sie – wenn man der Werbung trauen darf – fast ohne Konkurrenz. Die Unix-Maschinen verwenden MIPS Prozessoren unter NonStop-UX; als Zusatzprodukte gibt es vieles, was auch unseren Wünschen entgegenkäme: HSM, „storage subsystems“, Cluster, „Filesystem“ und „Volume Manager“ von Veritas.
Heute werden bereits von fast jedem (Workstation-) Hersteller auch Server-Ausführungen ihrer Modelle angeboten. Ein Beispiel ist die Enterprise Serie von SUN mit SPARC Prozessoren. Aber im Gegensatz zu der FX Serie von Motorola, bei der Ausfallssicherheit der Ausgangspunkt der Entwicklung ist, hat man hier mehr den Eindruck von zusätzlichen Features für Standardworkstations. Offensichtlich ist jedoch der Bedarf – wie bei uns – dafür in ausreichendem Maße vorhanden. Wenn wir den Aufwand für unsere Anlage Revue passieren lassen, scheint auch das Kosten-/Nutzenverhältnis für eine ausfallssichere Server-Lösung akzeptabel.
Die Ausfallssicherheit der verwendeten Maschinen (SPARCstations 20) als Ganzes wurde durch den Kauf von 3 Geräten erreicht, von denen nach ursprünglichem Plan swd.tuwien.ac.at höchste Priorität hatte, ftp.tuwien. ac.at auf der nächsten Stufe stand und die dritte Maschine als Test- und wirklicher Reserverechner im Einsatz war. Es war keine automatische „failover“ Funktion zwischen den Maschinen vorgesehen, sondern sie mussten sogar je nach Bedarf – auch physisch – umkonfiguriert werden.
Der Ausfall von Komponenten – in ca. 3 Jahren sind z.B. 3 CPUs der Doppelprozessormaschinen defekt geworden – führte üblicherweise zum Crash der jeweiligen Maschinen; es ist offensichtlich kein „fail safe“ oder „graceful degradation“ durch automatisches Wegschalten defekter Komponenten vorgesehen. Außerdem kann durch den Ausfall eines Teiles die restliche Maschine in Mitleidenschaft gezogen werden – die einzelnen Module sind nicht ausreichend gegeneinander isoliert.
Bei Problemen mit einer Netzwerkverbindung war kein Umschalten auf eine andere Netzwerkkarte (ein anderes Netz) vorgesehen – bei gleichzeitigem Wegschalten der eventuell störenden Karte. Transceiver Probleme hatten ursprünglich mehrere Geräte am gleichen Strang gestört und nicht nur den defekten Teil. Dies wurde bei der Übersiedlung in das Freihaus (Sommer 1996) durch strukturierte Verkabelung behoben.
Die Zunahme von angeschlossener Peripherie, z.B. von Festplatten, führte sehr schnell bis zum Limit der SCSI Busse und zu Instabilitäten. Außerdem bestand die Möglichkeit, dass bei jedem Umstecken Kabel und Steckverbindungen unzuverlässig wurden. Zu den Verkabelungsproblemen kamen noch Stellplatzprobleme und ungenügende Lüfter und Netzteile in den Zusatzgehäusen. Das Wechseln und Umkonfigurieren von Platten im Betrieb war nicht möglich. Die Anschaffung von Storage Works RAID-Systemen hat diese Probleme sehr verringert (Jänner 1997 bzw. März 1998), siehe: http:// www.storage.digital.com/swrks/.
Das Backup (als „snapshot“ zum Aufsetzen nach größeren Problemen) hinkte eigentlich immer hinter der Entwicklung des Plattenplatzes her. Zu weiteren Funktionen wie dem Archivieren älterer Software usw., d.h. zu einer ausreichend dimensionierten Backup-Lösung, hat es nie gereicht.
Ein Benachrichtigungssystem über signifikante (kritische) Systemzustände wurde selber in Ansätzen ent- wickelt; aber so elementare Funktionen wie geordnetes Shutdown bei Übertemperatur waren nicht von Haus aus vorgesehen. Als Zusatz wurde mit einer USV und geeigneter Software ein Shutdown bei Problemen mit der Stromversorgung realisiert (Sommer 1996).
Mit zunehmenden Datenmengen erwiesen sich sowohl die Leistung der CPUs (etwa beim Erzeugen von tar-Archiven oder beim Komprimieren von Daten) als auch die der 10Mbit Ethernet-Anschlüsse (in Spitzenzeiten) mehr und mehr als unzureichend.
Hauptanforderungen für den Einsatz in der Software Distribution sind ausreichend Plattenplatz und schneller Zugriff darauf sowie die Übernahme der bereits vorhandenen RAID-Systeme von StorageWorks. Gefordert sind geeignete Netzwerkanbindung mit TCP/IP (an der TU heißt das zur Zeit Ethernet und ATM), Unterstützung von Systemen zum Zugriff auf Medien wie CDs und anderer in Zukunft absehbarer Distributionsmedien, ausreichende Redundanzen auf verschiedenen Ebenen (Maschinen, CPUs, Netzwerk, Festplatten), Test- und Diagnosemöglichkeiten, zugesicherte Lieferzeiten bei Ersatzteilen. Die Analyse der Standzeiten während der letzten Jahre brachte folgende Ergebnisse: erstens Wartungsarbeiten, weiters einmal eine defekte Batterie im RAID und einmal Überlastung der USV. Die meisten Wartungsarbeiten können durch den Einsatz von zwei (oder mehr) Maschinen ohne Beeinträchtigung der Services durchgeführt werden. Unsere RAIDs sind so konzipiert, dass alle Teile in doppelter Ausführung vorhanden sein können, dies war zur Zeit des Batterieproblems noch nicht der Fall. So bleibt schließlich die USV, deren Dimension rechtzeitig an die Anforderungen angepasst werden muss.
Die Randbedingungen für die Software-Verteilung an der TU sind:
Plattenplatzentwicklung am SWD (in GByte)
Es wurden drei SUN Ultra Enterprise 450 Server beschafft, von denen zwei in einer Cluster-Konfiguration mit „failover“ betrieben werden. Die dritte dient dem Testen und Entwickeln von Software bzw. als Ersatz bei größeren Problemen. Diese Variante ist kostenneutral zu einem brauchbaren Wartungsvertrag und gibt uns mehr Flexibilität bei Entwicklung und Testen.
Die Systeme sind jeweils mit 2x296 MHz Prozessoren, redundanten Netzteilen, Lüftern, SCSI-Controllern, Ethernet- und ATM-Anschlüssen ausgestattet. Der Defekt von Einzelkomponenten sollte normalerweise keinen Totalausfall der Maschine bewirken, sondern nur eine Verringerung der Leistung. So besteht zum Beispiel die Möglichkeit, CPUs über Software abzuschalten, der Austausch von CPUs im Betrieb ist dagegen nicht möglich.
Die beiden bereits jetzt in Verwendung befindlichen StorageWorks RAID-Systeme arbeiten zufriedenstellend und sind auch relativ zukunftssicher, d.h. in verschiedenen Konfigurationen einsetzbar. Diese RAIDs wurden mit einem zweiten, redundanten RAID-Controller ausgestattet und so an die aktuellen Anforderungen angepasst. Weiters wurden 24 Festplatten zu 18 GB angeschafft. Die Verfügbarkeit von 18 GB Festplatten hat die Diskussion über andere Massenspeicher (MO-Jukebox u.ä.) zur Zeit obsolet gemacht. Die neue USV MX-5000XRW von APC (http://www.apcc.com/) wird in Kombination mit der PowerChute Software verwendet. Mit einer Kapazität von 5000 VA, Temperatur- und Feuchtigkeitsüberwachung wurde der Zustand gegenüber der existierenden Anlage auf das benötigte Niveau bei der neuen Konfiguration angehoben. Die Überwachung der Anlage durch Temperaturfühler ist nicht nur in der USV, sondern auch in den RAIDs und den SUN 450 Systemen vorhanden. Durch PowerChute werden von der USV entsprechende Alarme ausgelöst – wobei auch die Ansteuerung von bis zu 8 Geräten vorgesehen wurde.
Die Wartungsfreundlichkeit und damit verbundene – hoffentlich – geringe Standzeiten durch „hot swap“, „hot spare“ von Festplatten und ähnliche Maßnahmen sind bei den RAIDs und in den SUN 450 Systemen Standard. Auch der Tausch von Batterien der USV im „bypass mode“ ist ein ähnliches Feature.
Bei den Hardwarekomponenten wurde großer Wert auf konservatives solides Design gelegt. Die Gehäuse sind modular, passen z. B. in 19" Einschübe und kommen ohne exotisches (Gehäuse-)Design aus. Bei den Kabeln und Steckverbindungen bringt hoffentlich der Übergang auf SCSI-3 Stecker (VHDCI) Verbesserungen gegenüber SCSI-2, die ja eher als Einwegprodukte anzusehen waren. Für ausreichende Redundanz wurde vorgesorgt: Der Ausfall eines Lüfters, Netzteiles, einer Netz-werkanbindung, einer Festplatte (pro Raidset) o.ä. sollte gut überstanden werden.
Für das Backup wurde ein neues DLT-System ausreichender Kapazität (DLT7000) angeschafft (siehe: http:// www.quantum.com/products/dlttape/dlt7000/.
Gegenüberstellung (alt/neu):
|
CPU |
2 x 50 MHz |
2 x 296 MHz |
|
Memory |
192 MB |
512 MB |
|
Netz |
10 Mbit |
1155 Mbit ATM |
|
Expansion |
4 x Sbus |
10 x PCI |
|
Disks |
150 GB |
bis 1 TB |
Bei der Software-Liste ist natürlich einiges bereits durch die verwendete Hardware vorgegeben:
Das Betriebssystem für die neue Anlage ist Solaris 2.6, was unserer Anforderung nach möglichst weit verbreiteter Software entspricht. Die unter diesem Betriebssystem vorhandene Programmierumgebung ist uns vertraut. Adaptierungen der Verteilungsmechanismen über TCP/IP oder andere an der TU gängige oder gewünschte Protokolle sollten keine ernsthaften Probleme bereiten.
Als Cluster-Software mit „failover“ Eigenschaften wählten wir das Produkt „watchdog“ der Firma Wizard in München, das unseren Anforderungen (KISS – keep it small and simple) entspricht (siehe: http://www. wizard.de/). Als Backup-Software verwenden wir Solstice Backup Version 5.0.1 (= Legato NetWorker).
Zur Unterstützung von Filesystemen, Volumes, dem Verändern von Filesystemen im Betrieb (growfs), „transaction tracking“ (journaled file systems) und zum Aufsetzen unserer Verteilungs-Software verwenden wir weiterhin Online DiskSuite Version 4.1.6 (ODS) unter Solaris. Bei Bedarf ist aber auch der Übergang auf Veritas Produkte geplant.
Das bereits vorhandene „notification system“: mail, SNMP, Pager, Auswerten von Logs wird kontinuierlich weiterverbessert, wobei auf entsprechende Unterstützung bei den neueren Komponenten geachtet wurde. Die „monitoring services“ bei der USV oder „ambiental monitoring“ bei den SUNs sind wesentliche Verbesserungen gegenüber der alten Anlage.
Auf beiden Maschinen ist das Betriebssystem auf gespiegelten internen Platten (4 GB) installiert, sodass jede für sich lauffähig ist. Produktdaten, Home-Directories der Benutzer, SDS-Programme, Webspace etc. sind auf den RAIDs abgelegt, die als „shared SCSI devices“ von beiden Maschinen aus zugänglich sind (siehe Abbildung). Zum einwandfreien Funktionieren muss sichergestellt sein, dass alle „SCSI devices“ (SCSI-Controller in den SUN-Rechnern, RAID-Controller, RAID-Sets) am geteilten Bus eindeutige SCSI-IDs haben. Vier von acht IDs sind also von den Controllern belegt. Durch die Verwendung von LUNs können trotzdem mehr als vier RAID-Sets (logische Platten) verwendet werden. Mittels „watchdog“ bzw. ODS wird gewährleistet, dass ein RAID-Set zu jedem Zeitpunkt höchstens einem Rechner zugeordnet ist, was für die Datenkonsistenz unumgänglich ist.
Die HA-Software „watchdog“ (high availability) ist auf beiden Rechnern installiert und kommuniziert über zwei, also wieder redundante, Ethernet-Verbindungen (heartbeat). Pro Service (z.B.: swd.tuwien.ac.at) wird eine Konfigurationsdatei angelegt, in der für das Service benötigte Platten, Netzwerkschnittstellen etc. definiert werden. Diese Betriebsmittel werden laufend überprüft und die Ergebnisse der Überprüfung über die Heartbeat- Leitungen ausgetauscht. Beim Auftreten von Fehlern wird ein „failover“ initiiert. Bei der Übernahme des Services werden rc-Skripts ausgeführt. So kann auf einfache Weise das „Aussehen“ des Services bestimmt werden.
Im Jahre 1995 wurde mit dem neuen Server die MS-Direktinstallation (Samba) eingeführt, so wollten wir auch diesmal nicht nachstehen und etwas Neues bringen. Heute mehr als damals ist der Webbrowser ein tagtäglich verwendetes und jedermann vertrautes Werkzeug. Es lag also nahe, den Zugriff auf die von Ihnen lizenzierten Produkte über HTTPS zu ermöglichen.
https://swd.tuwien.ac.at:8000/
Neben der einfachen Bedienung spricht auch der Umstand dafür, dass immer mehr (Online)Dokumentationen in den Formaten HTML und PDF auf den Markt kommen, zu guter Letzt ist auch das Security-Argument anzuführen. Im Gegensatz zu FTP ist die Übertragung über HTTPS verschlüsselt (siehe auch Artikel ).
Für ausführlichere Angaben sei auf die Unterlagen der Hersteller, White Pages von SUN usw. verwiesen. Zur Software-Distribution an der TU Wien findet man immer wieder relevante Artikel in der PIPELINE.
Viele Beiträge wurden nach und nach überarbeitet und für Anleitungen zum Bezug von Campus-Software 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, dass es in diesem Bereich einer intensiven Zusammenarbeit bedarf. Weitere interne Unterlagen sind z. B. in den Jahresberichten der Abteilung, den Dokumentationen zum Software Distribution System oder dem relevanten Mail-Verkehr enthalten.
PIPELINE 8, Oktober 1992:
Günter Houdek, Neuer Software-Server, p. 11-12;
Helmut Mayer, Informationen über Dienste des Software-Distribution Servers
SWD, p. 12
PIPELINE 9, Jänner 1993:
Albert Blauensteiner, Die Software-Server der
Abt. Institutsunterstützung; p. 6; Günter Houdek, Ausbau des Software-Servers,
p. 7
PIPELINE 12, Februar 1994:
Günter Houdek, Ausbau des Software-Servers und
SunOS-Tuning, p. 37; Georg Gollmann, Serverstrategie der Abteilung Institutsunterstützung,
p. 38; Georg Gollmann, GemStone an der Abteilung Institutsunterstützung,
p. 38-39
PIPELINE 15, Februar 1995:
Antonin Sprinzl, Informationsangebot der Abteilung
Institutsunterstützung: Spektrum, Bezugsmöglichkeiten, p. 27-30
PIPELINE 16, Juni 1995:
Albert Blauensteiner, Campus-Software: Veränderungen
im Bezug; p. 21; Georg Gollmann, Neue Server der Abt. Institutsunterstützung,
p. 33
PIPELINE 17, Oktober 1995:
Udo Linauer, Der neue Campus-Software-Server,
p. 5-7; Milan Knezevic, Direktinstallation vom CampusSoftware-Server, p.
7-8; Tony Sprinzl, Goodie Domain Service der Abteilung Institutsunterstützung,
p. 17-18
PIPELINE 18, Februar 1996:
Helmut Mayer, Online Bestellung von Campus-Software,
p. 13
PIPELINE 21, Februar 1997:
Werner Steinmann, Softwaredistributionsserver
SWD, p. 11-13; Udo Linauer, Statistiken der Softwaredistribution, p. 14-15
PIPELINE 22, Juni 1997:
Albert Blauensteiner, Direktinstallation von CampusSoftware
über WWW, p. 8
PIPELINE 23, Oktober 1997:
Udo Linauer, Anleitung zum Bezug von CampusSoftware,
p. 23; Werner Steinmann, Die Entwicklung des Softwaredistributionsservers,
p. 28