Man erinnert sich vielleicht aus den vorherigen Folgen, dass ein Netzwerkausfall keine vergnügliche Sache ist. Nicht nur ist der Server daraufhin nutzlos. Sondern dem Admin bleibt nichts anderes übrig, als ins Rechenzentrum oder zum Provider zu fahren, den Rechner hart abstürzen zu lassen und es erneut zu versuchen. Denn eine Fernwartung ist ja nicht mehr möglich.

Unsere Versuche dazu waren öffentlich. Mancher Leser wird sich erinnern, dass wir immer wieder in diversen Foren dazu aufgerufen haben, einen Teststream abzurufen, um zu diesem Zeitpunkt einen möglichst hohen Traffic zu erzeugen. Aber stets gab der Server nach wenigen Minuten auf, obwohl nie mehr als 20 bis 30 Streams gleichzeitig zu bewältigen waren. Für einen Server wie den Xserve ist das kein nennenswerter Traffic. Umso schlimmer und mysteriöser sind die Ausfälle. Aber nicht nur der Streaming-Server quittierte den Dienst, sondern das gesamte System gab den Geist auf und war nicht mehr ansprechbar. Das wirft kein gutes Licht auf einen UNIX-Server.

Aber wir haben den Fehler gefunden, oder genauer, ein UNIX-Freak aus dem Rechenzentrum ist auf den richtigen Dreh gekommen. Der Fehler liegt in einer falschen Konfiguration der Ethernet-Ports und es dürfte selbst für erfahrene Mac-Admins unmöglich sein, dem auf die Spur zu kommen. Die Lösung scheint auch bei anderen Käufern zu funktionieren, jedenfalls haben mir das einige Hilfesuchende aus Apples Support-Forum geschrieben. Ich möchte noch mal betonen, dass es hier um einen Fehler geht, der bei praktisch allen Providern auftreten wird, die ihre Router auf maximale Performance auslegen (und wer täte das nicht). Ueberall dort kann man den Xserve vergessen. Nach kurzer Zeit kappt er die Verbindung.

Weiter »

Die Kapitel des Beitrags:

• Xserve-Test (Teil 5)

• Netzwerk adieu!

• Der Fehler und die Lösung  (hier geht's weiter)

• Alles ganz einfach

• Was lehrt uns dieses Gleichnis?