Wie vielen sicher aufgefallen ist, war der Newsserver diese Woche praktisch
nicht erreichbar. Ich moechte hier kurz die Ursachen, soweit wir sie
bisher analysieren konnten, darstellen.

Am Montag, 22.7.96, um 12:30 wollten wir die neue News-Server Konfiguration
in Betrieb nehmen (siehe auch getrenntes Posting).
Diese neue News-Server Konfiguration ist auf einer deutlich schwaecheren
Hardware (SUN Sparc 10/30 mit 64 MByte Hauptspeicher) bereits seit einer
Woche im Betrieb gewesen (unter dem neu installierten Betriebssystem
Solaris 2.5 mit der aktuellesten News-Server Software)
und hatte in dieser Zeit bereits im Parallelbetrieb alle News-Artikel
erhalten (dadurch wird sichergestellt, dass bei der Umstellung auf die
neuen Platten die Artikel-Nummern gleich bleiben, da sonst in den
bei den Benutzern gespeicherten status-files, in denen steht, welche
Artikel bereits gelesen wurde, keine Verwirrung entsteht).
Dieser Parallelbetrieb verlief ohne Problem. Natuerlich war keine Benutzerlast
auf diesem Server -- abgesehen von einigen Tests von uns.

Am Montag haben wir dann den bisher in Betrieb befindlichen News-Server
(ein SPARC 10 kompatibles System mit einer 50 MHz CPU) mit einer zweiten
CPU versehen und den Hauptspeicher auf 256 MByte aufgeruestet, sowie die
Platten des Parallelbetriebs an das System angeschlossen. Dies hat zwar etwas
laenger benoetigt als erwartet (div. Probleme bei Konfiguration der
diversen Kontroller und Platten, Kabel, etc.), war aber im Prinzip erfolgreich.

Der News-Server lief dann in der Sollkonfiguration in Produktion, d.h. es
wurden bereits News-Artikel ohne Probleme von der UNI empfangen. Aus
Sicherheitsgruenden haben wir jedoch noch nicht den allgemeinen Benutzer-
betrieb gestartet (nachdem die Produktion wegen der Verzoegerungen erst am
Abend moeglich war, wollten wir das System nicht der vollen Belastung
aussetzen, wenn niemand da ist).

Dienstag Mittag wurde der allgemeine Benutzerbetrieb gestartet und das
System verhielt sich normal.

Nach ca. 45 Minuten Benutzerbetrieb ist das System ploetzlich einfach
stehen geblieben, wobei eine Platte ewig das Busy-LED leuchten hatte.

Bei einem zweiten Versuch trat das gleiche Verhalten auf.

Die naechsten Tage verbrachten wir dann damit die Hardware-Konfiguration
systematisch durch andere Teile zu ersetzten:

• andere Kabel
  - andere Gehaeuse fuer System und /var Platte
  - wieder alte Hardware, die eine Woche problemlos gelaufen ist, verwenden
  - jede der Platten auf eine Platte des gleichen Typs umkopieren, (Platte
  koennten einen Defekt haben, der erst unter staerkerer Last auftritt)
  - jede der Platten auf einen anderen Typ umkopieren (wir koennten ein
  Problem mit einer relativ alten Firmware der Platten unter Solaris 2.5
  haben)
  - unbenutze SCSI-Kontroller aus Maschine entfernen
  - Reihenfolge der Kontroller aendern
  - Anderen Treiber fuer Fast/Wide SCSI Kontroller verwenden
  - Fast/Wide SCSI-Controller tauschen (er koennten ja kaputt sein)
  - Upgrade der Firmware am Motherboard auf die aktuellste Version

Jeder dieser Versuche kostet beim Umbau ca. 1 Stunde bis einen halben Tag
(inklusive dem meistens nachher notwendigen Filesystemcheck, - dauert bei
den News-Platten ca. eine Stunde!). Zum Glueck trat der Fehler waehrend
der Versuche meistens bereits nach ca. 5 Minuten auf.

Erst der Tausch des Motherboards von einer SPARC 10 Architektur auf eine
SPARC 20 Architektur brachte Donnerstag abend, ca. 19 Uhr den Erfolg.
Dies obwohl alle Komponenten laut Datenblatt etc. sehr wohl fuer eine
SPARC 10 gebaut sind.
Warum dies geholfen hat, wissen wir (und die befragten Firmen und Kollegen)
nicht wirklich, da zwischen SPARC 10 und SPARC 20 nur minimale Unterschiede
bestehen.

Wir hoffen dass dies das Problem wirklich geloest hat.
In der Zwischenzeit (ca. 20 Stunden) haben wir bereits 350.000 Artikel
mit insgesamt 4 GByte empfangen. Der Backlog der auf Uebertragung an der
UNI wartenden Artikel ist von ueber 650.000 Artikel bereits auf 425.000
Artikel reduziert worden. Der Backlog sollte ueber das Wochenende komplett
abgebaut werden (die minimale Aufhebezeit von Artikeln ist jetzt bereits
4 Tage).

In den naechsten Tagen wird es noch zu einigen kuerzeren Unterbrechungen
kommen, da wir diverse Umbauten im Zuge unserer Versuche erst wieder
rueckgaengig machen muessen.

--
Johannes Demel demel@edvz.tuwien.ac.at demel@noc.tuwien.ac.at
demel@tron.kom.tuwien.ac.at Johannes.Demel@tuwien.ac.at
Computing Center, Head of Communication Group, University of Technology, Vienna
Wiedner Hauptstrasse 8-10/020, A-1040 Wien, Austria
Tel: +43 (1) 58801-5829 Fax: +43 (1) 5874211