Betriebsanleitung für den virtuellen Compute-Provider im C3Grid

Transkript

1 C3Grid INAD: towards an INfrastructure for general Access to climate Data Betriebsanleitung für den virtuellen Compute-Provider im C3Grid Author(s): Partner(s): Lead Partner: Work Package: AP Version Identifier: 1.0 Date: V. Winkelmann, F. Schneider, J. Wahnes Universität zu Köln, TU Dortmund, AWI Universität zu Köln

2 Inhaltsverzeichnis Betriebsanleitung für den virtuellen Compute-Provider Motivation VM-Layout und Requirements Download des Compute-Providers Installation des Compute-Providers unter VMware ESXi VMware Workstation und VMware Player Installation des Compute-Providers unter VirtualBox Inbetriebnahme des virtuellen Compute-Providers Vorarbeiten Konfiguration Zusätzlicher Grid-Dienst GSISSH Test der Grid-Funktionalität Test-Beispiel für WS-GRAM Test-Beispiel für Fork Test-Beispiel für den File-Transfer per GridFTP Test des MDS Test des GSISSH-Servers Layout des Compute-Providers OS Plattenaufteilung Module-Environment Automatische Dienste Eingerichtete User und Einrichtung neuer User Initialisierung des Globus-Client Erweiterung des virtuellen Compute-Providers Höhertaktung der CPU, mehr CPUs, Vergrößerung des Hauptspeichers Vergrößerung des Plattenplatzes im DMS Workspace und Scratch Anbindung des Compute-Providers an ein separates Compute-Cluster Nutzung der installierten Workflows Standalone Tests installierter Workflows Portal-Tests der installierten Workflows Neue Workflows Betriebsanleitung für den virtuellen Compute-Provider Seite 2

3 Betriebsanleitung für den virtuellen Compute-Provider im C3Grid 1 Motivation Die Universität zu Köln hat auf Basis von VMWare-Workstation als Template eine virtuelle Maschine entwickelt, die im C3-Grid als Prototyp eines C3-Compute-Providers eingesetzt werden kann. Wegen der typischerweise begrenzten Ressourcen einer virtuellen Maschine im RZ-Umfeld ist dieses Gastsystem eher für den Testbetrieb ausgelegt, und weniger für Produktionsbetrieb. Der Grund, eine solche Maschine dennoch zu konzipieren, liegt in der Tatsache, dass im C3Grid Compute-Ressourcen mit größeren Compute-Clustern eingesetzt werden, die wegen des Mehrnutzerbetriebes nicht ohne größere Vorlaufzeit umkonfiguriert und Änderungen am Betriebssystem häufig nur nach Abschaltung des Batchsystems durchgeführt werden können, was immer eine deutliche Beeinträchtigung des regulären Nutzerbetriebs nach sich zieht und mehrere Wochen dauern kann, um laufende Batchjobs bspw. nicht abrechen zu müssen. Mit dem hier vorgestellten Gastsystem erhalten Compute-Provider im C3Grid die Möglichkeit, Änderungen an der eigenen Umgebung im Vorfeld zu testen und den Workflow-Entwicklern bereits frühzeitig anzubieten, bevor diese Änderungen bei einer späteren koordinierten Globalwartung der eigentlichen Ressourcen übernommen werden können. Weiterhin können Workflow-Entwickler, die ihre Programmumgebungen auf den dafür vorgesehenen zentralen Compute-Ressourcen im C3Grid installieren müssen, ihre Workflows bereits in eigenen virtuellen Umgebungen unter realen Bedingungen testen, die Umgebung nach eigenen Wünschen ändern und die Erkenntnisse an die Compute-Provider weitergeben. Nicht zuletzt bietet das Gastsystem allen interessierten C3-Partnern die Möglichkeit, von diesem Template ausgehend einen eigenen Compute-Provider im C3Grid aufsetzen, ggfs. auch unter Verwendung eigener zentraler Rechenressourcen wie Compute-Cluster. Ob sich ein solches Template auch als Muster für einen Cloud-Computing-Ansatz im C3Grid eignet, lässt sich noch nicht abschließend beantworten. 2 VM-Layout und Anforderungen Die hier vorgestellte virtuelle Maschine wurde unter VM-Workstation / 64 bit entwickelt und wird im OVA-Format angeboten. Aus dem OVA-Image wurde bereits erfolgreich unter VMWare ESX ein Gastsystem aufgesetzt. Das Template weist zur Zeit folgende Eigenschaften auf: Image: VMWare OVA Betriebssystem: CentOS 5 / 64bit Disk 1: 10 GB für Boot-Bereich und Root-Filesystem Disk 2: 10 GB für C3Grid-Workspace CPU: 1 CPU Memory: 1 GB Netzwerkeinstellung: Bridged Network Betriebsanleitung für den virtuellen Compute-Provider Seite 3

