Debeka favorisiert Linux-Clients

26.03.2002
Von 
Ludger Schmitz ist freiberuflicher IT-Journalist in Kelheim. Er ist spezialisiert auf Open Source und neue Open-Initiativen.

Der langjährige Unix-Kenner, der seit einigen Jahren die Entwicklung von Linux verfolgt hatte, fragte bei Red Hat und Suse nach einem Konzept. Er bekam eins vom Nürnberger Linux-Softwarehaus. Zwar war das kein fertiges Produkt, aber „ein völlig klares Konzept“, so Meyer. „Und das beste Argument war, dass Suse das prinzipielle Funktionieren auf einem Notebook vorführen konnte.“

Dadurch ermutigt, ließen sich IT-Leitung und Geschäftsführung des Versicherungskonzerns, in dem es bis dato nur Microsoft-basierende PCs gegeben hatte, auf das Linux-Experiment ein. Im April 2001 ging es los. Das Projekt war jederzeit im Plan. „Wir haben innovativ etwas gewagt“, so Meyer, „aber wir haben keine schlaflosen Nächte bekommen.“

Inzwischen ist das Projekt fast abgeschlossen. In den Geschäftsstellen stehen neue Pentium-III-PCs, mit Festplatten, aber ohne CD- oder Diskettenlaufwerke. Auf den Geräten läuft ein nicht modifiziertes Suse Linux 7.2 mit dem Kernel 2.4, das aber auf die Applikationen der Distribution verzichtet. „Am Quellcode haben wir nichts geändert“, erklärt der stellvertretende Projektleiter Michael Kulisch. „Das hätte bei neuen Versionen nur Arbeit gemacht.“

Auf den Smart Clients läuft lediglich ein Browser und eine mit Java selbst geschriebene Anwendung. Diese ist eigentlich kaum mehr als eine Terminal-Emulation. Hinzu kommen einige selbst geschriebene Debeka-Anwendungen, die von Web-Servern in Koblenz vorgehalten werden. Außerdem gibt es auf den PCs noch eine ICA-Client-Software von Citrix, um das einzige Windows-Programm, „Easy 2000“, verwenden zu können. Alle Daten liegen auf einem Bull-Mainframe in Koblenz. Für die Anbindung der Geschäftsstellen wurde pro zehn Mitarbeiter eine Bandbreite von 64 Kilobit/s kalkuliert.

Der eigentliche Clou aber ist das dahinter verborgene Administrationskonzept. „Wir verteilen keine Software, sondern synchronisieren Systeme“, fasst Kulisch zusammen. Und das funktioniert so: Wenn an einer Applikation Änderungen notwendig sind, werden die zunächst in Koblenz auf einem Referenzrechner, der baugleich mit den Clients in den Geschäftsstellen ist, ausgeführt und getestet. Danach werden die Änderungen mit einem Image-Server in der Zentrale synchronisiert. Dazu verwendet man den „Rsync“-Dienst, der nur die neuen Informationen kopiert und komprimiert überträgt.

In der folgenden Nacht klopft der Image-Server bei den Rechnern in den Geschäftsstellen an. Hier gibt es keinen lokalen Haupt- oder LAN-Server, sondern der erste aus dem Stand-by-Modus aufgeweckte lokale Rechner wird mit dem Image-Server synchronisiert. Danach nimmt er automatisch einen Neustart vor und synchronisiert sich nun mit allen Clients in seiner Nachbarschaft. Falls irgendein Fehler auftritt, beginnt der Vorgang, diesmal mit einem anderen Client in der Geschäftsstelle, von vorne.