Der neue Software Distribution Server SunFire 3800

Helmut Mastal, Werner Steinmann

Der neue Software-Server SunFire 3800 steht kurz vor der Inbetriebnahme als Hauptsystem für die Verteilung der Campus-Software der TU Wien. Damit wird das symmetrisch-redundante Doppelsystem von Sun Enterprise 450 Servern sukzessive abgelöst, und es kommt mittelfristig zu einer Konfiguration mit innerer Redundanz und einem höheren Anteil an aktiven Komponenten.

Entwicklung des Software Distribution Servers in den letzten drei Jahren

In den Jahren 1997/98 wurden zuletzt die Systeme des Software Distribution Servers neu installiert, indem eine SPARCstation 20 durch 2 gleiche, redundante Systeme Sun Enterprise 450 mit je 2 296 MHz Prozessoren und je 512 Mbyte Memory ersetzt wurde. Die SPARCstation 20 hatte bereits 3 Jahre zuvor eine noch ältere Sun Maschine (SPARCstation 330) abgelöst. Die beiden 450 Systeme, die also schon die 3. Generation der Software Distribution Server darstellten, bildeten ein symmetrisches Active-Standby Paar. Zur Vorrätighaltung der zu verteilenden Campus-Software dienten zwei StorageWorks RAID-Systeme mit netto ca. 500 Gbyte Speicherplatz bei den damaligen Plattengrößen. An Software wurde angeboten: Anwendungssoftware für PC und Unix sowie Betriebssysteme für PC. Gleichzeitig wurde die Administrationssoftware SDS (Software-Distribution-System) laufend weiter entwickelt und verfeinert, mit der die Validierung der Benutzer und die Zuordnung der in Sublizenzen vergebenen Software-Pakete ermöglicht wird. Den Benutzern steht die Software über die Services FTP, Samba und HTTPS zur Verfügung. Der Zugang über SFTP wird derzeit in Erwägung gezogen.

Erfreulicherweise entwickelten sich der Software-Server und die Akzeptanz seiner Dienstleistungen sehr gut. Es war in den letzten Jahren mit einem zehnprozentigen jährlichen Zuwachs bei der Anzahl der Software-Downloads zu rechnen. Der Speicherplatzbedarf für Campus-Software stieg aber wegen der zunehmenden Komplexität der Software-Pakete und höheren Spezialisierung bis zu 40 Prozent pro Jahr. Dieser Zuwachs konnte zeitweise nur durch eine rigorose Politik bei der Zurverfügungstellung alter Software-Versionen bewältigt werden.

Es ist daher nicht verwunderlich, dass bald nach der Installation der Enterprise 450 Servergeneration Überlegungen über die nächste Innovation angestellt wurden. Dabei bildete sich folgende Zielvorstellung heraus: Nach Erreichung des Endes des Lifecycles der 450 sollte ein Server/Speicher-System zur Verfügung stehen, das in der Lage war, wesentlich größere Datenmengen (Terabytes) vorrätig zu halten, und das auch leistungsfähig genug war, die notwendigen seriellen Batch-orientierten Operationen (Backup, Linken der den Benutzern zugewandten Verzeichnisse mit den gespeicherten Daten) in einer vernünftigen Zeit durchzuführen. Auch sollte diese Leistung dadurch erbracht werden, dass ein höherer Anteil der Gesamtressourcen aktiv dem Benutzerbetrieb zur Verfügung steht als bisher.

Mit diesem Szenario als Ziel wurden bereits in den Jahren 1999 und 2000 Investitionen getätigt, die unmittelbare Entlastungen bei den vorhandenen 450 Systemen bringen sollten, aber auf jeden Fall auch in das Gesamtkonzept der nächsten Servergeneration ab 2001/2002 passen mussten. In diesem Sinne wurden im Herbst 1999 zwei Bandwechselsysteme (Jukeboxes) vom Typ Overland LibraryXpress mit je 15 Slots für Backup-Zwecke angeschafft, die das vorhandene DLT 7000 Laufwerk ablösten und in ihrer Kapazität bis zu ca. 1 Terabyte Daten ausreichen werden. Im Frühjahr 2001 wurde schließlich die Backup-Maschine SPARCstation 20 (SWD-Server der 2. Generation) durch eine Sun Enterprise 450 abgelöst und damit die Performance der Server-Backups verbessert.