4 Es kann vorkommen, dass im Einzelfall die vorgesehenen Ressourcen nicht ausreichen, und dass insbesondere der vorgesehene Plattenplatz für den C3Grid-Workspace wegen zu großer Datensätze nicht ausreicht. In virtuellen Umgebungen können leicht Plattenbereiche vergrößert werden oder zusätzliche Platten zu Gastsystemen hinzugefügt werden. Problematischer ist es hingegen, die über das Hostsystem erweiterten Plattenbereiche im Betriebssystem verfügbar zu machen, ohne die aktuellen Filesysteme in Mitleidenschaft zu ziehen. Die Universität zu Köln favorisiert daher, erforderliche Plattenbereiche als zusätzliche Disks dem Gastsystem zuzuweisen und im Betriebssystem des Gastes die neuen Platten über den Logical Volume Manager dem Workspace zuzuschlagen (siehe dazu das Kapitel Erweiterung des virtuellen Compute-Providers). Bei der Vergabe der Taktrate und des Memorybedarfs ist der Administrator frei, da aber zeitweise Last durch die Abarbeitung von Workflows erzeugt wird, sollten obige Vorgaben nicht unterschritten werden. Bzgl. der Anzahl der CPUs sind wahrscheinlich die Möglichkeiten durch die Virtualisierungssoftware eingeschränkt. Bei einer Erhöhung der CPU-Zahl sollte innerhalb des Gastsystems auch die Konfiguration des Batchsystems überdacht werden, etwa die Zahl der erlaubten parallelen Aufträge. 3 Download des Compute-Providers Die hier vorgestellte virtuelle Maschine kann von C3Grid-Partnern unter ftp://ftp.uni-koeln.de/rrzk/c3grid/ heruntergeladen werden. Dazu ist zunächst mit den Entwicklern der virtuellen Maschine Kontakt aufzunehmen, um den Zugang für eine begrenzte Zeit freischalten zu lassen. 4 Installation des Compute-Providers unter VMware 4.1 ESXi Diese Anleitung gilt nur falls Sie umfangreichen Zugriff auf ihre ESXi Installation haben. Falls ihnen der vsphere Client kein Begriff ist oder Sie nur über eingeschränkte Rechte verfügen, wenden Sie sich bitte an die zuständigen Stellen ihrer Institution. 1. Öffnen Sie zuerst Ihren vsphere Client. 2. Wählen Sie "Datei" -> "OVF-Vorlage bereitstellen...". 3. Geben Sie zunächst den Pfad zum OVA-Package an und drücken Sie "Weiter". 4. Bestätigen Sie die nun folgende Übersicht. 5. Weisen Sie die Machine einer Gruppe zu und vergeben Sie einen Namen. 6. Wählen Sie einen Datastorage aus. (Die Machine benötigt thick-provisioned 20GB). 7. Die nächsten drei Formulare bestimmen die Netzwerkeinstellungen der Machine. Bitte konfigurieren Sie diese nach ihren Bedürfnissen. Die Maschine ist nun fertig und kann gestartet werden. Bitte beachten Sie auch den Admin Guide (Chapter 9). Betriebsanleitung für den virtuellen Compute-Provider Seite 4

5 4.2 VMware Workstation und VMware Player Der folgende Abschnitt gilt für Linux! Die Windows Version von VMware Workstation sollte einen Menüpunkt "File" -> "Import or Export" aufweisen. Das darauf folgende Wizard kann mit OVA Paketen umgehen. Um in VMware Workstation oder VMware Player OVA-Packages zu nutzen müssen sie zunächst ins VMX Format konvertiert werden. Dazu können Sie die von VMWare bereitgestellten Tools ovftool (cli) oder VMware vcenter Converter Standalone (graphisch) nutzen. Hinweise zur Installation entnehmen Sie bitte der offiziellen Dokumentation. 1. ovftool Um das OVA Package mit ovftool zu konvertieren führen sie folgenden Befehl aus: mkdir c3comp ovftool c3comp.ova c3comp/c3comp.vmx Die resultierenden Files lassen sich nun mit VMware Workstation und VMWare Player öffnen. Dazu wählen sie "File" -> "Open...". Überprüfen Sie die Einstellungen der Netzwerkkarte unter "VM" -> "Settings" und passen Sie diese ggf. ihren Bedürfnissen an. 2. VMware vcenter Converter Standalone Mit dem Standalone Converter können Sie die VM direkt in VMware WS oder VMware Player importieren. 1. Öffnen Sie dazu den Standalone Converter (vmware-converter-client) und wählen Sie "File" -> "New" -> "Convert Machine...". 2. Im nun erscheinenden Wizard wählen sie den "source type" "Virtual appliance" und geben den Pfad zum OVA-Package an. 3. Klicken Sie nun 2x "Next >" und wählen Sie im den "destination type" "VMware Workstation or other VMware virtual machine". 4. Nachdem Sie einen Namen und einen Zielpfad angegeben haben, klicken sie auf "Next >". Überprüfen sie nun die Netzwerkeinstellungen (Bridged oder NAT). 5. Falls Sie in der nun folgenden Übersicht keine Fehler entdecken klicken Sie "Finish" um die VM zu erstellen. Nach Fertigstellung können Sie die Machine in VMware Player und VMware Workstation per "File" -> "Open" öffnen und verwenden. 5 Installation des Compute-Providers unter VirtualBox Nachdem Sie den Oracle VM VirtualBox Manager geöffnet haben, wählen Sie "Datei" -> "Appliance importieren..." und geben den Pfad des OVA-Packages an. Im nun folgenden Menü setzen Sie einen Haken bei "Zuweisen neuer MAC-Adressen für alle Netzwerkkarten", alle anderen Einstellungen sollten passend gesetzt sein (vgl. Screenshot), können aber auch nachträglich geändert werden. Klicken Sie nun auf Importieren. Betriebsanleitung für den virtuellen Compute-Provider Seite 5

