Ausbau des Newsservers

Johannes Demel

Im Zuge des Investitionsprogramms (ca. 550.000 Schilling) zur Anpassung des Newsservers an die gestiegenen Anforderungen (ca. 40% Steigerung des Newsaufkommens pro Jahr) wurde der Massenspeicher für News-Artikel von bisher ca. 8 GByte auf ca. 16 GByte netto (ca. 40.8 GByte brutto) in einer RAID/Mirror Konfiguration aufgerüstet sowie die CPU-Leistung und der Hauptspeicher verdoppelt (nun 2x SPARC 50 MHz CPUs mit insgesamt 256 MByte Hauptspeicher). Gleichzeitig mußte zur Umsetzung der Investitionen das Betriebssystem umgestellt werden.

Mit dem vergrößerten Massenspeicher sollte es zumindest bis Ende dieses Jahres möglich sein, mindestens vier Tage Speicherung aller Newsartikel zu garantieren.

Die bisherige Software/Mirror-Lösung ist nach der Aufrüstung durch eine RAID/Mirror-Konfiguration in Hardware (DEC Storage Works) ersetzt, wodurch die Plattenstabilität weiter erhöht werden sollte. Durch die extrem hohe Belastung der Platten durch das Newsservice werden laufend Platten defekt (typisch alle 2 bis 4 Wochen). Aus diesem Grund wird schon seit ca. einem Jahr eine Mirror-Lösung (bisher in Software, nun mit eigener Hardware) eingesetzt, damit diese Ausfälle keine Betriebsunterbrechung bewirken.

Nach der Installation der neuen Konfiguration (die zu diesem Zeitpunkt bereits ca. eine Woche ohne Probleme im Test gelaufen ist) traten unerwartete Probleme auf. Diese Probleme äußerten sich dadurch, daß das System plötzlich stehen bleibt, wobei die Platten aktiv sind, aber nicht mehr richtig arbeiten. Die Ursache konnte trotz umfangreicher Tests bis jetzt nicht eindeutig geklärt werden. Vermutlich liegt das Problem bei Software-Fehlern im Solaris Betriebssystem 2.5.

Nach Einbau der 15 allerneuesten Patches von SUN trat bis zu Redaktionsschluß kein Fehler mehr auf. Wir hoffen, daß das Problem dadurch beseitigt ist.

Als Hintergrundinformation hier einige Bemerkungen zur generellen Problematik eines Newsservers: Ein Newsserver zeichnet sich durch folgende Anforderungen aus:

• Hohe Plattenkapazität, wenn die News-Artikel entsprechend lange aufgehoben werden sollen. Der Massenspeicherplatz wird hauptsächlich durch die diversen *.bin* Newsgruppen bewirkt.
• Extrem kleine durchschnittliche Artikel (= Filegröße), abgesehen von den wenigen Artikeln mit Binaries (ca. 45% der Artikel sind zwischen 1 und 2 kByte groß, ca. 20% kleiner als 1 kByte, ca. 25% zwischen 2 und 4 kByte, nur ca. 0.4% aller Artikel sind größer als 100 kByte). (Siehe auch die beiden Abbildungen über die Verteilung der Artikel und des belegten Platzes in Abhängigkeit von der Artikelgröße).
• Eine sehr hohe Fluktuation der Artikel und des Massenspeichers. Ca. 180.000 neue Artikel mit insgesamt ca. 2.4 GByte pro Tag. Insgesamt derzeit ca. 1.4 Mio. Artikel.
• Hohe Benutzerzahl (derzeitiger 24-Stunden Schnitt ca. 30 gleichzeitige Newsleser, Spitzenwerte bis ca. 150 gleichzeitige Newsleser). über 350 verschiedene Sub-Domains bzw. Rechner in der Top-Level Domain tuwien.ac.at lesen News (die Wählleitungszugänge und die Benutzerraumarbeitsplätze zählen jeweils als ein Rechner!).
• Von den Benutzern der TU Wien werden über 4500 verschiedene Newsgruppen gelesen.
• Die Anzahl der Zugriffe auf Artikel ist im Monatsschnitt etwa gleich oder höher als die Anzahl der Artikel, die wir erhalten.

Infolge dieser zum Teil sehr extremen Werte ergeben sich folgende Konsequenzen:

• Es ist eine sehr hohe IO-Last von sehr kleinen Files, die wirr auf der Platte verstreut sind, gegeben. Durch dieses Verhalten werden natürlich auch die Platten extrem belastet.
• Ein wirklich effektives Caching ist hier praktisch nicht realistisch möglich (allein die Overview-Files, aus denen der Newsreader die Liste der Artikel einer Newsgruppe mit Subject und From erhölt, - die neben den Directories am häufigsten zugegriffenen Files - sind schon über 300 MByte groß).
• Eine Datensicherung der vielen kleinen Artikel ist realistisch nicht möglich. Daher muß zur Erhöhung der Betriebssicherheit eine Mirror-Konfiguration verwendet werden. (Benchmarks und theoretische Überlegungen haben ergeben, daß eine RAID 5 Konfiguration, die weniger Platten benötigt, eine Performance-Verschlechterung um 50% mit sich bringt!)
• Die hohe Anzahl von kleinen Files stellt eine extrem ungewöhnliche Anforderung an das Filesystem praktisch aller Betriebssysteme dar. Kurz der Hintergrund: Unter Unix verwaltet das Betriebssystem den Platten-Platz, üblicherweise in 8kByte Blöcken. Soll ein kleineres File angelegt werden, so werden von diesem Block Fragmente erzeugt, die 1k, 2k oder 4k groß sein können. Files, die größer als 8kByte sind, können jedoch nur in vollen Blöcken angelegt werden. Dies führt bei einem Newsserver unter Umständen dazu, daß zwar noch Massenspeicherplatz da wäre, aber infolge der Fragmentierung der Blöcke keine ganzen freien Blöcke mehr. So hatten wir Situationen, wo 300Mbyte oder mehr Platz frei war, aber trotzdem keine Newsartikel mehr empfangen werden konnten, da keine freien Blöcke mehr vorhanden waren.
• Im Falle einer Störung (des eigenen Servers oder einer der Server, von dem die Artikel erhalten werden) tritt ein relativ komplexes Einschwingverhalten auf, das sich (bei beschränktem Massenspeicherplatz) über längere Zeit hinziehen kann.
• Wegen der hohen Fluktuation und der Problematik der Fragmentierung muß ein relativ großer freier Platz dimensioniert werden (dzt. ca. 3 Gbyte).