Die wesentliche Erneuerung im Jahr 2000 war der Übergang zu einer neuen Generation von Speichersystemen. Es wurde das MetaStor RAID-System 3702 angeschafft, das mit heutigen Plattengrößen (73 Gbyte) bis zu 2 Terabyte (netto etwa 1.5 Terabyte) sinnvoll ausbaubar ist und paarweise redundante Verbindungen zu jedem Host in Fibre-Channel Technologie mit Gigabit-Übertragungsraten ermöglicht. Das RAID-System 3702 ist damit als SAN (Storage Area Network) anzusprechen und hat mit einem Lifecycle von etwa 5 Jahren genau so in die bestehende vollredundante Konfiguration der 450er zu passen wie in die Endkonfiguration mit innerer Redundanz, die voraussichtlich 2002/2003 erreicht werden wird.

SWD Abbildung
SWD 1. Generation SPARCstation 330 (hinten), plus Plattengehäuse
SWD Abbildung
SWD 2. Generation SPARCstation 20
SWD Abbildung
SWD 3. Generation Sun Enterprise 450
SWD Abbildung
SunFire 3800: Fronttüre geöffnet, sichtbar (von oben nach unten):
RAID T3, Domain Controller, CPU/Memory Board, cPCI Interface Karten, redundante Stromanschlüsse
SWD Abbildung
SunFire 3800: Gesamtansicht
SWD Abbildung
altes StorageWorks RAID-System 450
SWD Abbildung
Neues MetaStor RAID-System 3702
SWD Abbildung
2 Overland Bandwechselsysteme + Sun Enterprise 450

Erfahrungen aus der bisherigen Struktur

Die bestehende, aus den Jahren 1997/98 stammende Servergeneration ist als symmetrische, hoch redundante Lösung anzusehen, mit den beiden Sun Enterprise 450 Systemen als 100-prozentiges gegenseitiges Backup, während die beiden alten (jetzt schon außer Betrieb genommenen) StorageWorks RAID-Systeme für einen sinnvollen Benutzerbetrieb stets gleichzeitig benötigt wurden. Hochredundante Lösungen können folgende Probleme in sich bergen: einerseits sind möglicherweise Komponenten doppelt ausgeführt, die nie oder sehr selten (innerhalb des Lifecycles von etwa 3 Jahren) Fehler aufweisen, andererseits können gerade in hochredundanten Konfigurationen sehr leicht neue Single-Points-of-Failure entstehen (oder übersehen werden), allein dadurch, dass die Verbindungen zwischen den einzelnen Redundanzebenen nicht mit der erforderlichen 4fach-Redundanz ausgeführt sind.

Die vollständige Redundanz für ein Service bewirkt, dass höchstens die Hälfte aller vorhandenen Ressourcen produktiv genutzt werden kann, während der Rest nur darauf wartet, dass irgendeine aktive Komponente ausfällt. Auch in der ursprünglichen Sun 450 Konfiguration gab es solche versteckte Single-Points-of-Failure: das waren das ATM-Interface für den Benutzerzugang, sowie die für beide Systeme gemeinsame USV (unterbrechungsfreie Stromversorgung), die nur einen einzigen Stromkreis unterstützte. Alle diese versteckten Probleme konnten mit geringen Mitteln noch für die alten 450 Systeme behoben werden und für die Neuplanung entsprechend berücksichtigt werden (nur 100 Mbit/s Ethernet-Interfaces, zwei Stromkreise einer neuen Emerson USV (von Liebert Hiross) dediziert für den Software-Server). Untersucht man die tatsächlich aufgetretenen Takeovers, also die fehlerbedingten Wechsel von einem System zum anderen, so findet man etwa ein Takeover pro Monat im Durchschnitt, wobei aber die Mehrzahl zu Lasten der alten USV geht, jedoch kein einziger Fall auf ein permanentes Hardware-Problem bei den Serversystemen zurück zuführen ist.

Planung des neuen Servers SunFire 3800