6 Abbildung 1:Importfenster von VirtualBox Nachdem die Virtuelle Maschine importiert wurde, klicken Sie auf "Ändern" in der Menüleiste. Dort wählen Sie "Netzwerk" und überprüfen die Einstellungen; Standartmäßig ist dort der Modus "Netzwerkbrücke" eingestellt. Dies können sie nach ihren Bedürfnissen anpassen. Danach wechseln sie zum Punkt Anzeige und erhöhen den VRAM auf mindestens 8MB. Die virtuelle Maschine kann nun gestartet werden. 6 Inbetriebnahme des virtuellen Compute-Providers Im Folgenden werden die notwendigen Schritte beschrieben, um nach dem Import des virtuellen Compute-Providers in der eigenen virtuellen Umgebung das Gastsystem als C3Grid-Compute- Provider in Betrieb nehmen zu können. Es wird vorausgesetzt, dass beim Import und Deployment des Gastsystems entweder mindestens der SSH-Zugang durch eine DHCP-Netzwerkadresse ermöglicht wurde, oder über die Virtualisierungssoftware der Zugang zur Konsole des Gastsystems möglich ist. 6.1 Vorarbeiten Um das Gastsystem als C3Grid-Compute-Provider in Betrieb nehmen zu können, sind verschieden Information einzuholen bzw. bereitzustellen: 1. Netzwerkadresse Es muss ein gültige feste IP-Adresse für das Gastsystem nebst einem DNS-Namen eingeholt Betriebsanleitung für den virtuellen Compute-Provider Seite 6

7 werden. Weiterhin werden die Netzmaske und die IP des Gateways benötigt. Diese Informationen werden bei der Ersteinrichtung des Gastsystems benötigt. Achten Sie bei der Beantragung/Vergabe der IP-Adresse für das Gassystem, dass nachfolgende Portfreischaltungen vorgenommen werden dürfen. 2. Portfreischaltungen Um die Grid-Middleware, hier Globus Toolkit, ordnungsgemäß betreiben zu können, müssen netzseitig mindestens folgende globale Portfreigaben vorliegen: Ports Art Protokoll Programm 80 in & out TCP Wget 8080 in TCP WebMDS 8443 in & out TCP WS-GRAM 2811 in TCP GridFTP Bereich in & out TCP GridFTP 2222 in TCP GSI-SSH 7512 in TCP MyProxy Soll das Gastsystem per SSH erreichbar sein, muss außerdem Port 22, zumindest innerhalb der eigenen Einrichtung, geöffnet sein. Mehr Informationen zur Einstellung von Firewalls für Globus Toolkit (Anhang C) findet man auf den DGrid-Seiten. 3. Um im D-Grid als Dienstanbieter auftreten zu können, wird ein D-Grid-Host-Zertifikat für Globus Toolkit benötigt, das für den oben festgelegten Domain-Namen des Gastsystems ausgestellt wird. Das Host-Zertifikat wird bei der zuständigen Zertifizierungstelle, in Deutschland normlerweise GridKa oder DFN-Verein, beantragt. Achten Sie darauf, dass bei der Beantragung des Zertifikates der Name des Gastsystems noch um den Präfix host/ erweitert werden muss, sofern die ausstellende Behörde das nicht selbst durchführt. D.h., das Zertifikat für einen Compute-Provider c3comp.mydomain.de muss auf den Hostnamen host/c3comp.mydomain.de ausgestellt werden. Ob das Zertifikat tatsächlich für diesen Hostnamen ausgestellt wurde, lässt sich bspw. mit dem Aufruf openssl x509 -in /etc/grid-security/hostcert.pem -text prüfen. 6.2 Konfiguration Wenn das Gastsystem als virtuelle Maschine aufgesetzt worden ist, müssen bei der Inbetriebname noch site-spezifische Angaben zum Netzwerk, Hostnamen gemacht werden. Außerdem muss Globus Tookit an die neue Umgebung angepasst werden. Dazu muss in irgendeiner Weise ein root- Zugang zum Betriebssystem des Gastsystems vorliegen. Im wesentlichen gibt es 2 Möglichkeiten: 1. SSH-Zugang Das Betriebssystem der virtuellen Maschine beinhaltet einen SSH-Server, der beim Booten automatsch gestartet wird. Außerdem ist netzwerkseitig die Versorgung mit IP, DNS-Server etc. per DHCP vorgegeben. Wird das Subnetz, in dem sich das Gastsystem befindet, über ei- Betriebsanleitung für den virtuellen Compute-Provider Seite 7

