Beitrag der IT zur Energieeinsparung. Teil 5: Umsetzung im Modell

1.1 Erprobung der Mainframe-Idee

Ein Teilszenario, die Umstellung von PC-Arbeitsstationen auf eine aus Terminalserver und der Einsatz von Thin Clients soll nachfolgend erprobt und dargelegt werden.

Der Versuch soll zeigen, ob die Nutzung von Clientgeräten zum Zugriff auf einen Terminalserver praktikabel ist, indem typische Bürotätigkeiten darauf ausgeführt werden. Diese bestehen aus verschiedenen Bestandteilen des Libre-Office-Pakets, dem E-Mail-Client Mozilla Thunderbird, den Webbrowsern Internet Explorer und Google Chrome und dem Windows-Explorer als Dateimanager. Außerdem wird das Grafikprogramm GIMP geöffnet.

Das Modell beschränkt sich nur auf den Terminalserver, andere in der Lösung geschilderte Elemente wie Mehrzwecknutzung, zentrale Datenhaltung oder Entwärmung werden nicht behandelt.

1.2 Struktur

1.2.1 Das „Mainframe“

Als Virtualisierungsumgebung dient VMware ESXi ohne vCenter, die Struktur besteht also nur aus einer Maschine. Die darauf betriebene Installation von Microsoft Windows XP muss für den Einsatz als Terminalserver-Betriebssystem modifiziert werden.

Die Maschine selbst läuft mit einem Prozessor des Typs Intel Core2Quad mit 2,63 GHz. Insgesamt sind 8 Gigabytes Arbeitsspeicher verfügbar; die genannten Ressourcen können im Modell aus noch genannt werdenden Gründen aber nicht ausgereizt werden.

1.2.2 Thin Client

Als Clients dienen ein gewöhnlicher PC und zwei eher schwächere Geräte, die stellvertretend für Thin Clients stehen sollen. Bei den zuletzt genannten handelt es sich um einen Raspberry Pi 2 sowie ein Netbook mit Intel-Atom-Prozessor, Baujahr 2007.

Der Raspberry Pi 2 ist ein Einplatinencomputer im Scheckkartenformat mit ARM-Prozessor und wird mit einem eigens dafür angepassten Betriebssystem, „Raspbian“, das auf Debian GNU/Linux basiert, betrieben. Der Prozessor läuft mit 900 MHz, als Arbeitsspeicher steht 1 Gigabyte zur Verfügung.

Der Paspberry Pi 2 hat eine Leistungsaufnahme von 4 Watt und fällt damit weit hinter die Angabe von 16 Watt für Thin Clients. Er wurde als extremes Beispiel zur Erprobung der maximalen Energieeinsparung für einen Terminalcomputer gewählt.

Das verwendete Netbook besitzt einen Atom-Prozessor vom Typ N270, der mit 1,6 GHz getaktet ist. Der klein dimensionierte L2-Cache macht den Einkernprozessor für größere Aufgaben wenig attraktiv, zur Ausführung einzelner Programme genügt er jedoch. Der Prozessor hat in Kombination mit dem vorhandenen 945GSE-Chipsatz eine Leistungsaufnahme von 8 Watt; das Gerät bezieht nach Umrüstung auf eine SSD eine gemessene Leistung von 21 Watt. Ausgehend von Alter und Ausstattung kommt es hinsichtlich seiner Leistungsfähigkeit einem Thin Client am Ende seines Lebenszyklus nahe.

1.3 Modifikation des Server-Betriebssystems

Das in ESXi betriebene Windows ist ein gewöhnliches Windows XP Professional als 32-Bit-Ausgabe. Da dieses Betriebssystem normalerweise nur eine einzelne Verbindung per Remotedesktop zulässt, wird es eigens für die modellhafte Erprobung so modifiziert, dass es vier Verbindungen erlaubt. Dies geschieht durch Abänderung von Einträgen in der Registrierungsdatenbank, sodass der in Windows laufende RDP-Server die maximale Anzahl an Clientverbindungen zulässt, die die Lizenz vorsieht – nämlich vier Stück.

Weil für den Betrieb vieler Sitzungen die Bereitstellung von möglichst viel Arbeitsspeicher sehr sinnvoll ist, wird das 32-Bit-Windows mittels Kernel-Patch so modifiziert, dass der künstlich beschränkte Adressraum oberhalb der 3-Gigabyte-Grenze nutzbar wird. Ferner wird die physikalische Adresserweiterung aktiviert, damit Speicher oberhalb der 4-Gigabyte-Grenze angesprochen werden kann. Diese Konfigurationsänderung geschieht mittels Parameter in den Starteinstellungen, der ursprünglich für die Serverfamilie von Microsoft Windows vorgesehen war. In den NT-basierten Betriebssystemen funktioniert der Parameter /PAE aber auch für das Desktopbetriebssystem.