Schon bei den ersten Planungen für das neue Softwareserver-System war klar, dass bei einem System, das Services für den gesamten Campus 24 Stunden pro Tag über das Netz anbietet, nie wirklich auf Redundanz verzichtet werden kann. Es sollte aber bei allen Komponenten, insbesondere bei den teuren Ressourcen wie Prozessoren und Speicher genau abgeschätzt werden, ob eine 100-prozentige Redundanz wirklich notwendig und sinnvoll ist, und ob nicht Redundanz in geringerem Ausmaß eine genügend hohe Verfügbarkeit liefert. Es ergab sich daraus in der Folge die Forderung, dass von den kritischen, teuren Ressourcen mindestens zwei Drittel aktiv für den Normalbetrieb zur Verfügung stehen sollen, und höchstens ein Drittel als Hot-Standby bereit gehalten wird.

Da im heurigen Frühjahr die SunFire Servergeneration als Nachfolgeserie der Sun Enterprise Generation auf den Markt kam, wurden Lösungen, die Redundanz in einem bestimmten Ausmaß vorsehen, durch das in der SunFire Serie ab dem Modell 3800 vorhandene Domainkonzept sehr begünstigt. Dieses baut auf innere Redundanz auf und kann Ressourcen im Verhältnis von Prozessor/Memory-Boards aufteilen. Da es schließlich gelang, einen SunFire Server 3800 mit 4 Sparc III Prozessoren und 4 Gbyte Memory zu einem unschlagbar günstigen Einführungspreis von Sun Austria zu erwerben, war der weitere Weg klar: Neben der SunFire 3800 als aktivem Server bleibt zunächst eine der Sun 450 mit einem auf 2 Gbyte erweiterten Hauptspeicher als Hot-Standby Server erhalten. Zu einem späteren Zeitpunkt wird unter Ausnützung des Domainkonzepts die SunFire 3800 um eine zweite Domain mit nur 2 Prozessoren erweitert, sodass dann wieder zwei Drittel des Gesamtsystems aktiv bleiben. Das zweite alte Sun Enterprise 450 System bleibt (wie die meisten älteren Software-Server-Systeme) produktiv erhalten und wird in Zukunft als neuer Goodie-Domain-Server eingesetzt werden.

RAID-Belegung

Übersicht RAID-Belegung (GB) 1. 1. 1997 bis 31. 12. 2000

SWD Downloads

SWD-Downloads im Jahr 2000, nach Produktgruppen

Installation und Konfiguration des neuen Servers

Hardware

Die drei vorhandenen Sun Ultra Enterprise 450 Server werden Schritt für Schritt durch eine Sun Fire 3800 mit zwei Domains ersetzt. Mit der SunFire 3800 verlagert sich die Redundanz durch mehrere getrennte Maschinen auf die Ausfallssicherheit innerhalb eines Gehäuses, wobei weiterhin eine Cluster-Konfiguration mit Failover betrieben wird. Momentan besteht der Cluster aus einer Sun Ultra Enterprise 450 und einer SunFire 3800 mit einer Domain.

Die Begriffe Domain und Partition verwendet Sun in diesem Zusammenhang zur Beschreibung verschiedener Konfigurationsmöglichkeiten ihrer SMP Server. Diese Konzepte wurden mit der Sun Enterprise 10000 (Starfire, mit bis zu 64 UltraSPARC-II Prozessoren und 64 Gigabyte Hauptspeicher) populär und sind in der SunFire Serie weiterentwickelt worden.

Eine Sun Enterprise 450 ist schon seit einiger Zeit dediziert als Backup-Server mit Legato NetWorker im Einsatz. Das Backup großer Datenmengen ebenso wie das Einspielen läuft weitgehend über ein eigenes internes Netzwerk und nicht über die vom offiziellen TUNET erreichbaren Anschlüsse.

Eine weitere E450 wird nun für gd.tuwien.ac.at frei; generell wird in all unseren Plänen einer sinnvollen Nutzung für wiederverwertbare Teile hohe Bedeutung beigemessen. Und die dritte - zurzeit im Cluster befindliche - 450-er dient dem Testen und Entwickeln von Software bzw. als Ersatz bei Problemen.

Die bisherige Variante mit mehreren Maschinen war kostenneutral zu einem brauchbaren Wartungsvertrag und gab uns mehr Flexibilität bei Entwicklung und Testen. Bei der neuen Maschine ist ein Wartungsvertrag im Bundle dabei.