8 nen DHCP-Server mit entsprechenden Daten versorgt, kann bei der Ersteinrichtung der Maschine die IP oder DNS-Name, soweit bekannt, verwendet werden, um einen Zugang per SSH-Client zu erhalten. 2. Konsole-Zugang über die Virtualisierungssoftware Virtualisierungslösungen von VMware und VirtualBox bieten die Möglichkeit eines direkten Konsol-Zugangs zu den eingerichteten Gastsystemen. Sofern die Berechtigung dafür vorliegt, kann über eine Client-Software, e.g. vsphere bei VMware, VirtualBox-Client direkt auf die Konsole zugegriffen werden. Diese Zugangsart ist zu bevorzugen, da sie immer funktioniert (, sofern die Maschine überhaupt läuft,) und auch bei Netzproblemen den Eingriff in das Betriebssystem erlaubt. Die Ersteinrichtung wird wie folgt durchgeführt: 1. Einloggen als Administrator Das Gastsystem besitzt als Administrator-Account Username: Password: root (bitte bei den Autoren erfragen) Es spielt dabei keine Rolle. ob Sie sich über einen SSH-Zugang oder den Konsole-Zugang einloggen. Da dieser Account vorgegeben ist, auf allen deratigen Compute-Provider-Systemen zunächst eingerichtet ist und die Accountdaten somit nicht geheim gehalten werden können, sollte unbedingt das Password mit dem Aufruf passwd neu gesetzt werden. 2. Einrichtung des Netzwerkes Um das Gastsystem mit den geeigneten Netzwerkeinstellungen zu versehen, kann im Betriebssystem das Programm system-config-network gestartet werden. Das Programm führt mit Hilfe von Eingabemasken durch die Einstellungen für den Netzwerkadapter (typischerweise eth0) und das Domain Name System. Für den Netzwerkadapter müssen die Angaben für die o o o statische IP-Adresse Subnetz-Maske Gateway bereitgehalten/eingetragen werden, DHCP ist zu deaktivieren. Für die Einstellungen des DNS sind o o der zugewiesene Rechnername mindestens 1 DNS-Server Betriebsanleitung für den virtuellen Compute-Provider Seite 8

9 o ggfs. ein Suchraum für das DNS anzugeben. Nach dem Sichern aller Einstellungen muss das Netzwerk neu gestartet werden: service network restart Da hier alle Netzwerkverbindungen unterbrochen werden, werden auch SSH-Sitzungen beendet. Sofern man keinen Fehler bei den Netzwerkeinstellungen gemacht hat, kann man sich mit dem neuen Rechnernamen beim Gastsystem per SSH-Client melden. Sollte das wg. eines Fehlers nicht mehr funktionieren, bleibt nur noch der Zugang über die Konsole der Virtualisierungssoftware, um die Netzwerkeinstellungen noch einmal zu prüfen. Nach erfolgreichem Neustart sollten die Programmaufrufe hostname -f hostname -i ifconfig einigen Aufschluss über die aktuelle Netzkonfiguration geben. 3. Übertragung des D-Grid-Host-Zertifikates Um die installierte Grid-Middleware nutzen zu können, muss auf dem Gastsystem das bei der eigenen Zertifizierungsstelle (s.o.) beantragete D-Grid-Host-Zertifikat, bestehend aus einem Public-Key/Private-Key Paar, im Verzeichnis /etc/grid-security unter den Namen /etc/grid-security/hostcert.pem (public key) /etc/grid-security/hostkey.pem (private key) abgelegt werden. Sofern ein Filetransfer per SSH-Protokoll möglich ist, kann das Zertifikat mit Secure Copy übertragen werden. Sollte das Zertifikat noch nicht als Public-Key/Private-Key Paar im PEM-Format vorliegen, erkundigen Sie sich bei der ausstellenden Zertifizierungsstelle, wie das Zertifikat konvertiert werden kann. Wichtig: Der Private Key darf keine Passphrase mehr zur Verschlüsselung beinhalten. 4. Anpassung der Middleware Wenn die Netzwerkeinstellungen korrekt sind und auch das Host-Zertifikat an den richtigen Stellen vorliegt, können mit Aufruf des von der Universität zu Köln bereitgestellten Scriptes die Konfiguration der Middleware und die Starteinstellungen beim Booten vorgenommen werden. Aufruf: /root/init-scripts/c3comp-init.sh Folgende Schritte werden dabei durchgeführt, die in den verwendeten Scripten für Teilaufgaben unter /root/init-scripts/subscripts/ nachvollzogen oder ggfs. Betriebsanleitung für den virtuellen Compute-Provider Seite 9