In der Theorie werden durch diese Änderungen 4 Gigabytes Arbeitsspeicher ansprechbar; praktisch ist es aufgrund anderer Komponenten, die ebenfalls einen Teil des Adressraums belegen, etwas weniger.

image
Abbildung 8: Erweitertes Startauswahlmenü mit der neuen Option. Eigene Arbeit.

1.4 Verbindungsaufbau

Es wird die maximal mögliche Anzahl von vier Verbindungen hergestellt: An einem normalen PC, die zwei weiteren an den beiden „Thin-Client-Stellvertretern“. Die vierte Verbindung ist bereits durch das zur Beobachtung angemeldete Administrator-Konto belegt.

Unter Raspbian (auf dem Raspberry Pi 2) müssen die Verbindungseinstellungen jedes Mal eingegeben werden, beschränken sich aber auf die Adresse des Servers und gegebenenfalls die Bildschirm- und Farbeinstellungen.

image
Abbildung 9: Verbindungsherstellung unter Raspbian. Eigene Arbeit.

Unter Windows kann zur schnellen Herstellung der Verbindung eine Datei angelegt werden, in der die Verbindungseinstellungen sowie Einstellungen über Gerätefreigaben (zum Beispiel Laufwerke, aber auch Soundaus- und Eingabegeräte) vorkonfiguriert werden können. Windows speichert die Anmeldeinformationen der letzten Sitzung auf Wunsch, sodass die Verbindung schnell durch Doppelklick auf die RDP-Datei hergestellt werden kann – ohne weitere Eingaben. Die Sitzung ist also sofort geöffnet oder wiederhergestellt.

image
Abbildung 10: „Speichern unter“ legt eine Datei mit den präferierten Einstellungen ab. Durch Doppelklick hierauf wird die Sitzung ohne weitere Nachfragen gestartet. Eigene Arbeit.

Nach dem Herstellen der Verbindung verhält sich die auf den Raspberry projizierte Sitzung aber wie jede andere auch – mit der Ausnahme, dass die standardmäßig mitgelieferte RDP-Client-Software keine Sounds überträgt. Programme von anderen Anbietern, die nachträglich installiert werden können, schließen diese Lücke allerdings.

1.5 Probelauf

Unter allen Verbindungen werden mehrere Programme verschiedener Kategorien geöffnet. Als vergleichsweise ressourcenhungrig erwiesen sich die Programme der Libre-Office-Suite (hinsichtlich Arbeitsspeicher) und das Grafikprogramm GIMP (CPU-Last).

image
Abbildung 11: Durch die Terminal-Benutzer ausgelöste Prozesse. Eigene Arbeit.

Bei aktiver Bedienung von Programmen in allen vier Sitzungen spiegeln sich besonders Programmstarts oder das Öffnen von Dateien im Verlauf der CPU-Auslastung wieder. Die Auslastung des Arbeitsspeichers ist trotz der insgesamt 50 Prozesse sehr moderat.[1]

Das Betriebssystem, das ja bereits geladen ist, benötigt in Abhängigkeit von den Benutzern nur wenig zusätzliche Ressourcen. Ins Gewicht fallen besonders die von den Benutzern ausgeführten Programme. Betriebssystem-nahe Prozesse, die für jeden Benutzer individuell gestartet werden, sind lediglich der Windows-Explorer und die der Prozess winlogon.exe, der die Sitzung aufrechterhält.

Die Ausführung einiger dieser Programme wäre auf dem Netbook mit seinem langsamen Prozessor kaum praktikabel. Da die Rechenleistung aber vom Server kommt, lässt sich beispielsweise GIMP vom Netbook, gleichermaßen natürlich auch vom Raspberry Pi aus bedienen.

Ein während des Versuchs aufgetretener Verbindungsabbruch durch das sich nachts abschaltende WLAN führte in den Sitzungen nicht zu Komplikationen – sie konnten einfach wieder aufgenommen werden, der Bildschirm präsentierte sich ebenso wie die Programme unverändert.

Weiter zu Teil 6: Fazit


Einzelnachweise. Das vollständige Quellenverzeichnis kann hier heruntergeladen werden.

[1] Vgl. „Verlauf der Prozessor- und Arbeitsspeicherauslastung am Terminalserver“ im Anhang.

Dieser Beitrag wurde in Ausarbeitung veröffentlicht und getaggt , , , , , . Ein Lesezeichen auf das Permalink. setzen. Kommentieren oder einen Trackback hinterlassen: Trackback-URL.

Einen Kommentar hinterlassen

Sie müssen angemeldet sein, um zu kommentieren.