Die Sun Enterprise 450 Systeme sind jeweils mit 2 x 296 MHz UltraSPARC-II Prozessoren, mindestens 1 GB Memory, redundanten Netzteilen, Lüftern, SCSI-Controllern, Fibrechannel-Controllern, Ethernet- und ATM-Anschlüssen ausgestattet. Es gab seit ihrem Einsatz keine Totalausfälle der Maschinen sondern eher nur Standardsituationen wie Platten- oder Memory-Tausch. Die heiklen ATM-Anschlüsse haben sich nicht bewährt und wurden durch Fastethernet-Controller ersetzt, die absolut problemlos funktionieren und als Vierfachanschlüsse auch sehr kostengünstig sind.

Die neue Sun Fire 3800 hat ein CPU Board mit 4 GB Memory und 4x750 MHz UltraSPARC III CPUs (d. h. eine Domain/Partition). Sie ist mit einem Sun StorEdge T3 RAID und einem Media Tray D240 in einem Sun Fire Systemschrank eingebaut, wobei bezüglich Ausfallssicherheit gegenüber unserer bisherigen Konfiguration schon im Design viele Vorkehrungen getroffen sind und man nicht den Eindruck von Add-ons hat. Sogar die PCI Karten sind im Betrieb tauschbar, sie sind als cPCI (compact PCI) ausgeführt. Dieser Kartentyp ist aber (noch) nicht sehr weit verbreitet und falls man ganz bestimmte Karten wie für die Fibrechannel-Anbindung der verwendeten MetaStor RAIDs sucht, ist das langwieriger als die Verwendung gängigerer Interfaces. Das CPU Board ist in unserer Konfiguration natürlich nicht sinnvoll im Betrieb zu wechseln, sondern erst wenn ein zweites als zweite Domain vorhanden wäre. Im Betriebssystem bzw. im Domain Controller ist entsprechende Unterstützung der Hardware vorgesehen, es lassen sich z. B. CPUs und Interfaces aktivieren/deaktivieren.

Software

Bei der Software-Liste ist Einiges bereits durch die verwendete Hardware vorgegeben:

Als Betriebssystem für die neue Anlage ist Solaris 8 ab Release 4/01 notwendig, d. h. z. B., dass wir alle eingesetzte Software auf 64-Bit-Tauglichkeit überprüfen mussten. Auf der älteren Anlage war noch Solaris 2.6 in Verwendung (nach Version 2.6 wurde mit 7 bzw. jetzt aktuell 8 weitergezählt). Unserer Anforderung nach möglichst weit verbreiteter Software entspricht Solaris immer noch, obwohl sich in den letzten Jahren die Verbreitung verschiedener Unix-artiger Betriebssysteme stark geändert hat. Die unter diesem Betriebssystem vorhandene Programmierumgebung ist uns vertraut, wobei wir dabei wesentlich auf das GNU Project und andere frei verfügbare Programme zurückgreifen und nicht nur Produkte von Sun einsetzen. Die von Sun mitgelieferten Versionen von Perl etc. sind oft nicht die Versionen, auf die unsere Verteilungsmechanismen aufbauen, und müssen ergänzt werden. Auch bei der Programmierumgebung gab es unter Solaris 8 nicht nur einen Namenswechsel auf Forte statt bisher Workshop. Adaptierungen der Verteilungsmechanismen über TCP/IP oder andere an der TU gewünschte Protokolle sollten aber keine ernsthaften Probleme bereiten.

Als Cluster-Software mit Failover-Eigenschaften wählten wir nach unseren bisherigen Erfahrungen wieder das Produkt Watchdog der Firma Apptime (ehemals Firma Wizard) in München, das unseren Anforderungen (KISS - keep it small and simple) entspricht (siehe: www.apptime.de). Das von Sun selbst angebotene Cluster Environment ist ausschließlich auf Sun-Produkte konzentriert und wäre schon aus diesem Grund für unsere Konfiguration nicht sinnvoll einsetzbar.

Als Backup-Software verwenden wir Solstice Backup Version 6.0.1 (= Legato NetWorker), wobei wir zurzeit 35 Clients auf einem eigenen Backup Server unterstützen (Sun Enterprise 450 mit 2 Overland DLT Juke Boxes).