10 für zukünftige Zwecke geändert werden können: o o o o Erstellung der Globus-Containerkeys samt Permissions Ersatz aller alten Hostnamen und IP-Angaben in allen relevanten Dateien von Globus Toolkit, PostGreSQL, Torque, Tomcat Abfrage zur Starteinstellung beim Booten von Globus Toolkit, PostGreSQL, Torque, Tomcat Abfrage zum sofortigen Start von Globus Toolkit, PostGreSQL, Torque, Tomcat Beantwortet man die Frage nach dem sofortigen Start positiv, werden alle Dienste sofort gestartet und der Compute-Provider ist augenblicklich aktiv. Beantwortet man die Frage, ob die notwendigen Dienste beim Booten gestartet werden sollen, negativ, müssen nach einem Neustart des Gastsystems die folgenden Dienste in der angegebenen Reihenfolge manuell gestartet werden: service postgresql start service pbs_server start service pbs_mom start service pbs_sched start service tomcat5 service globus start start Sollen die Dienste später dennoch für den automatischen Start beim Booten vorgesehen werden, kann man dies individuell durch die Aurufe ckconfig postgresql on ckconfig pbs_server on ckconfig pbs_mom on ckconfig pbs_sched on ckconfig tomcat5 on ckconfig globus on erreichen. Entsprechend kann man den Start der Dienste auch bei einem Neustart über die Option off unterdrücken. 6.3 Zusätzlicher Grid-Dienst GSISSH Im Auslieferungszustand der virtuellen Maschine ist der über GSI gesicherte SSH-Zugang unterdrückt. Sollte sich die Notwendigkeit erweisen, den GSI gesicherten SSH-Zugang nutzen zu müssen, etwa weil Instituts-seitig der Standard-SSH-Zugang nicht freigeschaltet werden darf, so kann der der zugehörige GSISSH-Server vom Administrator manuell gestartet werden durch den Aufruf service gsisshd start Soll der Dienst bereits automatisch beim Booten der virtuellen Maschine gestartet werden, muss dies noch durch die Eingabe ckconfig gsisshd on Betriebsanleitung für den virtuellen Compute-Provider Seite 10

11 eingestellt werden. Der vorkonfigurierte GSISSH-Server verwendet Port 2222, der für die Nutzung daher netzseitig freigeschaltet sein muss. Der Start des GSISSH-Servers ermöglicht allen in /etc/grid-security/grid-mapfile eingetragenen Grid-Nutzern, sich mit gültigem Proxy-Zertifikat auf der virtuellen Maschine ohne Passwort einzuloggen. Der verwendete User-Account wird aus dem Grid-Mapfile entnommen. Beispielsweise könnte so den Entwicklern der virtuellen Maschine für administrative Zwecke ein Zugang gewährt werden, ohne die obligatorische Account-Verwaltung der eigenen Einrichtung in Anspruch nehmen zu müssen. 6.4 Test der Grid-Funktionalität Wenn die o.g. Dienste gestartet sind und die Portfreigaben eingerichtet sind, kann ein autorisierter Nutzer aus dem D-Grid oder auch ein Portal-Nutzer der AWI-CA Aufträge an den neuen Compute- Provider senden. Um einem D-Grid-Nutzer die Gelegenheit zu geben, die Grid-Middleware samt WS-GRAM zu testen, muss der DN (Distinguish Name) des D-Grid-Nutzers vorab im Grid-Mapfile unter /etc/grid-security/grid-mapfile eingetragen werden und auf den vorgesehen Standard-Linux-Nutzer c3-usr gemappt werden. Soll diese Änderung permanent gelten, muss das Mapping zusätzlich noch in /etc/grid-security/grid-mapfile.local verankert werden, da der eigentliche Grid-Mapfile nachts durch die Vorgaben der AWI-CA aktualisiert und überschrieben wird. Von einem Globus Client kann der o. eingetragene D-Grid-Nutzer die einzelnen integrierten Middleware-Komponenten wie WS-GRAM, Fork, GridFTP, MDS testen: Test-Beispiel für WS-GRAM client> globusrun-ws -submit -Ft PBS -F c3comp.mydomain.de -s -q -c -- /bin/hostname c3comp.mydomain.de client> wobei c3comp.mydomain.de für das Gastsystem mit dem C3Grid-Compute-Provider steht, und client der persönliche Globus-Client ist Test-Beispiel für Fork client> globusrun-ws -submit -Ft Fork -F c3comp.mydomain.de -s -q -c -- /bin/hostname c3comp.mydomain.de client> Betriebsanleitung für den virtuellen Compute-Provider Seite 11

12 6.4.3 Test-Beispiel für den File-Transfer per GridFTP client> globus-url-copy gsiftp://c3comp.mydomain.de/etc/redhat-release file:///tmp/ client> cat /tmp/redhat-release CentOS release 5.6 (Final) client> Test des MDS Das Informationssystem MDS kann über das Web-Interface MDS getestet werden. Außerdem sollte der WebMDS spätestens nach 15 Minuten auch beim Master WebMDS in Dortmund registriert sein. Folgende URLs können zur Prüfung herangezogen werden: Test des GSISSH-Servers client> gsissh -p 2222 c3comp.mydomain.de Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Thu Aug 18 15:13: from client.mydomain.de c3comp# 7 Layout des Compute-Providers Es folgen einige Hinweise zum Aufbau des Compute-Providers, die bei der Administration des Providers hilfreich sein könnten. 7.1 OS Betriebssystem ist CentOS 5.6 und ist ein Derivat/Neucompilat der RedHat Linux 5.6 Quellen. Das Betriebssystem verhält sich zumindest oberflächlich betrachtet wie ein RedHat Linux 5.6, Kernel und Sofware-Pakete sind kompatibel. Die Paketverwaltung basiert auf RPM, Betriebssystem- Updates werden via YUM und den unter /etc/yum.repos.d/ konfigurierten Repositories durchgeführt. Insbesondere das EPEL Repository, ehemals als Ergänzung für RedHat Betriebssysteme gedacht, bietet eine Fülle an zusätzlichen RPM-Paketen, die bei RedHat zunächst nicht, oder nur veraltet, mitgeliefert werden. 7.2 Plattenaufteilung Der Compute-Provider beinhaltet 2 "physikalische" Platten (sofern man bei virtuellen Maschinen von "physikalischen" Platten sprechen darf; aber das OS weiß ja nicht, dass es virtualisiert läuft): /dev/sda: 10 GB für Boot-Bereich und Root-Filesystem /dev/sdb: 10 GB für C3Grid-Workspace & Scratch-Bereich Betriebsanleitung für den virtuellen Compute-Provider Seite 12

