Server-based Computing mit Linux

Server basierende Lösungen bieten sich aus mehreren Gründen als attraktive Alternative oder Ergänzung zur traditionellen Client/Server-Architekturen. Endgeräte und Standorte können frei gewählt werden und der Aufwand für die Verwaltung reduziert sich, womit die Kosten für die IT-Infrastruktur sinken.
Ist Linux eine Alternative für Server-based Computing? Unterstützt Linux die notwendigen Protokolle, um als Thin Client zu fungieren für TSE/Metaframe-Lösungen? Sind Linux-Server robust genug? Bieten sie die notwendige Redundanz und Failover-Technologie, so dass Server-Applikationen auf Linux laufen können?

Netzwerkfähig von Anfang an

Die notwendige Technologie, um Applikationen auf einem Server laufen zu lassen, ist seit 15 Jahren Bestandteil von Unix, und wurde von Linux übernommen. Das X-Window-System ist vom Grunddesign her netzwerkfähig. Linux ist ebenfalls als Multi-User-Betriebssystem konzipiert. Das heisst, Linux-Applikationen können ohne Modifikation entweder auf einem Client oder auf dem Server im Netzwerk-Betrieb laufen.
Die offene und freie Natur von Linux erlaubte diversen Herstellern, Linux basierende Thin-Clients zu entwickeln, welche keine Hard-Disk brauchen und wenig bis keine lokale Konfiguration nötig machen. Die gängigen Protokolle, z.B. ICA, Telnet und andere Terminal Emulatoren wie natürlich auch HTML-Browsing werden direkt unterstützt. Die Einkaufspreise für solche Clients können sehr attraktiv sein.

Reife Server-Technologie

Mittlerweile ist Linux eine erprobte und akzeptierte Server-Lösung. Alle notwendigen Basisdienste werden bei einer Linux-Distribution mitgeliefert oder können vom Internet heruntergeladen werden, z.B. File- und Druckdienste, E-Mail, Web-Server, Proxy-Server, Name-Server, Office und Groupware, Datensicherung, Firewall, Fernzugang, automatisierte Installation, System- und Netzwerküberwachung und Applikationsverteilung.
In letzer Zeit haben sich einige Clustering-Lösungen bewährt, die sich für den Einsatz in skalierbaren, fehlertoleranten Umgebungen eignen. Dazu sind zwei Komponenten notwendig: Failover und Loadbalancing.
Bei Failover handelt es sich um mindestens zwei reale Server, jeweils mit einer IP-Adresse, die sonst identisch aufgesetzt sind. Eine letzte IP-Addresse wird verwendet, um die Dienste anzusprechen. Der Master bietet im Normalfall die gewünschten Dienste an. Die anderen Server testen in regelmässigen Intervallen, ob der Master noch zur Verfügung steht.
Setzt der Master aus, übernimmt ein anderer realer Server diese letzte Adresse und bietet die Dienste an, bis der urspüngliche Master-Server wieder einsatzbereit ist. Diese Topologie stellt einen hochverfügbaren Service mit minimaler Hardware-Anforderungen zur Verfügung.
Mit Loadbalancing wird die Performance des Gesamtsystems erhöht und gleichzeitig noch Hardware-Redundanz erzeugt. In dieser Topologie wird vor den realen Servern ein sogenannten Direktor konfiguriert. Dieser leitet eingehende Anfragen an den realen Server weiter, welcher am meisten Resourcen frei hat. Der Direktor kann selber mit Failover ausgestattet werden, um die Zuverlässigkeit noch zu verbessern.
Unter Linux gibt es schon produktionsreife Lösungen z.B. Heartbeat, Mosix und LVS, die Hochverfügbarkeitslösung von Red Hat.

Thin Client mit Potential

Der Hauptnachteil von Thin-Client-Lösungen ist die Skalierbarkeit. Die Vorteile der Client/Server-Architecktur, dass jeder Benutzer dedizierte Resourcen bekommt, gehen verloren, der Server wird zum Flaschenhals.
Wenn der Betrieb des PC so einfach wie ein Thin Client wäre, hätte man das Beste beider Welten. SFI-Rabbit, die Rapid-Deployment-Lösung für Linux, bietet genau diese Möglichkeit an. Die Umgebung lässt sich vollautomatisch aufsetzen und genau den Kundenbedürfnissen anpassen.
SFI-Rabbit basiert auf Werkzeugen und Konzepten, die ursprünglich beim Institut für Virenkrankheiten und Immunprophylaxe (IVI) nach dem Konzept «Thin Client mit Potential» eingesetzt wurden. «Thin Client», weil die Clients einfach zu verwalten sind und weil Applikationen Server-basierend laufen können. «Mit Potential», weil die Möglichkeit, die lokale Resourcen effektiv auszunutzen, vorhanden blieb.
Ein Benutzer erhält zum Beispiel ein E-Mail mit einem MS-Word Dokument als Attachment. Bei IVI läuft Netscape zwar lokal, wird aber auf das Word-Dokument geklickt, so wird Microsoft Word auf einem Metaframe-Server gestartet. Beim Pilotkunden von SFI-Rabbit, der Rimuss Kellerei Rahm in Hallau, wird Staroffice lokal gestartet. Der Benutzer merkt nicht einmal, wo seine Programme laufen!

Partner gesucht

Heute eignet sich SFI Rabbit für Installationen von Zehn bis zu Hunderten von Clients. Dank dem Einsatz von proprietären Erweiterungen zu Linux bietet sich die Möglichkeit Geld zu verdienen, nicht nur mit Dienstleistungen und Support, sondern auch mit Produktverkauf. SFI sucht Kontakt mit Partnern, die sich als VAR oder Systemintegrator für den Verkauf von SFI-Rabbit-Lösungen interessieren.