Im Falle eines GAUs wäre mit einer Woche zu rechnen, bis Hunderte von GigaBytes wieder von den Bändern restauriert sind.

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.2.1 (ODS) unter Solaris. Dieser betriebssystemnahe Software-Teil ist insofern kritisch, als auch hier die Umstellung von Solaris 2.6 bzw. 7 auf 8 zum Tragen kommt. Ein Übergang auf Veritas Produkte, die von Sun für seine eigenen Cluster-Lösungen verwendet und angeboten wird, war bisher nicht notwendig, denn ODS wird entgegen anders lautenden Ankündigungen weiterhin unterstützt und ist für unsere Bedürfnisse ausreichend.

Das bereits vorhandene Notification System (Mail, SNMP, Pager, Auswerten von Logs) wird kontinuierlich weiter verbessert, 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.

Um mit der Entwicklung bei den Konsolen für Server (Domain Controller) oder RAID Schritt zu halten, haben wir ein neues, rein administratives 10 MBit/s Netzwerk eingeführt. Das Sun T3 RAID hat einerseits bereits gar keine serielle Konsole mehr, andererseits sind zur Konfiguration über Ethernet nur unsichere Protokolle wie Telnet und Ftp vorgesehen. Bei Netzwerkdruckern ist diese Art von Konfiguration im schlimmsten Fall wahrscheinlich höchstens lästig, aber kein Desaster wie eine gestörte Konfiguration bei einem RAID. Die Steuerung der StorageWorks RAIDs basierte noch auf einem offensichtlich proprietären Betriebssystem der Firma Digital, der Domain Controller, das T3 und die MetaStor RAIDs bauen hingegen auf bekannten embedded UNIX-Systemen wie VxWorks oder pSOSystem auf. Das Ansprechen der RAIDs zur Konfiguration über den SCSI-Bus ist aber erst nach einer Grundkonfiguration im Console Mode möglich oder andere elementare Funktionen wie Firmware Upgrade sind (sinnvollerweise) nur so vorgesehen.

Ausblick und zukünftige Services

Die Vollinbetriebnahme der SunFire 3800 ist mit dem Zusammenschluss mit dem RAID-System 3702 noch im November diesen Jahres geplant und möglicherweise bei Erscheinen der ZIDline bereits abgeschlossen. Die Benutzer am Campus der TU Wien sollten davon nicht allzu viel merken. Auch die Services des neuen Servers werden weiterhin über den generischen Hostnamen swd.tuwien.ac.at angesprochen. Nach der Inbetriebnahme ist daran gedacht, SFTP (Secure FTP) als neues Service anzubieten, insbesondere aber nicht ausschließlich für Unix-Benutzer, da das alte FTP keine verschlüsselte Übertragung kennt, Samba-Clients im Unix-Bereich aber nicht sehr verbreitet sind (vergl. auch den Artikel "Wie komme ich zu meiner Campussoftware ?“).

Referenzen

Für den allgemeinen Überblick ein Buch von: Adrian Cockcroft and Richard Pettit, Sun Performance and Tuning, Sun Microsystems Press, Second edition, 560 pages, ISBN 0-13-095249-4

Ältere Artikel zum Software Dstribution Service an der TU Wien sind im Archiv der Ausgaben von Zeitschriften des ZID nachzulesen: www.zid.tuwien.ac.at/zidline/archiv.html

Für aktuelle Informationen einige Web Pages der Hersteller im Internet bzw. Software Server zur verwendeten Software auf swd.tuwien.ac.at, z. B. sind die Manuals für Sun Systeme über deren Homepage oder direkt unter docs.sun.com zu finden:

Sun Microsystems, white papers, manuals, patches: www.sun.com
SunFire 6800/4800/3800 Systems Overview Manual

Overland Data DLT juke boxes: www.overlanddata.com

LSI Logic - Metastor RAID: www.lsilogic.com

JNI - fibre channel adapter: www.jni.com

Apptime - Watchdog Cluster Software: www.apptime.de
Apptime Watchdog Service Cluster System Adminstration Handbook, Juli 2001

The Apache Software Foundation, Web Server: www.apache.org

Samba Web Pages, Samba Server (Netbios over TCP/IP): www.samba.org

aufbereitete Solaris Freeware: www.sunfreeware.com

Liebert Hiross Emerson USV: www.liebert-hiross.de

Peter Pawlak, "Five Nines" - Is It Even Possible ? Directions on Microsoft UPDATE, Juni 2001


TopSeitenanfang | ZIDline 6 - Dezember 2001 | ZID | TU Wien