13 Um die Aufteilung der Platten so flexible wie möglich zu halten, wird der Logical Volume Manager zur Verwaltung der Platten eingesetzt. /dev/sda beinhaltet eine kleine statische Partition (/dev/sda1) für den Bootbereich (unter /boot gemountet), der allergrößte Teil (/dev/sda2) ist eine physikalische LVM-Partition, die in 2 logische Volumes augeteilt ist: ca. 2GB für den Swap-Bereich, 7,9 GB als Root-Partition, vgl. Ausgabe von fdisk -l /dev/sda pvdisplay /dev/sda2 lvdisplay VolGroup00 /dev/sdb beinhaltet nur eine große Partition (/dev/sdb1), die komplett als physikalische LVM-Partition nur für den C3-Workspace und den Scratch-Bereich (/scratch) eingesetzt wird. Zurzeit liegen der C3-Workspace und der Scratch-Bereich auf der gleichen Partition, der gemeinsame Speicherbereich beträgt 10 GB, vgl. Ausgabe von fdisk -l /dev/sdb pvdisplay /dev/sdb1 lvdisplay c3workspace Die logische Partition, die diesen Bereich enthält, wird unter /opt/c3grid/gemountet, der C3- Workspace und der Scratch-Bereich befinden sich damit unter /opt/c3grid/dms_workspace /opt/c3grid/scratch Als Besonderheit wird der Scratch-Bereich noch zusätzlich per BIND-Mount unter /scratch angeboten (vgl. Ausgabe des Aufrufs mount). 7.3 Module-Environment Für die Unabhängigkeit des Workflows sieht das C3Grid den Einsatz der Environment Modules vor, vgl. C3_unified_computing_environment. Die Installation der zugehörigen Software erfolgt unter /opt/software/, die Modulebeschreibungen sind unter /opt/software/modulefiles/ abgelegt, wobei hier noch eine Kategorisierung erfolgen kann. 7.4 Automatische Dienste Um einen weitgehend autarken Betrieb der Maschine ohne Administrationsaufwand zu ermöglichen, sind folgende automatischen Dienste eingerichtet: 1. logrotate o default: wöchentliche Rotation, 4 Wochen speichern. o globus: tägliche Rotation mit Neustart des Globus-Containers, 7 Tage speichern o tomcat: tägliche Rotation, 5 Tage speichern 2. tmpwatch o Dieser Dienst säubert automatisch temporäre Verzeichnisse anhand des Alters der Files. Betriebsanleitung für den virtuellen Compute-Provider Seite 13

14 /tmp: atime älter als 240h /var/tmp: atime > 720h /opt/c3grid/workspace: atime > 48h /scratch: atime > 48h torque server logs: mtime > 72h 3. getgridmapfile o Dieser Dienst lädt automatisch den neusten C3-INAD Grid-Mapfile vom AWI herunter und hängt die site-spezifischen Ergänzungen (vgl. /etc/gridsecurity/grid-mapfile.local) an 4. fetch-crl o Dieser Dienst lädt automatisch die neusten Revocation-Lists aus dem Internet. 7.5 Eingerichtete User und Einrichtung neuer User Auf dem Compute-Provider sind folgende "echte" Nutzer eingerichtet: User Password Art root s. Konfiguation, sollte unbedingt mit dem Aufruf /bin/passwd geändert werden globus illegales Password vereinbart, daher nicht SSH-tauglich, auch nicht für GSI-SSH c3-usr illegales Password vereinbart, daher nicht SSH-tauglich, auch nicht für GSI-SSH Account des Administrators Account zum Betrieb der Middleware Sammel-Account für das Mapping der Grid-Nutzer im Gridmap-File und zur Abarbeitung der Workflows Um weitere echte Nutzer einzurichten, steht das Programm system-config-users zur Verfügung. Sollen diese Nutzer einen Grid-Zugang zum Compute Provider erhalten, muss der Distinguish Name (DN) des Nutzers zusammen mit dem Accountnamen im Gridmap-File /etc/grid-security/grid-mapfile eingetragen werden. Achtung: der Gridmap-File /etc/grid-security/grid-mapfile wird periodisch neu erzeugt aus der Vorgabe der C3-INAD-User (vom AWI) und einem lokalen site-spezifischen Gridmap-File /etc/grid-security/grid-mapfile.local. Soll ein Nutzer dauerhaft den Grid-Zugang zum Compute Provider erhalten, muss der Distinguish Name des Nutzers zusammen mit dem Accountnamen in diesem Gridmap-File ebenfalls eingetragen werden. Sollen sich die Nutzer von außerhalb mit GSI-SSH einloggen dürfen, muss neben der Anpasung des Gridmap-Files zusätzlich der GSI-SSHD-Server gestartet werden. Im laufenden Betrieb ruft man als Administrator dazu auf: service gsisshd start Soll der GSI-SSHD-Server automatisch auch beim nächsten Neustart des Betriebssystems gestartet werden, ist dies zusätzlich im Betriebssystem zu vereinbaren: chkconfig gsisshd on Standardmäßig ist der GSI-SSH-Server ausgeschaltet. 7.6 Initialisierung des Globus-Client Um auf dem virtuellen Compute-Provider in einer interaktiven Bourne-artigen Shell die ebenfalls Betriebsanleitung für den virtuellen Compute-Provider Seite 14

