Ende Oktober hatten wir einen ausführlichen Artikel veröffentlicht, der zeigt, wie man mit geringem finanziellen Aufwand auf Basis von ausgesuchten Desktop-Komponenten mit Hilfe des Betriebssystems OpenSolaris einen möglichst schlagkräftigen Home-Server bauen kann, der nicht nur Datei-Freigaben für verschiedene Benutzer beherrscht, sondern sogar virtuelle PCs mit Hilfe von VirtualBox bereitstellen kann.
Kurz nach der Veröffentlichung des Artikels und einer für ausreichend befundenen Testphase mit zahlreichen Stabilitätstests (hauptsächlich für CPU, RAM und Storage-Subsystem) wurde der Server seinem Bestimmungszweck zugeführt. Leider gab es schon kurz darauf die ersten Probleme: beim Kopieren von großen Datenmengen (100 GB oder mehr) in einem Rutsch brach - nicht 1:1 reproduzierbar, aber immer mal wieder - der Kopiervorgang mit unerklärlichen Fehlerrmeldungen ab. Mal soll der Pfadname zu lang gewesen sein, mal sei die Netzwerkressource nicht mehr erreichbar. Letztendlich waren das aber nur Erklärungsversuche der Windows-Clients "ins Blaue hinein". Zuerst hatte wir ein Problem mit dem Sun-eigenen SMB-Server in Verdacht und probierten den aus der Linux-Welt bekannten Samba. Ohne Unterschied.
Tatsächlich gönnte sich zwischendurch der rge-Treiber von OpenSolaris immer wieder ein Nickerchen, denn auch vom Server aus konnte man keine Netzwerk-Komponente mehr erreichen. Wenn man ein paar Minuten wartete oder den Server einfach neu startete, war wieder alles ok; bis zum nächsten Abbruch bei hoher Last.
Für unseren Home-Server hatten wir das ASUS M3A76-CM Mainboard gewählt, das als NIC einen Wald- und Wiesen-Chip von Realtek, den RTL8111C in der PCI-Express Variante mit 1 GBit/s Transferrate trägt. Zwar waren wir während der Recherche für das Projekt "Home-Server" auf zahlreiche Probleme von Solaris mit den Realtek Gigabit-Chips gestoßen, doch datierten die alle auf Anfang 2008, während wir die OpenSolaris-Version 2009.06 einsetzten. Da das Netzwerk sofort out-of-the-box funktionierte, wähnten wir das Problem als nicht mehr existent.
Nun, offenbar waren wir da zu voreilig und wie schon das Solaris-Abenteuer mit unserem Webserver damals gezeigt hat, offenbart oft erst praxisbezogene Dauerlast eventuelle Schwächen. Mit dem Realtek-Problem sind wir nicht alleine. Wer sich die Mühe macht ein paar Stunden die einschlägigen Foren zu lesen (u.a. bug ID 6807184), stößt auf unzählige Beiträge, in denen dieses Problem geschildert wird, auch auf Lösungsvorschläge und leider auch auf die Quintessenz, dass keiner der Workarounds rundum zufriedenstellend ist. Aber der Reihe nach.
Die Ursache für das Problem liegt wohl irgendwo in der Hardware-Routine für die Checksummen-Prüfung. Bei vielen Usern - darunter auch bei uns - waren die Verbindungsabbrüche vorbei, wenn man die Checksummen-Kontrolle nicht dem Netzwerk-Chip, sondern der CPU aufbürdet. Dazu öffnet man als "su" die Datei /etc/system und fügt am Ende der Datei die Zeile
set ip:dohwcksum = 0
hinzu. Dann Reboot und das Problem sollte behoben sein. Leider jedoch ging dieser Fix bei uns auch mit einer eklatant niedrigeren Transferrate einher. Während große Dateien vorher (bis zum Abbruch) mit etwa 80 MB/s auf den Server geschoben werden konnten, schlich das System nun mit 20 MB/s dahin. Das ist nicht akzeptabel.
Als nächstes probierten wir sämtliche Patches für den rge-Treiber, die in diesem Thread veröffentlicht wurden. Da das Problem von Haus aus unregelmäßig und nur unter extremer Netzwerk-Last auftrat, ist es unmöglich zu sagen, ob einer davon das Problem gelindert hat. Behoben hat es leider keiner.
Als nächstes wurden wir auf ein Netzwerk-Projekt für Solaris aufmerksam, das von einem gewissen Masayuki Murayama betrieben wird. Es handelt sich dabei um eine Sammlung freier Netzwerk-Treiber für Solaris, die offenbar ihren Ursprung in der BSD-Welt haben. Allerdings klagten einige Foren-User dabei über komplette Systemabstürze in Form von kernel panics (vergleichbar einem Bluescreen unter Windows). Transferrate gegen Stabilität? Ein schlechter Tausch bei einem Server.
Nach nun zwei Wochen lesen und probieren müssen wir zu dem Schluss kommen - und damit die Ratschläge des Großteils der Postings aus der OpenSolaris-Szene wiederholen - von den Realtek-Gigabit-Netzwerk-Chips die Finger zu lassen, wenn Solaris zum Einsatz kommen soll. Es ist unverständlich, wieso es offenbar seit fast zwei Jahren nicht möglich ist, die Probleme mit einer kompletten NIC-Familie in den Griff zu bekommen (betrifft wohl auch 8168), die millionenfach weltweit im Einsatz ist und unter anderen Betriebssystemen fehlerfrei arbeitet. Das Problem ist im übrigen nicht Hersteller spezifisch, denn eine uralte Realtek RTL-8139 Fast-Ethernet PCI-Karte arbeitet als zweite NIC (für ein separates Teilnetz via WLAN) in unserem Home-Server völlig problemlos.
Im Zweifel wurde von der OpenSolaris-Community immer wieder eine Intel PCI-Express Karte empfohlen. In der Praxis wird es wohl auch jede andere Netzwerkkarte tun, die mit einem Chip bestückt ist, der auf der offiziellen Kompatibilitätsliste von OpenSolaris steht.
Dieses Problem zeigt, in welche Fallen man laufen kann bei einem verglichen mit der Linux-Welt oder gar dem Windows-Imperium vergleichsweise kleinen Nischenprodukt wie OpenSolaris. Selbst das inoffizielle Prädikat "Massenware" (sprich: "dafür MUSS es doch was geben") ist kein Garant dafür, dass es dafür auch in exotischen Betriebssystem-Welten wie Solaris brauchbaren Treibersupport gibt. Von Realtek selbst kommt nichts, ergo hängt der Support an freiwilligen Programmierern, die meist via Reverse-Engineering oder gar Trial-and-Error oder über irgendwelche irgendwo ergatterte, teils veraltete Unterlagen versuchen Treiber zu programmieren. So uneigennützig und bewundernswert so ein Community-basierendes Open-Source Projekt ist, so frustrierend kann es für den Endanwender sein, wenn es eigentlich funktioniert, aber unter kritischen Bedingungen dann eben doch nicht.
Wir für unseren Teil haben uns nun eine eben solche hochgelobte Intel Netzwerk-Karte bestellt und werden prüfen, ob das Problem damit wie versprochen aus der Welt ist. Falls ja, werden wir den Artikel entsprechend aktualisieren.
Diesen Artikel bookmarken oder senden an ...
