Einrichtung eines EDV-Labors für Bauingenieure
Christian Schranz, Institut für Hochbau und Technologie
Klaus Egler, Paul
Torzicky
Die Fakultät für Bauingenieurwesen hat sich entschieden, ein zentrales
EDV-Labor einzurichten. Diese Einrichtung gab es bis dato noch nicht. Es
soll den Studierenden und Lehrenden im Bereich Bauingenieurwesen Arbeitsplatzrechner
mit fachspezifischer Software anbieten. Das EDV-Labor soll für Lehrveranstaltungen,
Übungen sowie Seminare mit/von Fremdfirmen eingesetzt werden.
Zwei Kriterien waren bei der Planung maßgebend: Einerseits soll sich die
Verwaltung aller Arbeitsplätze möglichst einfach gestalten. Andererseits
hat die Hardwarestruktur des EDV-Labors den Anforderungen der Benutzersoftware
zu genügen. Zu dieser zählt neben dem üblichen Office-Paket und mathematischen
Softwareprodukten, wie Wolfram Mathematica und Matlab, vor allem bauingenieurspezifische
Software. Einige Beispiele seien angeführt:
-
CAD-Programme: Nemetschek Allplan, Autocad, Archicad
-
Statikprogramme: SCIA ESA.PT, Stratos, Dlubal Rstab, Dlubal RFEM, IQ100
-
Bauphysikprogramme: Heat 3D, Therm, Wufi, Bastian, CATT
-
Grundbauprogramme: DC Software, Plaxis
-
Baubetriebsprogramme: Auer, ABK, Doka Tipos
Aufgrund der Benutzersoftware ist die Verwendung von MS Windows XP als
Betriebssystem erforderlich.
Struktur des EDV-Labors
Während der Planung des EDV-Labors gab es Gespräche mit dem ZID über dessen
Erfahrungen zu vorhandenen Systemen. Die Entscheidung fiel auf eine Server-Client-
Lösung der Firma Ardence,
Ardence Desktop Edition (s.
http://www.ardence.com/enterprise/products.aspx?ID=83#), mit der einer der Autoren schon positive Erfahrungen in einem
der ZID-Internet-Räume hat.
Dabei booten von einem entsprechend leistungsstarken Server alle Clients.
Diese Lösung vereinfacht nicht nur den Installationsprozess sondern auch
den Software-Update sowie die Neuinstallation von zusätzlicher Software.
Diese Software zeichnet sich durch verschiedene Image-Modi aus, deren zwei
normalerweise zum Einsatz kommen: Shared-Image Mode und Private-Image Mode.
Im Shared-Image Mode, auch als Virtual Disk Mode bezeichnet, können alle
Arbeitsplatzrechner von diesem Image booten. Ardence Desktop Edition verwendet
eindeutige Merkmale der Arbeitsplatzrechner für die Lizenzverwaltung (normalerweise
mac-Adressen). Dadurch scheint jeder Arbeitsplatzrechner wie ein spezifischer
Rechner auf, läuft aber nur von einem Image.
Im Private-Image Mode hat ein Arbeitsplatzrechner die Schreibberechtigung
für das Image. Es kann dann natürlich nur ein Arbeitsplatzrechner mit diesem
Image gebootet werden. Dieser Mode dient zur Veränderung des Images, z.B.
für Betriebssystemupdates oder Softwareinstallationen.
Damit auf dem Server nur ein Arbeitsplatz-Image eingerichtet werden muss
und somit die Verwaltung vereinfacht wird, müssen alle Arbeitsplatzrechner
komplett gleich ausgestattet sein. Im EDV-Labor kommen daher 25 HP DC7600
(2,8 GHz und 1,0 GB RAM) zum Einsatz. Die eingebaute Festplatte ist deaktiviert,
da sie für den Normalbetrieb eigentlich nicht erforderlich ist. Die Userdaten
der Studenten werden auf den Studentenservern stud3.tuwien.ac.at und stud4.tuwien.ac.at
unter den jeweiligen Studentenaccounts gespeichert. Dazu wird die Verbindung
zu diesen Studentenservern via smb aufgebaut. Somit haben die Studenten
alle ihre Daten zentral gespeichert und müssen sich nicht auf zusätzlichen
Servern einloggen.
Damit die Leistungsfähigkeit im Netzwerk gegeben ist, wurde ein eigener
Gbit-Switch angeschafft. Die Arbeitsplatzrechner sind mit Gbit-Verbindung
an den Server angeschlossen.
Der eingesetzte Server muss entsprechend leistungsfähig sein. Es wird ein
HP DL360 mit zwei Xeon-Prozessoren (3,0 GHz und 2,0 GB RAM) eingesetzt.
Auf Redundanz wird besonders Wert gelegt. Daher sind zwei 72 GB Festplatten
als gespiegelte Platten eingesetzt, das Netzgerät sowie die Kühler sind
ebenfalls in doppelter Ausführung vorhanden. Als Betriebssystem wird Windows 2003 Server eingesetzt.
Der Server ist in diesem System ein single point of failure. Daher müssen
"Notfall-Szenarien" für einen Serverausfall geplant werden.
Von besonderer Wichtigkeit ist dabei die gewählte Backup-Strategie unter
der Prämisse einer möglichst hohen Verfügbarkeit des Systems. Nicht alle
beschriebenen Backup-Strategien konnten komplett durchgetestet werden,
da einerseits die entsprechende Hardware zum gegebenen Zeitpunkt noch nicht
zur Verfügung stand bzw. die hohe Auslastung des EDV-Labors die notwendigen
Testzeiten nicht gestattet. Dies wird in der vorlesungsfreien Zeit nachgeholt.

Das EDV-Labor für Bauingenieure
Im beschriebenen Labor wird in regelmäßigen Intervallen eine Sicherung
des Gesamtsystems vorgenommen. Dazu wird ein Ghost-Image der Festplatte
des Servers auf einem ZID-Server abgelegt. Bei einem Test im EDV-Labor
dauerte sowohl das Backup aber vor allem das Recovery mindestens drei Stunden,
weshalb diese Strategie für absolute Notfallszenarien ungeeignet ist. Sie
kommt daher nur für Archivzwecke zur Anwendung.
Alternativ bietet sich die Anschaffung von Ersatzplatten der gespiegelten
Platten an. Auf die Ersatzplatten wird regelmäßig über den Raidmechanismus
der aktuelle Datenbestand gespeichert. Im Falle eines Datenverlustes auf
den Orginalplatten kann der Betrieb durch einen Tausch der Platten sofort
wieder aufgenommen werden.
Um für einen Totalausfall des Servers gewappnet zu sein, steht einer der
Arbeitsplatzrechner als Ersatzserver zur Verfügung, der immer eine aktuelle
Version des Datenbestandes des Servers enthält. Ein Arbeitsplatzrechner
als Ersatzserver muss wegen der eingeschränkten Leis- tungsfähigkeit als
Notlösung betrachtet werden. Die Anschaffung eines gleichwertigen Ersatzservers
erscheint sinnvoll.
Eine weitere Möglichkeit bei einem Totalausfall des Servers wird durch
Ardence Desktop Edition geboten. Dabei kopiert man die Images regelmäßig
auf die lokale Festplatte der Arbeitsplatzrechner. Bei einem Totalausfall
des Servers müssen nur die lokalen Festplatten der Arbeitsplatzrechner
aktiviert werden. Einige Softwarepakete benötigen jedoch den Server als
Lizenzserver. Während dieses absoluten Notbetriebes stehen diese Softwarepakete
nicht zur Verfügung.
Es muss nicht gesondert darauf hingewiesen werden, dass die verwendeten
Images immer auf aktuellem Stand gehalten werden müssen.
Aufbau und Installation
Die Aufbau- und Installationsarbeiten erfolgten in mehreren Schritten unter
tatkräftiger Unterstützung mehrerer ZID-Mitarbeiter.
Schritt 1: Installation eines Arbeitsplatzes
Als Betriebssystem wurde auf diesem Arbeitsplatz MS Windows XP installiert.
Dies ist notwendig, da bauingenieurspezifische Software fast gänzlich dieses
Betriebssystem erfordert. Soweit schon bekannt wurde die Benutzersoftware
installiert. Für die Validierung der Studentenaccounts wurde ein eigener
Validierungsmodul des ZID installiert. Dies wird weiter unten noch genauer
beschrieben. Die Studentenaccounts sind hiebei derzeit nur als Standardaccounts
verfügbar. Vereinzelte Software-Pakete (wie Nemetschek Allplan) erfordern
jedoch Hauptbenutzer-Rechte für die Benutzer. Daher wurden einige generelle
Accounts eingerichtet, unter anderem einer mit Hauptbenutzer-Rechten. Danach
wurden auch alle aktuellen Treiber und Patches sowie die Ardence Client
Software installiert.
Schritt 2: Server einrichten
Als Betriebssystem wurde MS Windows 2003 Server verwendet. Für einige Softwarepakete
waren noch einzelne Lizenzserver notwendig. Das Hauptaugenmerk galt aber
der Installation der Distributionssoftware Ardence Desktop Edition.
Die Software Ardence Desktop Edition beinhaltet auch einen dhcp-Server
sowie einen boot-PXE-Server für die Arbeitsplatzrechner. In der entsprechenden
Konfigurationsdatei des dhcp-Servers wurden die mac-Adressen aller Rechner
eingetragen und mit fixen IP-Adressen belegt. Somit kann jeder Rechner
mittels seiner IP-Adresse identifiziert werden.
Schritt 3: Image erzeugen
Im dritten Schritt wurde das Image des bereits installierten Arbeitsplatzrechners
am Server erzeugt. Für die Arbeitsplatzrechner musste eine Image-Größe
festgelegt werden; diese beinhaltet das zu installierende Betriebssystem,
die Benutzersoftware sowie eventuelle Benutzerdaten. Danach wurde eine
Virtuelle Disk erzeugt; ein Schritt, der längere Zeit beanspruchte. Die
Virtuelle Disk wurde dann am Server gemountet und formatiert. Auch hier
sollte man eine längere Zeitdauer einplanen. Während dieses Schrittes durften
keine USB-Dongles angesteckt sein, da diese denselben Laufwerksbuchstaben
wie die Virtuelle Disk beanspruchten. Ein Formatieren hätte dann den Dongle
beschädigen können. Die Virtuelle Disk musste dann den zuerst installierten
und in der dhcp- Konfigurationsdatei definierten Arbeitsplatzrechnern zugeordnet
werden. Die Virtuelle Disk wurde danach in Ardence Desktop Edition auf
Harddisk First umgestellt.
Der Arbeitsplatzrechner musste nun auf Remote Boot umgestellt werden. Danach
konnte das Image des Arbeitsplatzrechners mittels Ardence Desktop Edition
auf die Virtuelle Disk geschrieben werden.
Schritt 4: Aktivierung des Images für alle Arbeitsplatzrechner
Im vierten Schritt wurde der Arbeitsplatzrechner in Ardence Desktop Edition
von Harddisk First auf Virtual Disk umgestellt, und danach das Image von
Private-Image Mode auf Shared-Image Mode. Somit war das Image für alle
Arbeitsplatzrechner verfügbar. Danach konnten alle Rechner gestartet werden.
User-Validierung über TU-Passwort
Das Programm Gina von XPA-Systems (http://pgina. xpasystems.com/) kommt
zum Einsatz. Beim Login des Benutzers werden nacheinander die Studentenserver
stud3.tuwien.ac.at und stud4.tuwien.ac.at abgefragt. Falls auf einem der
beiden Server ein erfolgreiches Login möglich ist, wird die Nutzung des
Rechners gestattet. Secure Pop oder SFTP können dabei als Validierungsprotokoll
verwendet werden. Alle Studierenden mit gültigem Studentenaccount können
somit validiert werden, ohne eigene Accounts im EDV-Labor anlegen zu müssen.
Dieser Validierungs- und Authentifizierungsablauf ist derzeit noch in Diskussion
und kann sich noch ändern.
Eine direkte Beschränkung auf eine Studienrichtung ist noch nicht möglich.
Es wird aber daran gearbeitet, dies zu ändern. Eine diskutierte Möglichkeit
beinhaltet den Gruppenmodus im TUWIS++. Bei dieser Möglichkeit muss eine
Gruppe eingerichtet werden, deren darin angemeldete Studenten dann bestätigt
werden müssen. Nach dieser Bestätigung sollten diese Studentenaccounts
vom ZID als zulässige für die Validierung verwendet werden. Dies böte die
Möglichkeit, noch vor Anmeldungsbeginn diverse Vorbedingungen zu verlangen,
die dann automatisch kontrolliert werden sollten. Dies entspricht in etwa
der TU Wien E-Learning Authentifizierung (tuwel.tuwien.ac.at). Diese Möglichkeit
ist jedoch erst in Diskussion und kann so leider noch nicht eingesetzt
werden.
Erfahrungen und Probleme
Ein nunmehr schon dreimonatiger Betrieb verläuft zur vollsten Zufriedenheit.
Es sind keine systembedingten Probleme aufgetreten. Besonders die Wartung
stellte sich als besonders einfach dar.
Während dieser Zeit wurde schon mehrmals zusätzliche Software installiert.
Dabei müssen alle Rechner ausgeschaltet werden. Danach wird das Image
auf Private-Image Mode umgestellt. Nun kann ein Rechner wieder im Private-Image
Mode gestartet werden. Dieser greift nun schreibberechtigt auf das Image
am Server zu. Nachdem die Software installiert, eingerichtet und getestet
ist, wird der Rechner wieder heruntergefahren. Das Image kann wieder in
den Shared-Image Mode umgestellt werden. Die Software ist nun nach einem
Neustart auf allen Rechnern verfügbar. Dieser Vorgang bewegt sich im Minuten-Bereich.
Im Folgenden sind einige Probleme, die während des Betriebes auftraten,
aufgelistet. Diese sind jedoch rein logistischer Natur, und hätten schon
im Vorhinein verhindert werden können. Die Auflistung dient hier daher
dem Erfahrungsaustausch.
-
Startreihenfolge dhcp-Server sowie boot-PXE Server:
Der dhcp-Server muss
vor dem boot-PXE Server gestartet werden. Einmal trat der Fall auf, dass
der boot-PXE Server vor dem dhcp-Server gestartet wurde; der dhcp-Server
konnte nicht gestartet werden. Nachdem alle Rechner ihre IP-Adressen erst
über den dhcp-Server erhalten, konnte kein Rechner gebootet werden. Ein
manuelles Deaktivieren des boot-PXE Servers sowie manuelles Starten beider
Server in richtiger Reihenfolge löste das Problem, welches seit damals
nicht wieder auftrat.
-
IP-Adressenkonflikt:
Um eine Software zu installieren, wird das Image auf
Private-Image Mode umgestellt. Danach bootet ein Arbeitsplatzrechner mit
diesem Image. Dieser Arbeitsplatz- rechner erhält vom dhcp-Server eine
- seiner mac-Adresse zugeordnete - IP-Adresse. Im EDV-Labor beträgt die
voreingestellte dhcp-Lease-time zehn Minuten (dies kann natürlich verändert
werden). Wird nun der Rechner hinuntergefahren, das Image wieder auf Shared-Image
Mode umgestellt und ein anderer Rechner zuerst neu gestartet, erhält dieser
zwar während des boot-Prozesses seine - der mac-Adresse zugeordnete - IP-Adresse.
Nach dem Starten von MS Windows XP hat das Betriebssystem noch die während
der Installation erhaltene IP- Adresse. Bei Neustart aller Arbeitsplatzrechner
führt dies zu einem IP-Adressenkonflikt. Dies kann leicht umgangen werden,
indem man die als dhcp-Leasetime eingestellte Zeitdauer abwartet und erst
danach alle Arbeitsplatzrechner startet. Andererseits erhalten die Arbeitsplatzrechner
nach einmaligem Verstreichen der dhcp-Leasetime sowieso ihre entsprechende
IP-Adresse.
-
Lizenzserver der Firma Nemetschek:
Bei diesem Lizenzierungsverfahren wird
am Arbeitsplatzrechner eingestellt, wo sich der Lizenzserver befindet.
Leider wird dabei auch der Name des Arbeitsplatzrechners festgehalten.
Somit ist der im Image gespeicherte Name jener des Arbeitsplatzrechners,
an dem das Image modifiziert wurde. Da jeder Arbeitsplatzrechner einen
anderen Rechnernamen hat, muss die Lizenzserverinformation an jedem Rechner
nach jedem Neustart nochmals eingestellt werden. Dies kann jedoch von jedem
Benutzer des Programms, der gleichzeitig Hauptbenutzer-Rechte besitzt,
erledigt werden. Derzeit wird noch angedacht, diesen Vorgang durch Verwendung
von scripts zu automatisieren.
Zusammenfassung
Der Betrieb des EDV-Labors läuft zur absoluten Zufriedenheit. Alle bis
jetzt aufgetretenen Probleme waren rein logistischer Natur, welche im Voraus
hätten verhindert werden können. Da es sich dabei noch dazu nur um Kleinigkeiten
handelte, konnten diese auch rasch beseitigt werden. Im laufenden Betrieb
traten wie erwartet keinerlei systembedingte Probleme auf.
Das geplante und hier eingesetzte Konzept hat sich als absolut passend
für EDV-Labors erwiesen. Die Vorteile seien hier nochmals aufgelistet:
-
einfache Wartungsarbeiten,
-
rasche und einfache Softwareinstallation an den Arbeitsplatzrechnern,
-
Konzentration rein auf die Serverwartung.