15 vorhandenen Funktionen des Globus-Clients nutzen zu können, muss das Environment des Nutzers angepasst werden, Variablen und Pfade gesetzt werden. Dazu wird in der Shell aufgerufen (der Punkt am Anfang gehört dazu!):. /usr/local/etc/globus-env-setup.sh Danach stehen Programmaufrufe wie etwa globus-url-copy oder globusrun-ws zur Verfügung. Anmerkung: Dieses Initialisierung wird implizit ebenfalls beim Start des Globus-Servers durchgeführt, vgl. /etc/init.d/globus). 8 Erweiterung des virtuellen Compute-Providers Prinzipiell kann der virtuelle Compute-Provider erweitert werden, um die Leistungsfähiglkeit zu steigern. Im Folgenden sind naheliegende Maßnahmen skizziert. 8.1 Höhertaktung der CPU, mehr CPUs, Vergrößerung des Hauptspeichers Da es sich bei dem Compute-Provider um eine virtuelle Maschine handelt, kann seitens des Hostsystems über die Virtualisierungssoftware die Taktung der Maschine erhöht werden, außerdem kann die Maschine mit mehr CPUs ausgestattet werden. Letzteres ist dann sinnvoll, wenn über C3Grid mehr Last auf den virtuellen Compute-Provider gelenkt wird. Um einer höheren CPU-Zahl Rechnung zu tragen, sollte die Zahl der gleichzeitig erlaubten Batchjobs angepasst werden. Bei Erhöhung der Zahl der CPUs, aber auch im normalen 1-Core-Betrieb kann es sich als sinnvoll erweisen, den virtuellen Compute-Provider mit mehr Hauptspeicher zu versehen. Dies geschieht ebenfalls über die Virtualisierungssoftware des Hostsystems. Ggfs. ist eine Reboot notwendig, um die Ressourcenänderungen nutzen zu können. 8.2 Vergrößerung des Plattenplatzes im DMS Workspace und Scratch Da es sich bei dem Compute-Provider um eine virtuelle Maschine handelt, kann seitens des Hostsystems über die Virtualisierungssoftware eine zusätzliche dritte Platte mit hinreichendem Plattenplatz bereitgestellt werden. Von einer Vergrößerung der Workspace-Platte als solcher über das virtualisierende Hostsystem wird abgeraten, weil eine eventuelle spätere Reduzierung des Plattenplatzes sich schwieriger gestaltet. Nach der Bereitstellung der dritten Platte ist in der Regel eine Reboot erforderlich. Die dritte virtuelle Platte, die zur Vergrößerung dienen soll, erhält betriebssystemseitig üblicherweise den Devicenamen /dev/sdc, im Zweifel kann dies aber auch über den Aufruf fdisk -l /dev/sdc geprüft werden. Achtung: Wenn im Nachfolgenden die falsche Platte verwendet wird, können Daten unwiderruflich verloren gehen. Folgende Schritte sind für die Erweiterung des DMS Workspace um die neue Platte notwendig Initialisierung der neuen Platte als physikalisches Volume im LVM: Betriebsanleitung für den virtuellen Compute-Provider Seite 15

16 pvcreate /dev/sdc Erweiterung der bestehenden Volume Group, in der sich das logische Volume mit dem DMS Workspace befindet (, im Auslieferungszustand ist dies die Volume Group c3workspace, Volume Group vorher mit vgdisplay c3workspace auf Existenz prüfen), um das neue physikalische Volume /dev/sdc: vgextend c3workspace /dev/sdc Erweiterung des logischen Volumes, auf dem sich der DMS Workspace befindet (, im Auslieferungszustand ist dies das logische Volume /dev/c3workspace/c3workspace, logisches Volume vorher mit lvdisplay auf Existenz prüfen), um den gesamten in der o.g. Volume Group befindlichen Plattenplatz: lvextend -l +100%FREE /dev/c3workspace/c3workspace Erweiterung des auf dem o.g. logischen Volume momentan angelegten Filesystems auf den neuen Bereich: resize2fs /dev/c3workspace/c3workspace Nach diesen Schritten steht dem DMS Workspace der neue Plattenplatz zur Verfügung, ein Reboot ist nicht erforderlich. 8.3 Anbindung des Compute-Providers an ein separates Compute- Cluster Folgende Arbeiten sind grundsätzlich erforderlich, um für die Ausführung von Workflows per WS- GRAM ein eigenes separates Cluster einzusetzen. Wegen der speziellen Verhältnisse bei den einzelnen Compute-Providern vorort lassen sich die notwendigen Arbeiten nur skizzieren und müssen individuell umgesetzt werden: Bereitstellung aller für die Ausführung der Workflows erforderlichen Standard-Software auf dem Cluster Bereitstellung der Envronment Modules und Modulefiles auf dem Cluster, speziell Modulefile für C3Grid-Variablen Migration der Workflows und Tasks auf das Cluster gesharetes Filesystem zwischen Cluster und virtuellem Compute-Provider für den DMS Workspace, Benachrichtigung an WSS, falls Pfad sich ändert. gemeinsames Batchsystem zwischen virtuellem Compute-Provider, d.h. o ggfs. Installation des richtigen Globus-Job-Managers auf dem virtuellen Compute- Provider, falls das Cluster nicht PBS/Torque unterstützt, zusätzlich Installation der erforderlichen Client-Pakete auf dem virtuellen Compute-Provider für das Cluster- Batchsystem o Sichtbarkeit der Logfiles des Cluster-Batchsystems auf dem virtuellen Compute- Provider gewährleisten o Konfiguration des Globus-Job-Managers, evtl. neues Batchsystem, anderer Exec- Host (= eigenes Cluster) o Konfiguration des Cluster-Batchsystems wg. neuem Submit-Host (= virtueller Compute-Provider) Betriebsanleitung für den virtuellen Compute-Provider Seite 16

17 evtl. Installation des Ganglia-Information-Providers im MDS, GeoMaint-Service, C3Grid- Infoprovider Für Änderungen an der Globus-Installation, insbesondere bei der Installation eines neuen Job- Managers sollte zunächst ein Backup der Globus-Installation vorgenommen werden, um ggfs. später auf den alten Zustand zurückkehren zu können. 9 Nutzung der installierten Workflows Auf der virtuellen Maschiene sind zur Zeit folgende Workflows installiert: cdo QFlux Cape Stormtrack CWT... Die Workflows und deren Tasks sind unterhalb des Verzeichnisses /opt/software/c3tools/workflows abgelegt. 9.1 Standalone Tests installierter Workflows Um die Funktion der installierten Workflows zu überprüfen, sollten die einzelnen Workflows zunächst ohne Grid-Nutzung "standalone" ausgeführt werden. Zu jedem Workflow existiert daher ein Batchscript, dass mit dem Aufruf qsub <script> an das installierte Batchsystem geschickt werden kann. Die benötigten Daten werden mit dem virtuellen Compute-Provider ebenfalls ausgeliefert, die Ergebnisse eines solchen Batchjobs sind im C3-Workspace zu finden, Stdout und Stderr des Jobs liegen im CWD, aus dem man die Batchjobs abgesendet hat. 9.2 Portal-Tests der installierten Workflows Um die installierten Workflows gridseitig über das Portal testen zu können, muss zunächst der virtuelle Compute-Provider beim Workflow-Scheduler in Dortmund registiert werden. Siehe auch: Bei der Registrierung wird ein eindeutiger Name der Art <xyz>.cp.c3grid.de vergeben, über den der eigene Compute-Provider und GridFTP-Server in den Workflow-Beschreibungen (WSL- Files) adressiert werden. Zu jedem Workflow existiert ein WSL-File, der zum Test des Workflows per Upload im Portal verwendet werden kann. Wichtig ist dabei, dass in den betreffenden WSL-Files der eigene CP- Provider-Name für die Adressierung der Teilaufgaben verwendet wird. Alternativ kann man auch einen WSL-File, der automatisch von Portal erzeugt wurde und nach beendeter Arbeit als Anhang bei der -Bestätigung versandt wird, als Muster verwenden und nur Betriebsanleitung für den virtuellen Compute-Provider Seite 17

18 den eigenen CP-Provider-Namen ersetzen. Ggfs kann es noch erforderlich sein, alle im WSL-File verwendeten Filenamen umzubenennen, da ev. das DMS Kenntnis über bereits verwendete Zwischenprodukte hat. 10 Neue Workflows Die virtuelle Maschine eignet sich ebenfalls, um unabhängig von anderen C3Grid-Compute- Providern neue Workflows in einer eigenen Gridumgebung aufzusetzen, zu testen oder ggfs. der Allgemeinheit anzubieten. Prinzipiell ist die Vorgehensweise zur Implementation von neuen Workflows im Deliverable Best Practices in Packaging and Releasing C3Grid Software beschrieben. Zusätzlich benötigte Standard-Software, die in der virtuellen Maschine nicht enthalten ist, kann mit YUM über die in /etc/yum.repo.d konfigurierten Betriebssystem-Repositorien bezogen und installiert werden. Zur Nutzung von YUM vgl. man yum Die Workflows und deren Tasks werden, wie in Best Practices in Packaging and Releasing C3Grid Software beschrieben, im Workflowverzeichnis bereitgestellt. Nach erfolgreichem Test per WSL- Upload können die Workflows auch im Portal bereitgestellt werden Betriebsanleitung für den virtuellen Compute-Provider Seite 18