Jahresbericht 2009 Juni 2010 LRZ-Bericht

Größe: px
Ab Seite anzeigen:

Download "Jahresbericht 2009 Juni 2010 LRZ-Bericht 2010-01"

Transkript

1 Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften Jahresbericht 2009 Juni 2010 LRZ-Bericht Direktorium: Prof. Dr. A. Bode (Vorsitzender) Prof. Dr. H.-J. Bungartz Prof. Dr. H.-G. Hegering Prof. Dr. D. Kranzlmüller Leibniz-Rechenzentrum Boltzmannstraße Garching UST-ID-Nr. DE Telefon: (089) Telefax: (089) Internet: Öffentliche Verkehrsmittel: U6: Garching-Forschungszentrum

2

3 Jahresbericht 2009 des Leibniz-Rechenzentrums i Vorwort Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Kurse und Veranstaltungen Kursübersicht, Statistik Vorträge Schattenseiten des Internet Software-Versorgung für Rechnersysteme außerhalb des LRZ Benutzerverwaltung und Verzeichnisdienste Für LRZ-Systeme vergebene Kennungen LRZ Secure Identity Management (LRZ-SIM) IntegraTUM-Teilprojekt Verzeichnisdienst AAI-Föderationen: Shibboleth Identity Provider , Web-Dienste und Datenbanken Services Webdienste Datenbanken Grafik, Visualisierung, Multimedia Visualisierungs-Projekte Nutzung des Streamingservers Serveradministration und Applikationsunterstützung Serveradministration in BDS Service für das Münchner Wissenschaftsnetz Desktop- und Applikationsservices Sicherheitsdienste für Desktops im MWN Active Directory im Münchner Wissenschaftsnetz Provisionierung der Benutzer in das Active Directory Desktop Management Server Management System Center Configuration Manager Microsoft Office Sharepoint Services Projekte im Rahmen der Lehrlingsausbildung Server- und Benutzerzertifizierung nach X Bearbeitung von Missbrauchsfällen Statistik der Missbrauchsfälle Besondere Ereignisse IT-Bibliotheksverbund Bayern Rechnerbeschaffung Zentrale Authentifizierung und Sicherheitskonzept Firewall-Cluster Virtualisierung Neue Hardware für Mybib Neue Dienste Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Entwicklung bei der Datenhaltung Überblick Archiv- und Backupsystem Langzeitarchivierung... 48

4 ii Inhaltsverzeichnis Online-Speicher Entwicklungen bei den Rechensystemen Höchstleistungsrechner in Bayern (HLRB II: SGI Altix 4700) Linux-Cluster Remote Visualisierungsserver Software und User Support im Bereich Hochleistungsrechnen Entwicklungsumgebung Anwendungen Supportanfragen Öffentlichkeitsarbeit HLRB and KONWIHR Results and Review Workshop Benutzerdiskussion Supercomputing Konferenzen in Hamburg und Portland Veranstaltungen im Bereich Hochleistungsrechnen InSiDE Aktivitäten für ein nationales und europäisches HPC-Konzept Gauss Centre for Supercomputing Projekte und Kooperationen BMBF Verbundprojekt ISAR KONWIHR PRACE: Partnership for Advanced Computing in Europe Tätigkeiten im Server-Betrieb Linux-Serversysteme Virtualisierung am LRZ PCs unter Linux als Mitarbeiter-Arbeitsplätze Betriebsüberwachung Aktivitäten im Bereich Verteilte Ressourcen D-Grid (Förderung e-science und vernetztes Wissensmanagement des BMBF) DEISA Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) LRZ-Projekt Eclipse4Grid Cloud-Computing Projektanträge 7. EU-Forschungsrahmenprogramm e-infrastrukturen Betrieb der Grid-Infrastruktur Sonstige Grid-Aktivitäten Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Betrieb des Kommunikationsnetzes Backbone-Netz Gebäude-Netze Rahmenvertrag für die Beschaffung von Switches Wellenlängenmultiplexer WLAN (Wireless LAN) Wesentliche Netzänderungen im Jahr Netzausbau (Verkabelung) Anbindung Studentenwohnheime Dienste Internet-Zugang Domain Name System

5 Jahresbericht 2009 des Leibniz-Rechenzentrums iii Wählzugänge (Modem/ISDN) VPN (IPsec) DFN-Roaming Unterstützung von Veranstaltungen Service Load Balancer (SLB) Proxies und Zeitschriftenzugang DHCP-Server VoIP im Jahr Zugang über UMTS: Vodafone Sponsoring der Exzellenz Universitäten TU München und der Ludwig-Maximilians-Universität München IPv6 im MWN Management Weiterentwicklung und Betrieb der Netzdokumentation Netz- und Dienstmanagement Überwachung der Dienstqualität des MWN mit InfoVista Action Request System (ARS) IT-Service Management Sicherheit NAT-o-MAT/Secomat Security Information und Event Management (SIEM) Zentraler Log-Server Zentrale Sperrliste Monitoring am X-WIN-Übergang Sicherheitswerkzeug "Nyx" Virtuelle Firewalls Projektarbeiten im Netzbereich D-GRID Das CNM und die Géant-Visualisierungswerkzeuge für Performance Monitoring Géant E2E Link Monitoring Géant I-SHARe GET-E Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen Arbeitskreis Security Arbeitskreis IT-Service-Management Arbeitskreis Continuity Arbeitskreis Informationsmanagement Organisatorische Maßnahmen im LRZ Personalveränderungen Zugänge Abgänge Gebäudemanagement und Gebäudebetrieb Nutzungsänderungen hin zu Büronutzung Energieeffizienz Erweiterung des LRZ (Rechnerwürfel und Institutsgebäude) Personalausstattung der Hauswerkstätte Dienstleistungskatalog Mitarbeit in Gremien

6 iv Inhaltsverzeichnis Abteilung Benutzernahe Dienste und Systeme Abteilung Hochleistungssysteme Abteilung Kommunikationsnetze Abteilung Zentrale Dienste Veranstaltungen am LRZ Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen Abteilung Benutzernahe Dienste und Systeme Abteilung Hochleistungssysteme Abteilung Kommunikationsnetze Abteilung Zentrale Dienste Öffentlichkeitsarbeit LRZ als Ausbildungsbetrieb Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten Veröffentlichungen der Mitarbeiter Promotionen am LRZ Regelwerk des LRZ Satzung der Kommission für Informatik Mitglieder der Kommission für Informatik Benutzungsrichtlinien für Informationsverarbeitungssysteme Betriebsregeln des Leibniz-Rechenzentrums Richtlinien zum Betrieb des Münchner Wissenschaftsnetzes (MWN) Richtlinien zur Nutzung des Archiv- und Backupsystems Gebühren des Leibniz-Rechenzentrums Zuordnung von Einrichtungen zu LRZ-Betreuern Betriebs- und Organisationskonzept für den Höchstleistungsrechner in Bayern (HLRB) Nutzungs- und Betriebsordnung für den Höchstleistungsrechner in Bayern (HLRB) Mitglieder des Lenkungsausschusses des Höchstleistungsrechners in Bayern (HLRB) Technische Ausstattung Rechner und Server Höchstleistungsrechner SGI Altix Hochleistungs-Linux-Systeme Grid-Rechner Hochleistungs-Graphik-System Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner Speicher NAS+SAN Bruttokapazitäten im Überblick Netzkomponenten Router WLAN-Komponenten Switches Netz-Server

7 Jahresbericht 2008 des Leibniz-Rechenzentrums, Vorwort 1 Vorwort Der Jahresbericht 2009 des Leibniz-Rechenzentrums (LRZ) der Bayerischen Akademie der Wissenschaften dokumentiert das weitere quantitative und qualitative Wachstum dieser Einrichtung, das sich aus der steigenden Nachfrage nach IT-Dienstleistungen in Forschung und Lehre sowie der nationalen und internationalen Wertschätzung, die das LRZ genießt, ergibt. Im Jahr 2009 lagen die Schwerpunkte der Arbeiten in den folgenden Bereichen: Weitere Professionalisierung der Arbeit des LRZ als IT-Dienstleistungszentrum für weit über Kunden durch Fortsetzung des Weges zur ISO/IEC Zertifizierung, Einführung eines einheitlichen, kontrollierten und werkzeuggestützten Dokumentationsprozesses, Weiterentwicklung des Dienstleistungskatalogs, Ausbau der Mitarbeiter-Weiterbildung sowie strategische Ausrichtung von vier Querschnitts-Arbeitskreisen zu den Themen Security, IT-Service- Management, Continuity und Informationsmanagement. Abschluss und Verstetigung des Projektes IntegraTUM mit einer Festveranstaltung in Anwesenheit von Staatsminister Dr. Heubisch, CIO Staatssekretär Pschierer und zahlreichen weiteren Gästen am 24. September Vorbereitung der Beschaffung des Höchstleistungsrechners SuperMUC und Einbindung in die Aktivitäten des Gauss Centre for Supercomputing GCS in Deutschland sowie die Partnership for Advanced Computing in Europe (PRACE), sowie aktives Engagement in entsprechenden deutschen und europäischen Organisationen und Projekten. Erweiterung des bestehenden Gebäudes des LRZ, insbesondere Ausbau des Rechnerkubus zu einem Doppelkubus sowie Neubau eines Mitarbeiter- und Visualisierungstraktes. Diese Erweiterung dient sowohl der Vorbereitung auf die neuen europäischen Aufgaben im Bereich des Hochleistungsrechnens als auch als Raumerweiterung für alle weiteren Dienste. Voraussetzung war die Bewilligung der Ausbausumme von knapp 50 Mio.. Nachfolgend sind die Aktivitäten des LRZ wie in den Vorjahren in der Reihenfolge der Abteilungen beschrieben. Teil 1 der vorausgegangenen Jahresberichte wird künftig jedoch in einer gesonderten Broschüre die Dienstleistungen des LRZ darstellen und wird in Kürze erscheinen. Dies soll die besondere Kundenorientierung des Angebots des LRZ weiter unterstreichen. An dieser Stelle möchte ich den Mitarbeiterinnen und Mitarbeitern des LRZ für ihre engagierte Arbeit danken. Mein besonderer Dank gilt aber auch der Leitung der Bayerischen Akademie der Wissenschaften, den zuständigen Ansprechpartnern im Bayerischen Staatsministerium für Wissenschaft, Forschung und Kunst sowie den Mitgliedern des HLRB-Lenkungsausschusses und der Kommission für Informatik, die die Arbeit des LRZ mit konstruktiver Kritik stets fachkundig unterstützt haben. Persönlich danke ich insbesondere den Mitgliedern des Direktoriums des LRZ, den Kollegen H. J. Bungartz, D. Kranzlmüller und H.-G. Hegering, die ihre große Fachkompetenz in die Leitung des LRZ mit eingebracht haben.der vorgelegte Jahresbericht geht wieder bewusst über das Zahlenwerk üblicher Jahresberichte hinaus. Wir versuchen wie in den letzten Jahren, viele unserer Dienste und Geschäftsprozesse zu erklären und unsere Konventionen und Handlungsweisen zu begründen. Dies soll die Komplexität unserer Aufgabenstellung und das LRZ als Institution transparenter machen. Das LRZ nimmt aufgrund seiner Größe und Organisationsform, seines Umfangs des Versorgungsbereiches, seiner Anzahl der Nutzer, Anzahl, Vielfalt und Heterogenität der Systeme, Beteiligung an Entwicklungsprojekten usw. eine deutliche Sonderstellung ein, die auch im Bericht sichtbar wird. Eine moderne IT-Infrastruktur ist essentiell für die Wettbewerbsfähigkeit der Hochschulen und des Landes, und so muss auch das IT-Kompetenzzentrum eng im Hochschulumfeld verankert sein. Das Leibniz- Rechenzentrum als das technisch-wissenschaftliche Rechenzentrum für die Münchner Hochschulen wird sich auch in Zukunft den Anforderungen eines modernen IT-Kompetenzzentrums stellen, und das nicht nur durch den zuverlässigen Betrieb von IT-Infrastruktur, sondern auch durch aktive Beteiligung an Forschung und Entwicklung in den Bereichen Kommunikationssysteme, IT-Managementprozesse, Computational Science und Grid-Computing. Hierzu zählen auch die Initiativen im Rahmen von ISO/IEC Ich bin überzeugt davon, dass es dem LRZ auch im Jahr 2009 erneut gelungen ist, die Erwartungshaltung seiner Nutzer einerseits, aber auch seiner Finanzgeber andererseits zu erfüllen und seine Dienstqualität

8 2 Vorwort und IT-Kompetenz erneut zu steigern. Ich freue mich auf die Zusammenarbeit mit Ihnen und die weitere Entwicklung im Jahr Univ.-Prof. Dr. Arndt Bode Vorsitzender des Direktoriums des Leibniz-Rechenzentrums

9 Jahresbericht 2009 des Leibniz-Rechenzentrums 3 1 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme 1.1 Kurse und Veranstaltungen Kursübersicht, Statistik 2009 Wie schon in den vergangenen Jahren wurden die Kurse gut angenommen, die vom LRZ zum Thema Hochleistungsrechnen angeboten wurden. Bei der Planung konnte stets davon ausgegangen werden, dass alle Teilnahmewilligen, die einen Platz im Kurs erhalten, diesen auch wahrnehmen würden. Dies darf beim übrigen Kursangebot leider nicht als selbstverständlich vorausgesetzt werden. Gerade bei den Kursen zu PCs und PC-Software ist der Unterschied zwischen der Zahl der Anmeldungen und der Zahl der Teilnehmer nach wie vor groß. Dies hat hohen Verwaltungsaufwand für diese Kurse zur Folge, müssen doch bei jeder Absage auf einen erteilten Kursplatz wieder alle organisatorischen Schritte für die Nachrücker durchlaufen werden. Es zeigte sich, dass das Interesse an Kursen zu den aktuellen Microsoft Office-Produkten nach wie vor groß war. Außerdem gilt immer noch, wie schon im letzten Jahresbericht formuliert: Vom Kursprogramm des LRZ wird einerseits Aktualität erwartet, die Akzeptanz der Anwender in Bezug auf neue Programmversionen andererseits hinkt dieser Erwartungshaltung häufig hinterher. Oft werden aus den unterschiedlichsten Gründen Programmversionen auch einfach übersprungen. Gerade bei den Microsoft Produkten neigen Anwender und Systemverantwortliche dazu, nur immer jede übernächste Version zu akzeptieren und zu installieren; und dies meist mit guten Gründen und einem zeitlichen Versatz - während auf die ersten Service Packs gewartet wird. Kurse zu PCs und PC-Software 2009 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Textverarbeitung mit Word 2007 (Kompaktkurs) Word 2007 lange Dokumente, wiss. Arbeiten MS-Excel 2007 (Kompakt- u. Fortsetzungskurs) PowerPoint 2007 (Kompaktkurs) Photoshop CS (Einsteigerkurs) Access SPSS (Spezialkurs) Insgesamt: Tabelle 1: Kurse zu PCs und PC-Software Unix-Kurse und Praktika 2009 Kurstitel Dauer Anzahl Stunden Teilnehmer Teilnehmer (Stunden) Kurse insgesamt angemeldet teilgenommen Einführung in die Systemverwaltung unter Unix Insgesamt: Tabelle 2: Kurse zum Themenbereich Unix

10 4 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Auch im Jahr 2009 wurde - zusätzlich zum regulären Kursprogramm - die vorhandene, moderne Infrastruktur im Hörsaal, den Seminar- und Kursräumen für andere Veranstaltungen genutzt. Softwarefirmen hatten die Gelegenheit, neue Produkte bzw. neue Versionen bekannter Produkte zu präsentieren. Dabei standen wieder Beispiele für die Nutzung in Forschung und Lehre im Vordergrund. Internet 2009 Kurstitel Dauer Anzahl Stunden Teilnehmer Teilnehmer (Stunden) Kurse insgesamt angemeldet teilgenommen Webdesign, Usability & Schreiben fürs Web Barrierefreies Webdesign Schattenseiten des Internet Praktische Tipps zur Vermeidung von Gefahren Insgesamt: Tabelle 3: Kurse zum Thema Internet Hochleistungsrechnen 2009 Kurstitel Dauer Anzahl Stunden Teilnehmer Teilnehmer (Stunden) Kurse insgesamt angemeldet teilgenommen Introduction to modern Fortran and associated tools Parallel Programming with dynamic languages High-Performance Computing with GPGPUs Programming of High Performance Computing Systems Wissenschaftliche 3D Animation mit Blender Einführung in die Remote Visualisierung Insgesamt: Tabelle 4: Hochleistungsrechnen Weitere Veranstaltungen 2009 Kurstitel Dauer Anzahl Stunden Teilnehmer Teilnehmer (Stunden) Kurse insgesamt angemeldet teilgenommen Train the Trainer Einführung in das Archiv- u. Backupsystem am LRZ Professioneller IT-Betrieb in mittleren und großen Umgebungen 3,5 1 3, Insgesamt: 17,5 3 17, Tabelle 5: Weitere Kurse

11 Jahresbericht 2009 des Leibniz-Rechenzentrums 5 Graphik und Visualisierung 2009 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Einführung in Virtual Reality Insgesamt: Tabelle 6: Weitere Kurse Vorträge Schattenseiten des Internet Die große Zahl der gemeldeten und selbst entdeckten Missbrauchsfälle zeigt (s. Abschnitt 1.9), dass das Sicherheitsbewußtsein im Bereich der virtuellen Welt des Internet noch deutlich besser werden muss. Deshalb veranstaltet das LRZ regelmäßig den Vortrag Schattenseiten des Internet Praktische Tipps zur Vermeidung von Gefahren vor Teilnehmern des Münchner Wissenschaftsnetzes (weitere Details und die Handouts der Vortragsfolien siehe security/gefahren/). Außerdem bietet das LRZ diesen Vortrag im Rahmen seiner Öffentlichkeitsarbeit Schulen und anderen interessierten Einrichtungen an. Dies ist möglich, da sich der Vortrag an Einsteiger auf dem Gebiet der Internet-Sicherheit richtet; für Eltern und Lehrer einerseits und Jugendliche ab 12 Jahren andererseits stehen angepasste Varianten zur Verfügung. Die beiden Schwerpunkte des Vortrags behandeln Problembereiche, die Kinder, Jugendliche und Erwachsene gleichermaßen betreffen: In den letzten beiden Jahren wird das Thema Abzocker im Internet relativ häufig in Presse und Fernsehen behandelt. Dennoch fallen allein in Deutschland jährlich mehrere Hunderttausend Internet-Nutzer auf die vielen unseriösen Angebote herein. Etwa die Hälfte der Opfer kennen ihre Rechte zu wenig und zahlen deshalb die geforderten Beträge zwischen 60 und 200 Euro, obwohl dies überhaupt nicht erforderlich wäre.

12 6 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Alle Nutzer des Internet unterliegen mehr oder weniger umfangreichen rechtlichen Pflichten. Ein Verstoß dagegen (z.b. gegen das Urheberrecht) kann mehrere Tausend Euro kosten! Leider kennen praktisch keine Jugendlichen und nur wenige Erwachsene diese Art von Gefahren. Im Jahr 2009 wurden durch diesen Dienst des LRZ an der Allgemeinheit mehr als 700 interessierte Zuhörer erreicht (Schulklassen und Eltern an mehreren Gymnasien). 1.2 Software-Versorgung für Rechnersysteme außerhalb des LRZ Die Versorgung der Hochschulen mit günstigen Lizenzen für Forschung und Lehre über das LRZ bietet große Möglichkeiten, die Ausgaben für Software so gering wie möglich zu halten. Im Berichtsjahr stand die Neuverhandlung des von der Firma Microsoft gekündigten Select-Vertrages an. Lizenzen für Microsoft-Software machen fast die Hälfte des Software-Umsatzes des LRZ aus. Nach langwierigen Verhandlungen konnten im Spätsommer Select Plus-Rahmenverträge mit Microsoft abgeschlossen werden, die es allen mit Forschung und Lehre befassten Einrichtungen des Bayerischen Staatsministeriums für Wissenschaft, Forschung und Kunst ermöglichen, Microsoft-Software auch weiterhin zu günstigen Konditionen über das LRZ zu beziehen. Gegenwärtig wird vom LRZ gemeinsam mit der Universität Würzburg die Ausschreibung eines Vertragshändlers, der die Kunden mit den Software- Produkten beliefert, organisiert. Außerdem wurden einige auslaufende Verträge mit Herstellern bzw. Anbietern weiterer Software (z. B. Ansys/Fluent, ESRI, LabView, SPSS) verlängert, neu abgeschlossen oder abgelöst, um die unkomplizierte und günstige Versorgung der Endkunden weiterhin sicherzustellen. Für Einrichtungen mit zentralem Einkauf besteht die Möglichkeit, die am meisten nachgefragten Softwarelizenzen online zu bestellen. Hierzu zählen die Münchner Universitätskliniken mit ihrem jeweiligen Zentraleinkauf, die Universität Augsburg, einige Fachhochschulen aus dem südbayerischen Raum sowie einige kleinere Einrichtungen. Welche Software von wem zu welchen Bedingungen über das LRZ bezogen werden kann, ist auf der Webseite dargestellt. Die umsatzstärksten Softwarepakete im letzten Jahr waren: Microsoft-Lizenzen im Rahmen der Select/Select-Plus-Verträge: im Jahr 2009 haben Kunden im Raum München in Höhe von etwas über Euro über das LRZ bestellt. Bayernweit lag das Volumen insgesamt im oberen sechsstelligen Bereich. Adobe- und Corel-Bestellungen wurden über das LRZ im Rahmen des CLP-Vertrages in Höhe von ca Euro abgewickelt. SPSS: im Raum München im oberen fünfstelligen Bereich, bayernweit über Euro. Bei vielen weiteren Produkten lagen die Umsätze im fünfstelligen Bereich. Novell- und Sophos-Produkte werden den bayerischen Universitäten und Hochschulen nach einem festen Kostenschlüssel bereitgestellt, daher gibt es an dieser Stelle keine Umsatzzahlen. 1.3 Benutzerverwaltung und Verzeichnisdienste Bei der Vergabe von Kennungen an Hochschuleinrichtungen und Studenten arbeitet das LRZ sehr eng mit den beiden Münchner Universitäten zusammen. Abschnitt gibt einen Überblick über die derzeit vergebenen Kennungen und ihre Verteilung auf die LRZ-Plattformen. In Abschnitt wird die Weiterentwicklung der im Rahmen des Projekts LRZ-SIM (Secure Identity Management) geschaffenen Infrastruktur beschrieben. Sie basiert auf dem Einsatz von LDAP-Servern und profitiert von der direkten Kopplung mit den LMU- und TUM-seitigen Hochschulverzeichnisdiensten. Im Rahmen des erfolgreich abgeschlossenen Projekts IntegraTUM (Abschnitt 1.3.3) hat das LRZ unmittelbar am Aufbau und Betrieb einer integrierten, hochschulübergreifenden Benutzerverwaltungs-Architektur und Verzeichnisdienst- Infrastruktur mitgewirkt. Ein weiteres sehr dynamisches Arbeits- und Forschungsgebiet ist die Authentifizierungs- und Autorisierungsföderation des DFN (DFN-AAI), in der das LRZ bereits als Dienstleister und sogenannter Identity-Provider für die LMU und TUM fungiert (Abschnitt 1.3.4).

13 Jahresbericht 2009 des Leibniz-Rechenzentrums Für LRZ-Systeme vergebene Kennungen An Hochschuleinrichtungen vergebene Kennungen Die folgende Tabelle gibt einen Überblick über die vom LRZ an Hochschuleinrichtungen (via Master User) vergebenen Kennungen, und zwar pro Plattform und mit Stand von Ende Einrichtung VPN Mail AFS Sun- Cluster Linux- Cluster PC Leibniz-Rechenzentrum Bayerische Akademie der Wiss. (ohne LRZ) Ludwig-Maximilians-Universität München Technische Universität München Hochschule München andere bayerische Hochschulen Öffentlich-rechtliche Einrichtungen sonstige Einrichtungen Kooperationsprojekte aus dem Grid-Bereich Nutzer des Bundeshöchstleistungsrechners Gesamt Tabelle 7: Vergabe von Kennungen für LRZ-Plattformen Die gegenüber dem Vorjahr deutlich kleineren Zahlen bei den Plattformen VPN, Mail, AFS und Sun- Cluster erklären sich dadurch, dass in 2009 eine großangelegte Datenbereinigungsaktion durchgeführt wurde, bei der alle Kennungen und Berechtigungen daraufhin überprüft wurden, ob sie noch benötigt werden. Die oben genannten Zahlen entsprechen also nun der tatsächlichen Nutzung. Nicht in der Tabelle enthalten sind die Kennungen für den Bundeshöchstleistungsrechner, die SGI Altix 4700, da es hier häufig Kooperationen gibt und daher keine klare Zuordnung zu einer Einrichtung möglich ist. Ende 2009 waren für diesen Rechner insgesamt Kennungen vergeben, davon 281 für Projekte aus dem Grid-Bereich An Studenten vergebene Kennungen Die Vergabe von Kennungen an Studenten erfolgt bei der Ludwig-Maximilians-Universität und bei der Technischen Universität gekoppelt mit der Vergabe von Kennungen für das Web-Portal Campus LMU bzw. das Campus-Management-System TUMonline. Für Studenten anderer Münchner Hochschulen erfolgt die Vergabe individuell und direkt durch das LRZ. Ende 2009 hatten knapp Studenten (Vorjahr: ca ) eine Kennung, die u.a. für Mailzwecke und für den Wähl- bzw. VPN-Zugang ins MWN genutzt werden konnte. Hier die Aufteilung auf die Hochschulen mit den meisten Kennungen:

14 8 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Hochschule Ludwig-Maximilians-Universität München Technische Universität München Hochschule für Musik und Theater München Hochschule für Fernsehen und Film München Akademie der Bildenden Künste München Hochschule für Philosophie München Verwaltungs- und Wirtschaftsakademie München FernUniversität Hagen Hochschule für Politik München sonstige Hochschulen Anzahl Kennungen Gesamt Tabelle 8: Vergabe von Kennungen an Studenten LRZ Secure Identity Management (LRZ-SIM) Mit dem Projekt LRZ Secure Identity Management wurde die Benutzerverwaltung des LRZ im März 2008 auf die Basis sicherer, verteilter Verzeichnisdienststrukturen umgestellt Umsetzung bisheriger Anforderungen und Entwicklungspotential Mit LRZ-SIM konnten mittlerweile viele teils schon seit längerer Zeit bestehende Anforderungen an die zentrale Benutzerverwaltung umgesetzt werden. Der Datenaustausch mit externen Benutzerdatenbeständen, insb. denen von LMU und TUM, erfolgt über Standard-Schnittstellen auf Basis des LDAP-Protokolls und erfordert keine aufwändigen Speziallösungen. Die Zuordnung von Benutzern bzw. deren Organisationen oder Einrichtungen zu den so genannten LRZ-Projekten kann in LRZ-SIM flexibel vorgenommen und geändert werden. Eine wesentliche Voraussetzung dafür war die Umstellung auf die neuen, nicht sprechenden LRZ-Kennungen. Das bisherige starre hierarchische Schema der alten Benutzerverwaltung, das beispielsweise für die aus ganz Deutschland stammenden Benutzer des Höchstleistungsrechners Sonderlösungen erforderte, konnte dadurch ohne Designbruch abgelöst werden. In LRZ-SIM konnten 2009 alle Kennungen mit Unterstützung der Master User personalisiert werden, d. h. es gibt keine anonymen Kennungen mehr wichtig im Hinblick auf Sicherheit und zur Prävention von Missbrauch. Kennungen werden aus Datenschutz- und Sicherheitsgründen auch nicht mehr wiederverwendet, also im Laufe der Zeit nur mehr von einer einzigen Person genutzt. LRZ-SIM kann über die Verwaltung der Kennungen für Rechner-Plattformen hinaus auch für die anderen Dienste des LRZ eingesetzt werden. So können beispielsweise die eigenen Benutzerverwaltungen des Mailsystems und TSM-Backups abgelöst oder integriert werden. Dadurch werden im technischen Bereich Redundanzen und Inkonsistenzen vermieden. Organisatorisch kann der erhöhte Aufwand durch die Mehrfachregistrierung der Benutzer sowohl auf Kunden- als auch auf LRZ-Seite beseitigt werden. LRZ-SIM stellt sich heute als eine moderne Identity&Access-Management-Lösung dar, in der insbesondere die folgenden Ziele verwirklicht sind: Durch Einsatz von Standardkomponenten (hier Novell edirectory und Novell Identity Manager) konnte ein großer Teil von Low-Level-Eigenprogrammierung vermieden, der Wartungsaufwand reduziert und der Zugang intern wie extern über das standardisierte und weit verbreitete Schnittstellen- Protokoll LDAP angeboten werden.

15 Jahresbericht 2009 des Leibniz-Rechenzentrums 9 Damit sind die technischen Voraussetzungen geschaffen worden, um zur Erfassung und Pflege von Daten auf externe Datenquellen (wie beispielsweise die hochschulweiten Verzeichnisdienste der beiden Münchner Universitäten, IntegraTUM und Campus LMU ) zurückgreifen zu können. Darauf aufbauend ist der Einsatz von Software für Identitätsföderationen wie Shibboleth möglich, um universitätsübergreifende Authentifizierungsmechanismen und Datenaustauschprozesse, beispielsweise im Hinblick auf die Virtuelle Hochschule Bayern, zu ermöglichen. Die Architektur ist flexibel genug, um mit den sich im Laufe der Zeit verändernden Anforderungen und neuen Aufgaben zurechtzukommen. Hierzu gehört insbesondere die Definition entsprechender Change-Management-Prozesse. Vorhandene und neue Provisioning-Prozesse konnten und können nahtlos umgesetzt und durch geeignete Workflow- und Triggermechanismen dauerhaft gewährleistet werden. LRZ-SIM hat alle Aufgaben und Daten der bisherigen zentralen LRZ-Benutzerverwaltung vollständig übernommen. Dabei konnte der Migrationsprozess für die bisher schon angeschlossenen Plattformen schrittweise und weitgehend transparent realisiert werden. Nun ist LRZ-SIM als flexible Plattform für das Identity-Management am LRZ auch für zukünftige Änderungen und Erweiterungen gerüstet Weiterentwicklung von Architektur und Implementierung Während die Kernarchitektur, wie sie im März 2008 in Produktionsbetrieb ging, beibehalten wurde, gab es 2009 im Detail etliche Weiter- und Neuentwicklungen sowohl beim Datenmodell als auch besonders beim Webportal (Id-Portal), bei den Konnektoren und bei den angebundenen Systemen. Als Kern der neuen LRZ-Benutzerverwaltung hat sich die Metadirectory-Architektur in den ersten zwanzig Monaten ihres Betriebs bewährt. Als Schnittstelle zwischen den vorhandenen Komponenten realisiert das Metadirectory mit seinen drei Satellitenverzeichnissen die technischen Aspekte der Datensynchronisations-Workflows, auf die die zugrunde liegenden Geschäftsprozesse abgebildet werden. Abbildung 1 zeigt die aktuelle logische Struktur der neuen zentralen Benutzerverwaltung. Drei Verzeichnisdienste dienen mit einem für den jeweiligen Zweck optimierten Datenschema der Anbindung der vielfältigen LRZ-Rechnerplattformen und des LRZ-Portals mit Management-Funktionalität sowie dem Datenaustausch mit den beiden Münchner Universitäten. Das Metadirectory im Zentrum koordiniert den Abgleich der Datenbestände über Konnektoren (dicke Pfeile). Angeschlossene Systeme können über LDAP-Verbindungen direkt die Datenbestände in den Verzeichnissen nutzen (dünne Pfeile). Änderungen werden innerhalb weniger Sekunden an alle angeschlossenen Systeme weitergegeben. Viele der früheren LRZ-internen Datenflüsse, die mit Verzögerungen von bis zu einigen Stunden verbunden waren, konnten dadurch verbessert werden. Zudem lassen sich Plattform- und Dienstberechtigungen nun wesentlich flexibler und feiner granuliert als vorher verwalten, so dass einige in den letzten Jahren notwendig gewordene Sonderlösungen ebenfalls abgelöst werden konnten Aktivitäten 2009 Die umfangreiche produktive Server-Infrastruktur von LRZ-SIM erforderte eine kontinuierliche Aktualisierung der eingesetzten Software, um bei Releases und Patches auf dem aktuellen Stand zu bleiben, und zwar sowohl auf Betriebssystem-Ebene (SuSE Linux) als auch auf Verzeichnisdienst-Ebene (Novell edirectory und neuerdings zusätzlich OpenLDAP) und auf IDM-Ebene (Novell Identity Manager, imanager und Designer). Um den unterbrechungsfreien Betrieb dauerhaft gewährleisten zu können, wurden einige Server nach Systemfehlern auch komplett neu aufgesetzt (Portal- und Authentifizierungssatellit) und um weitere Replikas auf VMware-Basis ergänzt. Im Rahmen des LRZ AK Continuity wurden die Directory-Dienste und ihre Abhängigkeiten erfasst. Virtualisiert wurden außerdem die Server des Id-Portals, des Load-Balancers für die Authentifizierungssatelliten sowie des Subversion-Servers für die Unterstützung der Entwicklungs- und Dokumentationsarbeiten. Parallel zu den produktiven Servern musste auch die Testumgebung kontinuierlich auf dem aktuellen Stand gehalten werden. Nahezu alle Testserver wurden virtualisiert. Erweiterungen im Id-Portal als auch Neuimplementierungen von Konnektoren wurden durchwegs zuerst in der Testumgebung entwickelt und wurden dort ausführlich mit Real-Life-Datensätzen erprobt.

16 10 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Abbildung 1 Architekturmodell der neuen LRZ-Benutzerverwaltung, Stand 2009 Das Id-Portal ist die nach außen am deutlichsten sichtbare Komponente der LRZ-Benutzerverwaltung und ermöglicht nicht nur Master Usern, alle Aufgaben rund um die Verwaltung der ihnen zugeteilten Kennungen effizient zu erledigen, sondern dient auch als Self-Service-Oberfläche für alle Benutzer. Viele Funktionen des Id-Portals konnten im Detail verbessert und benutzerfreundlicher gestaltet werden, nicht zuletzt auch durch das Feedback aus der täglichen Benutzungspraxis durch die LRZ-Hotline, die LRZ- Administratoren, die LRZ-Betreuer und die Master User. Zu nennen sind in diesem Zusammenhang neue Workflows für die Betreuer und Master User, die eine bessere Übersicht, mehr direkte Links und teils auch farbliche Markierungen bei nahenden oder überschrittenen Terminen bieten. Auch die stärkere Zusammenfassung von Eingabemöglichkeiten eine Person betreffend, oder die schnelleren Suchmöglichkeiten z.b. über die Einrichtungshierarchie erhöhten den Bedienbarkomfort des Portals entscheidend. Dadurch ist es etwa den Betreuern leichter möglich, gezielte und zeitnahe Unterstützung für die Master User und Kunden bei der Verwaltung ihrer LRZ- Projekte zu leisten. Auch bei der Datenqualität der in LRZ-SIM verwalteten Einträge konnten durch vielfältige Maßnahmen Verbesserungen erzielt werden: Durch eine groß angelegte Konsolidierungsaktion konnten die meisten der brach liegenden Kennungen identifiziert und gelöscht werden. Bisher anonyme Kennungen sind nun alle durch die Master User personalisiert, was nach aktuellem IT-Recht auch erforderlich ist. Die automatische Suche und umfassendere Anzeigen im Id-Portal helfen, Personen-Dubletten aufzufinden oder von vornherein zu vermeiden. Das Id-Portal erschwert nun auch die unerwünschte Weitergabe von Kennungen ( Recycling ) und meldet entsprechende Fälle an die Betreuer. Die Sammlung von Datenqualitäts-Prüfskripten wurde ständig erweitert. Die Skripte dienen z.b. dem Aufspüren von nicht personalisierten Kennungen, von Personen mit unverhältnismäßig vielen Kennungen und von Einträgen mit fiktiven Personendaten. Die korrekte Belegung von LRZ-IDs, die als Referenzen auf andere Einträge dienen, ist ein weiterer Kontrollbaustein. Übersteigt die Anzahl

17 Jahresbericht 2009 des Leibniz-Rechenzentrums 11 gefundener Datenqualitätsmängel festgelegte Grenzwerte, werden Betreuer bzw. Master User informiert. Quota und Verbrauchswerte werden mindestens täglich mit den von den Plattformen gemeldeten Werten abgeglichen und in den LDAP-Servern aktuell gehalten. Mit der Erhebung von Informationen, welche angebundenen Systeme und Dienste welche Attribute lesend oder schreibend verwenden, konnten nicht nur die Rechte der entsprechenden Proxy-User- Kennungen auf den LDAP-Servern eingeschränkt und so die Datensicherheit erhöht werden. Es wurde dadurch auch eine Informationsbasis geschaffen, um die Administratoren dieser Systeme und Dienste gezielter über geplanten Änderungen oder aktuelle Probleme informieren zu können Im Id-Server, der für die Vergabe von und Auskunft zu LRZ-IDs, Kennungen, uidnumbers und gidnumbers zuständig ist, wurden ebenfalls eine Reihe von Verbesserungen eingebaut. So wurden Erweiterungen für freie Benutzer- und Projektnamen, wie sie u.a. im Grid-Umfeld erforderlich sind, integriert. Fehlermeldungen wurden stärker differenziert, alle Ergebnisparameter typisiert und umfangreichere Tracing-Möglichkeiten integriert. Ein neues Webfrontend erlaubt nun auch direkte Id- Anfragen ohne Kenntnis der Programmierschnittstelle. Die Anbindung weiterer Dienste an LRZ-SIM, unterstützt durch die technischen Möglichkeiten des neuen Identity-Management-Systems, bildeten einen weiteren Schwerpunkt der Arbeit. Schon im Vorjahr war neben der Grundversorgung der LRZ-Plattfomen mittels Direktiven auch die direkte LDAP- Authentifizierung für die VPN-Einwahl, für die Nutzung des DocWeb-Gateways und für den Zugriff auf die LRZ-Netzdoku realisiert kam die Anbindung folgender Dienste neu hinzu: Die Linux-Arbeitsplätze wurden auf SIM-Authentifizierung umgestellt. Das WebDNS-Portal wurde als Plattform im Id-Portal sichtbar gemacht und auf LDAP- Authentifizierung für Hostmaster über die regulären LRZ-Kennungen umgestellt. Das Monitoring-System Cacti wurde als neue Plattform in SIM aufgenommen. Für das Netzverantwortlichen-Portal NeSSI wurde ein Link mit verschlüsselter, sicherer Information über die erfolgte Authentifizierung ins Id-Portal integriert. Der Mailserver für die externen Studenten konnte auf LDAP-Authentifizierung und die sonst übliche Direktiven-Versorgung umgestellt werden. Für die NAS-Filer wurde die automatische Quota-Setzung über die SIM-Plattform PC ermöglicht. Für die High-Performance-Computing-Plattformen wurde eine Funktionsbibliothek auf Basis im LDAP hinterlegter Regeln zur Autorisierung neuer Benutzer (u.a. mit Berücksichtigung der Nationalität) erstellt. Damit sind auch nachträgliche Datenqualitätschecks möglich. Ein neues Konzept wird das Löschen von HPC-Projekten regeln, unterstützt durch neue Attribute im Verzeichnis und Spalten in der HPC-Datenbank, um dauerhaft die Zuordnung von Kennungen auch zu ehemaligen Projekten verfolgen zu können. Die SIM-Daten konnten erfolgreich in das zukünftig am LRZ eingesetzte IT-Service-Management- Werkzeug iet ITSM übernommen werden. Für den Import von Studenten- und Mitarbeiterdaten von Campus LMU nach LRZ-SIM wurde die technische Schnittstelle zwischen der LRZ-Benutzerverwaltung und ihrem Pendant an der Ludwig- Maximilians-Universität grundlegend überarbeitet. An die Mitarbeiter ausgewählter Fakultäten können nun automatisch bestimmte Berechtigungen für LRZ-Systeme vergeben werden. Diese werden beispielsweise im Rahmen des LRZ-Angebots zum Desktop-Management, für den automatischen Zugang zu Compute-Servern wie dem Linux-Cluster für ausgewählte Einrichtungen, und im Rahmen internationaler Forschungsprojekte wie dem Large Hadron Collider am CERN benötigt. Vor der teils aufwändigen Neuprogrammierung der Konnektoren zwischen den Verzeichnissen war eine Reihe von Vorarbeiten zu leisten: Korrelation von bestehenden Personendaten der LMU mit denen in LRZ-SIM in Zusammenarbeit mit den Master Usern der LMU Physik und Biologie Spezifikation der automatisch zu importierenden Personendaten, der zu vergebenden Berechtigungen und der Zuordnung zu Projekten zusammen mit den IT-Verantwortlichen der betroffenen LMU-Einrichtungen

18 12 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Konsolidierung von Projekten und Verteilung der automatisch importierten Kennungen auf diese Projekte Einrichtung von Auffangprojekten sowie erweiterte Masteruser-Rechte zum Verschieben von Kennungen in andere Projekte Erweiterung des Datenmodells um neue Attribute, u.a. zur gleichzeitigen Verwaltung einer (Studenten-)Mailbox und einer (Mitarbeiter-)Weiterleitung Umsetzung der automatischen Plattform- und Kontingent-Zuweisung auf Basis von LMU-Gruppen Abstimmung der Änderungsrechte auf Kennungen zwischen Campus LMU und Id-Portal mit entsprechenden Read-only-Einschränkungen auf Seiten des Id-Portals. Ende 2009 konnte diese neue umfangreichere Kopplung der Verzeichnisdienste von LMU und LRZ mit vielen Automatismen für den Import von Rechten und Rollen schließlich erfolgreich produktiv geschaltet werden. Zusammenfassend kann festgestellt werden, dass auch das zweite Betriebsjahr des neuen Identity- Management-Systems LRZ-SIM wie erwartet eine Menge Entwicklungsarbeit sowohl für interne Verbesserungen als auch für die Anbindung weiterer Plattformen und Dienste mit sich brachte. Darin zeigten sich aber auch die flexible Erweiterbarkeit der Architektur und das Potential für die Nutzung der neuen technischen Möglichkeiten. Durch die aktive Teilnahme an bayern- und bundesweiten Arbeitskreisen zum Thema Metadirectorys konnten hochschulübergreifend Kompetenz und Wissen genutzt und die Optimierung in Details der Implementierung erreicht werden. Der Austausch von Konzepten und Erkenntnissen ist ein wichtiger Baustein dafür, dass das LRZ sowohl hinsichtlich der Anzahl der zu verwaltenden Benutzer als auch der zur Verfügung gestellten Dienste und Rechnerplattformen eine der im deutschen Hochschulumfeld aufwändigsten Identity-Management-Lösungen mit sehr hohen Anforderungen erfolgreich betreibt Planungen weiterer Anbindungen und Vorhaben 2010 Für die Produktivführung von Microsoft Exchange für LRZ-Kunden wurde ein detailliertes Konzept ausgearbeitet: Weiterleitungs-Adressen und Abwesenheits-Einstellungen sollen nach LRZ-SIM geholt, dort verwaltet und in eine eigenes Forwarder-Verzeichnis provisioniert werden. Ein Konnektor auf Basis des Novell Scripting Drivers wird den bisherigen AD-Konnektor ablösen. An Vorarbeiten wurde geleistet: Schema-Erweiterungen mit neuen Mail-Attributen samt Initialisierung Erweiterungen im Id-Portal um neue Workflows in den Self-Services und Anpassung an die neue erweiterte Schnittstelle zur Verwaltung von Mailattributen Provisionierung der LMU-Kennungen in einen separatem Teilbaum des MWN-Active Directorys Provisionierung des Mail-Forwarder-Verzeichnisses mit Daten der Testumgebung LRZ-SIM wird die eigene Benutzerverwaltung des TSM-Systems und des DATWeb-Portals vollständig ersetzen. Jedes Projekt kann für TSM-Nutzung freigeschaltet werden, Master User können selbst Kennungen zur TSM-Nutzung berechtigen. Der Prozess zur Deprovisionierung sieht vor, dass die Löschung von Kennungen mit aktiven TSM-Knoten verhindert wird. Die Integration von Grid-Kennungen wurde vorbereitet und prototypisch für einen Teil der DEISA- Kennungen durchgeführt. Die Teilnahme an den Grid-Verbünden setzt voraus, dass deren jeweilige Benutzerverwaltungsinfrastrukturen verwendet werden. Um den doppelten Datenpflegeaufwand sowohl in den LRZ- als auch den jeweiligen Grid-Systemen einzusparen und die damit verbundenen Fehlerquellen zu vermeiden, soll die SIM-Kopplung mit Grid-Systemen weiter ausgebaut werden. Die Konzeption zur Provisionierung der relevanten Teile des TUMonline-Datenbestands in die LRZ- Benutzerverwaltung wurde auf technischer Ebene konkretisiert. Neben noch zu klärenden datenschutzrechtlichen Aspekten wurde aus den Erfahrungen der TUMonline-Migration ein Weg gefunden, wie zwar die Identitäten (reale Personen) möglichst umfassend aus beiden Quellen konsolidiert werden können, dabei aber für bestehende Kennungen und die daran gebundenen Ressourcen (z.b. Mailadressen, Homedirectorys) ein für die Benutzer sanfter Übergang ohne Zeitdruck hin zu einheitlichen Kennungen möglich ist. Damit wird für alle TUM-Angehörigen die Pflege der Stammdaten einheitlich über TUMonline erfolgen und von dort übernommen werden können. Weitergehende Berechtigungen zu

19 Jahresbericht 2009 des Leibniz-Rechenzentrums 13 LRZ-Diensten werden dann nur noch den von TUMonline importierten und nicht den alten LRZ- Kennungen zugeordnet werden können. Wesentliche Langzeit-Aufgaben sind Monitoring und Reporting im operativen Betrieb sowie die gezielte Anpassung des Systems an neue und veränderte Anforderungen im Rahmen eines speziell auf die Anforderungen des Identity Managements ausgelegten Change Managements IntegraTUM-Teilprojekt Verzeichnisdienst Im Rahmen des DFG-geförderten Projekts IntegraTUM (http://portal.mytum.de/iuk/integratum) wurde eine integrierte IT-Infrastruktur für die TUM aufgebaut. Das vom LRZ durchgeführte zentrale technische Teilprojekt Verzeichnisdienste (TP LDAP) hatte dabei die Aufgabe, einen Hochschulverzeichnisdienst zu konzipieren und umzusetzen, über den aktuelle Informationen über die Identitäten und Autorisierungen von Hochschulangehörigen (Mitarbeiter, Studenten, Gäste) abgerufen und in angeschlossene Systeme eingespeist werden können. Auf Basis eines Rollenkonzepts werden nun die Daten selektiv an die jeweiligen Systeme weitergeleitet und ständig aktuell gehalten, so dass ein automatisches und sehr zeitnahes Anlegen, Modifizieren und schließlich auch Löschen von Accounts erreicht wird. Insbesondere die unverzügliche bzw. karenzzeitorientierte Deprovisionierung war aufgrund von Datenschutz-, Lizenz- und Benutzerrichtlinien eine wichtige Anforderung Weiterentwicklung von Architektur und Implementierung Prägend für das letzte Projektjahr 2009 war die vollständige Umstellung auf das Campus-Management- System TUMonline (https://campus.tum.de) als führendes Quellsystem, das nicht nur Studenten- und Personalverwaltung, sondern auch die früher als Übergangslösung implementierte IntegraTUM- Gästeverwaltung ablösen konnte. Die notwendige technische Umstellung wurde zudem für eine Optimierung des eingesetzten Datenschemas genutzt, um den angebundenen Zielsystemen nun auch diejenigen Daten im jeweils benötigten Format liefern zu können, deren Bedarf sich erst im Laufe des Produktivbetriebs in den letzten beiden Jahren entwickelt hatte. Nachdem sich mit Einführung von TUMonline auch einige Hochschul-Prozesse änderten, ergaben sich diverse Änderungen gegenüber der ursprünglich erstellen detaillierten Anforderungsanalyse. Bereits implementierte technische wie auch organisatorische Aspekte der Anbindung der übrigen Teilprojekte an den Verzeichnisdienst mussten neu geprüft werden. Dies betraf die Syntax, Struktur und Semantik der Daten selbst, die Einbettung in geänderte oder neue Hochschul-Prozesse, die vorhandenen Protokolle zur Übertragung der Daten mittels sog. Konnektoren, die erwünschte und technisch mögliche Synchronisationsfrequenz und nicht zuletzt auch die weitgehend automatisierten Korrektur- und Replay-Mechanismen in Fehlersituationen. Auch schon vor der Einführung von TUMonline erwies sich die Konzeption von Datenmodellen für den zentralen Verzeichnisdienst, d.h. von LDAP-Schemata für die IntegraTUM-Directorys, als ein evolutorischer Prozess, in dem sich das Datenmodell laufend an die nachträglich ermittelten Erfordernisse der Datenabnehmer anpassen musste. Die dritte, für die Provisionierung durch TUMonline ausgelegte Version des Schemas (Schema V3) stellt nun einen nahezu optimalen Kompromiss aus Datensparsamkeit, Universalität und Flexibilität der vorgehaltenen Daten dar. Ein besonderer Fokus lag auf der leichten Durchsuchbarkeit mit möglichst nur einem Filter für die Datenabnehmer und Kunden des Authentifizierungsdienstes. Das aktuelle Schema liegt hinsichtlich Syntax, Semantik, Datenherkunft, Datenkonvertierung und Soll-Verwendung spezifiziert und in Form von Schema-Dateien zur Konfiguration der Server-Software vor. Die interne Struktur des Verzeichnisdienstes (Directory Information Tree, DIT), die die Anordnung der Objekte im hierarchischen Verzeichnisdienst vorgibt, berücksichtigt verstärkt die Belange des Datenschutzes und der Datensicherheit über vererbte Zugriffsrechte, aber auch die Trennung von Administrations-, Benutzer- und Gruppendaten.

20 14 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Abbildung 2 IntegraTUM Verzeichnisdienst-Architektur V3 Bei der Verzeichnisdienstarchitektur waren die Aspekte Skalierbarkeit, Verfügbarkeit und Wartbarkeit zu berücksichtigen. Im Unterschied zu vielen vergleichbaren Projekten und in Analogie zum LRZ-SIM- Projekt basiert der IntegraTUM-Verzeichnisdienst nicht auf einem zentralen LDAP-Server, sondern auf einem Geflecht mehrerer Verzeichnisdienste, die die Daten in den jeweils benötigten Formaten bereitstellen und über ein Metadirectory untereinander abgleichen. Die obige Abbildung zeigt die logische Struktur dieser Architektur: Die Daten aus dem führenden Campus-Management-System TUMonline fließen direkt ins Metadirectory. Die Aggregation und Konsolidierung der Daten, beispielsweise von Studenten, die als studentische Hilfskräfte auch Mitarbeiter sind, ist bereits in TUMonline erfolgt. Konnektoren (dicke Pfeile in Abbildung 2) verteilen die Daten dann an weitere Verzeichnisdienste, an welche die Zielsysteme angeschlossen sind. Die Zuordnung der Zielsysteme zum jeweiligen Verzeichnisdienst basiert auf einer Gruppierung anhand der jeweils benötigten Datenformate, Datenmengen und Synchronisationsfrequenzen, um eine möglichst gleichmäßige Auslastung des Gesamtsystems zu erzielen. Die im Bild dargestellten dünnen Pfeile entsprechen LDAP-Abfragen, die die Zielsysteme selbst initiieren Aktivitäten 2009 Aufgrund der Umstellung des Metadirectory-Schemas für die Anbindung an TUMonline wurde auch eine neue Server-Infrastruktur erforderlich. Alle Server wurden auf Basis des zentral am LRZ betriebenen VMware ESX-Server-Clusters virtualisiert aufgesetzt. Darüber hinaus waren Neuimplementierungen und Überarbeitungen der systemspezifischen Konnektoren sowie erneute zielsystem-individuelle Tests für die V3-Infrastruktur erforderlich. Die entsprechende neue Testumgebung wurde ebenfalls auf virtuellen Servern aufgebaut. Das Deployment-Konzept für Hardware, Software und Konfiguration wurde auch für die dritte Verzeichnisversion (V3) vollständig umgesetzt. Dabei wurden insbesondere die Aspekte Replikation, Standortwahl und System- und Dienstsicherheit berücksichtigt. Die zentralen Maschinen sind dabei

21 Jahresbericht 2009 des Leibniz-Rechenzentrums 15 ausreichend dimensioniert, um in den kommenden Jahren auch weitere Systeme noch problemlos integrieren zu können. Zudem sind die Maschinen redundant aufgesetzt und über je einen Service Load Balancer (SLB) angebunden. Damit wird nicht nur Ausfallsicherheit erreicht, sondern auch Serversicherheit, denn die Verzeichnisse sind von außen nur per LDAP über den SLB erreichbar (siehe Abbildung 3). Der Management-Zugang über SSH und IDM-Tools ist nur über ein separates lokales Netz möglich, auf dem zudem noch eigene restriktive Routing-Policies realisiert werden können. Abbildung 3 Service Load Balancer für Ausfall- und Serversicherheit für IntegraTUM-Directorys Das Datenmodell für die Speicherung von Personendaten und Autorisierungsgruppen wurde erneut verfeinert. Dieser Schritt wurde primär durch die Einführung von TUMonline als neuem Campus Management System motiviert, das nunmehr die Systeme HIS SOS und SAP HR als Datenquellen für das Metadirectory vollständig abgelöst hatte. Darüber hinaus konnte die Gelegenheit genutzt werden, das Schema stärker an sich inzwischen in Deutschland abzeichnende Best Practices anzupassen, die sich durch Initiativen wie SCHAC und die DFN-AAI ergeben. Die Verfahrensbeschreibung für die Speicherung der Daten in den einzelnen Verzeichnisdiensten wurde für die ermittelten Datenflüsse und das aktuelle Architekturkonzept angepasst und vom Datenschutzbeauftragten der TUM für den Endausbau der Verzeichnisdienste genehmigt. Mit dem neuen Schema V3 wurde auch eine Anpassung der Konnektoren zu den Satellitenverzeichnissen für die abnehmenden Systeme erforderlich. Hier sind insbesondere die Teilprojekte E-Learning und Bibliothek zu nennen, die auf dem Applikations-Satellitenverzeichnis eine an das vorige Schema angelehnte Datenstruktur provisioniert bekommen bzw. die bei der Datentransformation in den Zielsystemen (hier der OCLC IDM-Connector) unterstützt wurden. Im Zuge der Provisionierung der fakultäts- und lehrstuhleigenen CIP-Pools werden vom IntegraTUM-Verzeichnisdienst aus jeweils bedarfsgerecht fakultätseigene Verzeichnisdienste mit den benötigten Daten beliefert, wobei die Fakultäten intern die Verteilung dieser Daten auf weitere Verzeichnisdienste und einzelne lokale Server übernehmen. Für die Windows-Systemadministration

22 16 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme wurde inzwischen ein noch stärker integriertes Konzept umgesetzt, bei dem die Lieferung der Benutzerdaten nur an ein einziges Microsoft Active Directory erforderlich ist. Viele Einrichtungen können jedoch zur Authentifizierung ihrer Benutzer an lokalen Rechnern und Diensten direkt den zentralen Authentifizierungsserver nutzen. So konnten im Laufe des Jahres 2009 überdurchschnittlich viele neue Kunden für diesen Authentifizierungsdienst gewonnen werden, und das obwohl Mitte 2009 der Umstieg auf die neuen Verzeichnisse (und damit auf den neuen Authentifizierungsdienst mit neuem Schema V3) für alle Kunden erforderlich war. Zu den neuen Kunden zählen Lehrstühle und Einrichtungen aus allen TUM-Fakultäten, insbesondere auch Informatik, Mathematik, Medizin, Sport, Wirtschaftswissenschaften sowie Bau- und Vermessungswesen. Die Ende 2007 in den Produktivbetrieb überführte automatische Dateneinspeisung in das MWN-weite Microsoft Active Directory wurde bezüglich der für den Betrieb von Microsoft Exchange benötigten Daten und bezüglich gruppenbasierter Autorisierungsprozesse verbessert. Dadurch konnten insbesondere auch die Lizenzbedingungen für die Nutzung der Terminalserver-Farm der TUM Physik mit sehr geringem Aufwand umgesetzt werden. Mit der Bereitstellung und Datenversorgung eines hochverfügbaren OpenLDAP-Verzeichnisdienstes für das Mailrouting konnte ein weiterer zentraler Meilenstein des Projekts erreicht werden. Die seit Projektbeginn mehrmals konzipierte, aber nie implementierte Gruppenverwaltung ist nun in Abstimmung mit dem TP LDAP im TUMonline-Webportal verfügbar. Die auch manuelle Zuordnung von Kennungen zu Gruppen erfolgt dabei über Rollen (in TUMonline-Sprechweise Funktionen ). Jede Rolle bzw. Funktion wird pro organisatorischer Einheit in Form einer Gruppe ans Metadirectory provisioniert, und zwar mit eindeutigem Namen gemäß dem 2007 erstellten ADS-Namenskonzept. Die Nutzung dieser Gruppen in angebundenen Systemen erfolgt momentan bereits im zentralen Active Directory für die dort Dienstbeauftragten. Weitere Systemberechtigungen, beispielsweise zur Benutzung von Rechnerpools, müssen nun nicht mehr individuell vergeben werden, sondern können auf Gruppenzugehörigkeiten wie alle Studenten der Fakultät für Informatik basieren. Zusätzlich zu den Verzeichnisdiensten wurden die Implementierung weiterer Dienste und Maßnahmen voran gebracht: Zur Inbetriebnahme des Campus Management Systems TUMonline und der damit verbundenen Einführung neuer Hochschulprozesse wie der Online-Bewerbung für Studenten wurden mehrere neue Webservices implementiert, die nun auch die Abfrage bestehender Kennungen, die automatisierte Vergabe von gidnumbers sowie die Datensatzkorrelation mit Bestandsdaten im Verzeichnisdienst unterstützen. Im Active Directory MWN-ADS wurde die automatische LRZ-Berechtigungsvergabe auf VPN, PC und NAS-Filer für alle TUM-Angehörigen realisiert. Dies führte zu einer spürbaren Entlastung der Master User (Kennungsanlegen) und der LRZ-Hotline (Passwortsetzung). Der Betrieb der Server des Trouble-Ticket-Systems OTRS, das TP LDAP eingerichtet hatte, wurde an die Rechnerbetriebsgruppe der TUM Informatik übergeben. Anfängliche Schwierigkeiten bei der Etablierung der neuen Workflows zwischen TUM und LRZ bzw. der jeweiligen Incident- Management-Systeme konnten erfolgreich behoben werden Kooperationen und Ausblick Die Kooperationen mit anderen Hochschulen und deren Rechenzentren wurden fortgesetzt und weiter ausgebaut: Im ZKI-Arbeitskreis Verzeichnisdienste und im Arbeitskreis Meta-Directories der bayerischen Rechenzentren wurden die im Rahmen des Teilprojekts entstandenen Konzepte und Werkzeuge mit anderen Hochschulen diskutiert. Dabei spielen die entwickelten LDAP-Schemata, die konzipierten Konnektoren, die Verzeichnisdienstarchitektur und die angestrebten Optimierungen der Hochschulprozesse eine zentrale Rolle. Eines der diskutierten Datenschemata (dfneduperson) ist mittlerweile zum Quasi-Standard für Studierendendaten in der DFN-AAI-Föderation geworden. Die Ergebnisse aus TP LDAP und die erfolgreiche Übernahme der aufgebauten Verzeichnisdienst- Infrastruktur in den Produktivbetrieb wurde auch auf dem ZKI-Arbeitskreistreffen im Oktober 2009 in Dresden ausführlich vorgestellt. Einige Universitäten (u.a. Würzburg und Dresden) waren an Implementierungsdetails, speziell an der Identitätskorrelation sowie an Werkzeugen zur Schema- Verwaltung, interessiert und wurden mit entsprechender selbst entwickelter Software versorgt. Mit der

23 Jahresbericht 2009 des Leibniz-Rechenzentrums 17 Universität Jena wurden Konzepte und Probleme bei der Einführung der Bibliotheks-IDM-Software erörtert. Mit der Universität Augsburg wurden Provisionierungsstrategien über Webservices diskutiert. Schließlich war das LRZ Gastgeber des IntegraTUM-Abschlussworkshops am 24. September Der Workshop stieß bei hoher Teilnehmerzahl inhaltlich und fachlich auf großes Interesse. Im Tagungsband (A. Bode, R. Borgeest: Informationsmanagement in Hochschulen, 466 pp., Springer Verlag Heidelberg 2010) ist TP LDAP mit einer überdurchschnittlich hohen Zahl von Beiträgen vertreten. Mit dem planmäßigen Auslaufen der DFG-Förderung im Herbst 2009 wurde die Verzeichnisdienst- Infrastruktur V3 vollständig in den produktiven Regelbetrieb überführt. Aktuell laufen Planungsgespräche zur Festlegung der langfristigen TUM- und LRZ-seitigen Zuständigkeiten; im Vordergrund steht dabei der Aufbau eines Betriebs- und Entwicklungsteams, dessen Kompetenzen sich sowohl auf die technischen Aspekte des Campus-Management-Systems TUMonline als auch die Identity-Management-Infrastruktur erstrecken AAI-Föderationen: Shibboleth Identity Provider Das LRZ betreibt seit 2008 im Rahmen der Authentifizierungs- und Autorisierungsinfrastruktur des DFN- Vereins (DFN-AAI) auf Basis der Software Shibboleth (https://www.aai.dfn.de/der-dienst/foederation) die Identity-Provider-Dienste für die TUM, die LMU und das LRZ selbst. Die Shibboleth-Infrastruktur erlaubt die universelle Nutzung diverser E-Learning-, Portal-, Verlags- und Softwarelizenzangebote mit der lokalen IntegraTUM-, CampusLMU- bzw. LRZ-Kennung und bietet darüber hinaus automatisch die Möglichkeit des Single Sign-On. Die Zahl der Angebote nahm dabei auch im vergangenen Jahr stetig zu. So hat die LMU eine Reihe ihrer E-Learning-Angebote in die DFN-AAI-Föderation eingebracht, u.a. Casus, itunesu, Moodle und OLAT. Zusammen mit dem E-Learning-Projekt der TUM, electum, wurde die notwendige Erweiterung des eingesetzten Learning-Management-Systems, im-c Clix, erreicht, so dass auch dieses E-Learning- Angebot nahtlos in die DFN-AAI integriert ist. Und schließlich bietet die virtuelle Hochschule Bayern (vhb) seit dem Wintersemester 2009/10 eine auf dieser Technologie basierende Studentenregistrierung an, die im Pilotbetrieb bereits von der TUM genutzt wird. Sie löst relativ umständliche, proprietäre Verfahren wie das postalische Einsenden von Immatrikulationsbestätigungen ab und ermöglicht interessierten Studenten somit einen sehr kurzfristigen Zugang zum Angebot der vhb. Neben diesen deutschlandweiten Aktivitäten beteiligt sich das LRZ zudem an einer im Rahmen des Grid- Projekts DEISA geschaffenen europäischen Rechenzentrumsföderation, die nahtlosen Zugriff auf die externen Rechen- und Speicherressourcen mit der eigenen lokalen Kennung ermöglichen wird Aktivitäten 2009 Dem schnellen Anstieg der Nutzung der Föderations-Infrastruktur musste seitens des LRZ durch eine umfangreiche Aktualisierung und Erweiterung der Identity-Provider-Kapazität Rechnung getragen werden. In diesem Zusammenhang wurden folgende Aktivitäten durchgeführt: Virtualisierung: Die am LRZ betriebene VMware-ESX-Infrastruktur erlaubte die Einrichtung dreier neuer virtueller Server, die auf SLES11-Basis die Shibboleth-Dienste erbringen. Sie lösten die bisherige physische Maschine ab, auf der alle drei Identity-Provider für TUM, LMU und LRZ in einem gemeinsamen Applikationsserver liefen. Software-Update: Mit den neuen Servern wurde gleichzeitig ein neuer, stabilerer Applikationsserver (Tomcat 6) sowie die aktuellste Shibboleth-Version (2.1.5) installiert. Dies erlaubt weiterhin einen stabilen, unterbrechungsfreien und performanten Betrieb der drei Identity-Provider. Daneben erfolgte der Umstieg auf die Attribut-Auskunfts- und -Freigabe-Komponente uapprove, die die bisherige Komponente ARPViewer ablöste. uapprove zeigt dem Benutzer vor der Authentifizierungsfreigabe für einen neuen Service Provider, welche Attribute an den Service-Provider im Fall der Freigabe übermittelt würden. Der Benutzer hat so die Möglichkeit, die Datenweitergabe providerbezogen zu akzeptieren oder auch abzulehnen, was einen wesentlichen Baustein im Datenschutz und in der Selbstauskunfts-Funktionalität in AAI-Föderationen darstellt.

24 18 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Verfügbarkeit: Neben der Standard-Serverüberwachung des LRZ wurde das selbst entwickelte Verfügbarkeits- und Restart-Programm für die drei neuen IdP-Maschinen angepasst und um zusätzliche Heuristiken der Fehlererkennung aus Log-Dateien erweitert. Auf Attribut-Ebene mussten Anforderungen einzelner Service-Provider nachgezogen werden. Dies erfolgte einerseits für die LMU-Learning-Angebote, die eine konstante Attributlieferung während und nach der Inbetriebnahme des neuen Campus LMU -Konnektors (siehe Abschnitt ) benötigten, und andererseits für die TUM-Learning-Plattform, für die übergangsweise die komplette Attribut-Palette nachgebildet wurde, die die Plattform bisher über den direkten LDAP-Import aus dem IntegraTUM-Applikationssatelliten erhielt Ausblick 2010 In einer eigenen Föderation bietet der DFN die Short Lived Credential Services (SLCS, https://slcs.pca.dfn.de/gridshib-ca) für Grid-Dienste an, die bisher nur den LRZ-Benutzern zur Verfügung stehen. In diese Föderation sollen baldmöglichst auch die Identity-Provider für TUM und LMU aufgenommen werden. Die Virtuelle Hochschule Bayern (vhb) wird möglicherweise Unterstützung bei der Umstellung von Registrierung, Kurs-Anmeldung und Kurs-Login auf die Shibboleth-Authentifizierung im Rahmen der DFN-AAI-Föderation brauchen. Auch bei den gehosteten Instanzen der Open-Source E-Learning- Software Moodle am LRZ wird Beratungsbedarf zu Shibboleth erwartet. In absehbarer Zeit wird eine nochmalige Kapazitätserweiterung der Identity-Provider erforderlich sein. Angestrebt werden sollte dabei die redundante Auslegung mit je zwei Servern als IdP-Cluster, was weitere Vorteile für die Verfügbarkeit und Performance sowohl in Fehlersituationen als auch bei Wartungsarbeiten bringen wird. Erfahrung hierzu gibt es bereits in den Metadirectory-Arbeitskreisen , Web-Dienste und Datenbanken Services Produktivführung von Exchange für die TU München Herausragendes Ereignis des Jahres 2009 im Mailbereich war der erfolgreiche Abschluss des Integra- TUM-Projekts mit der TUM-weiten Produktivführung von Microsoft Exchange. Jeder TU-Angehörige kann nun durch einen entsprechenden Self Service von TUMonline selbst einstellen, ob an ihn adressierte Mails an den neuen Groupware-Server oder den bisherigen mytum-mailserver ausgeliefert oder an eine externe Adresse weitergeleitet werden sollen. Zur Realisierung dieses benutzerbezogenen Routings wurde ein so genannter Forwarder aufgebaut, der alle Mails für alle über TUMonline verwalteten Domains entgegennimmt (u.a. für tum.de und mytum.de) und dann anhand eines dedizierten Directories entscheidet, wohin die Mails für einen Benutzer zugestellt werden sollen. Als Verzeichnisdienst für Exchange dient das MWN-weite Active Directory ads.mwn.de, das auch für die IntegraTUM-Teilprojekte Datenspeicher und Systemadministration verwendet wird. Die Benutzerobjekte werden aus dem IntegraTUM Meta-Directory dorthin provisioniert. Der Exchange-Service wurde mandantenfähig ausgelegt, so dass er auch von anderen Einrichtungen im MWN genutzt werden kann, ohne dass es zu Datenschutzproblemen kommt. Die TUM als Ganzes ist ein Mandant, die Mandanten sind hermetisch voneinander abgeriegelt. Alle weiteren Mandanten neben der TUM sollen über das zentrale Identity Management des LRZ, LRZ-SIM (Secure Identity Management), ins Active Directory provisioniert werden. Diese Anbindung ist für Anfang 2010 geplant. Bei Bedarf können dann durch die Exchange-Administratoren am LRZ auch mandantenübergreifende Gruppen gebildet werden, etwa für Kooperationen zwischen LMU und TUM. Um Exchange als zentrale Mail- und Groupware-Lösung der TUM zu etablieren sind noch Schnittstellen und Web-Oberflächen zur dezentralen Administration zu entwickeln, die es den Administratoren von Einrichtungen ermöglichen Funktionsobjekte (z.b. für shared Mailboxen, Mailverteiler und Ressourcen wie Räume, Geräte usw.) zu verwalten.

25 Jan Mrz Mai Jul Sep Nov Jan Mrz Mai Jul Sep Nov Jan Mrz Mai Jul Sep Nov Jan Mrz Mai Jul Sep Nov Jahresbericht 2009 des Leibniz-Rechenzentrums Statistiken Spam- und Virenabwehr Das Gros der Spam- und Viren-Mails (ca. 99,5%) wird bereits von den Mailrelays, die für die Annahme von s aus dem Internet zuständig sind, durch die dort implementierten Abwehrmechanismen abgewiesen. Die angenommenen s werden von den Mailrelays an Scan-Rechner weitergeschickt. Dort werden Viren-Mails ausgefiltert (und die Empfänger darüber informiert) und die verbleibenden E- Mails markiert, ob es sich vermutlich um Spam-Mails handelt oder nicht. Diese Markierung kann dann dazu verwendet werden die betreffenden s durch Konfiguration entsprechender Regeln im eigenen Mailprogramm auszufiltern. In Abbildung 4 ist die Entwicklung von ausgefilterten Viren-Mails, markierten Spam-Mails und regulären erwünschten s (Ham-Mails) für die Jahre 2006 bis 2009 graphisch dargestellt. Dabei sind nur die s berücksichtigt, die von den Mailrelays angenommen wurden. Wie man sieht, ist der Anteil der Ham-Mails seit Jahren relativ konstant. Dafür ist auch 2009 der Anteil an Viren-Mails noch weiter gefallen, in der Graphik kann man ihn schon nicht mehr erkennen. Die Werte liegen bei ca. 80 erkannten Viren pro Tag (Vorjahr: 130) Ham Spam Viren Abbildung 4 Monatliches Ham-, Spam- und Virenaufkommens in den Jahren 2006 bis Mailhosting (virtuelle Mailserver) Das LRZ bietet Hochschulen und hochschulnahen Einrichtungen, die keinen eigenen Mailserver (Message Store mit POP/IMAP-Zugriff) betreiben wollen, an, den Maildienst am LRZ zu hosten. Es wird dann eine virtuelle Maildomain eingerichtet, in der sich der Name der betreffenden Einrichtung widerspiegelt (z.b. jura.uni-muenchen.de) und Angehörige dieser Einrichtungen erhalten entsprechende Mailadressen. Ende 2009 waren am LRZ 228 (Vorjahr: 225) virtuelle Mailserver eingerichtet. Eine Aufteilung auf die Hauptnutzer ist der folgenden Tabelle zu entnehmen: Einrichtung Ludwig-Maximilians-Universität München Technische Universität München Bayer. Akademie der Wissenschaften (inklusive LRZ) andere Hochschulen und hochschulnahe Einrichtungen Virtuelle Mailserver Gesamt 228

26 20 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Nutzung der Message-Store-Server Ende 2009 gab es Mailboxen (Vorjahr: ) auf einem der fünf Message Stores (POP/IMAP- Server) des LRZ. Nachfolgend eine Aufteilung nach Servern bzw. Benutzergruppen: POP/IMAP-Server für Mitarbeiter der vom LRZ bedienten Einrichtungen (Mailserver mailin ): Ludwig-Maximilians-Universität München Technische Universität München Bayer. Akademie der Wissenschaften (inklusive LRZ) Hochschule München 254 andere bayerische Hochschulen 207 andere wissenschaftliche Einrichtungen die Fakultät Physik der Technischen Universität München das mytum-portal der Technischen Universität München Studenten der Ludwig-Maximilians-Universität München (Campus LMU ) Studenten anderer Münchner Hochschulen Anzahl Benutzer Gesamt Nutzung des Exchange-Dienstes Im Jahr 2009 wurde der Benutzerbetrieb für den Exchange-Dienst aufgenommen, zunächst beschränkt auf die im Rahmen des IntegraTUM-Projekts realisierte Anbindung der TU München sowie einige Pilotbenutzer an der Bayerischen Akademie der Wissenschaften und am LRZ selbst. Ende 2009 gab es auf dem Exchange-Cluster Mailboxen, die sich wie folgt verteilten: Einrichtung Technische Universität München Bayerische Akademie der Wissenschaften (ohne LRZ) Leibniz-Rechenzentrum Exchange- Mailboxen Gesamt Nutzung von -Verteilerlisten Das LRZ bietet seinen Nutzern die Möglichkeit eigene -Verteilerlisten einzurichten (auf Basis des Programms Majordomo). Ende 2009 gab es 661 Listen (Vorjahr: 593), die sich wie folgt verteilten: Einrichtung Ludwig-Maximilians-Universität München Technische Universität München Bayer. Akademie der Wissenschaften (inklusive LRZ) andere Hochschulen und hochschulnahe Einrichtungen - Verteilerlisten Gesamt 661

27 Jahresbericht 2009 des Leibniz-Rechenzentrums Webdienste Content-Management für das LRZ selbst und für die BAdW Das Content-Management-System Fiona der Fa. Infopark wird seit Mitte 2007 für die Verwaltung der Inhalte des Webauftritts der Bayerischen Akademie der Wissenschaften verwendet. Im April 2009 wurde auch der Webauftritt des LRZ auf dieses System umgestellt und dabei vor allem gestalterisch, aber auch inhaltlich überarbeitet Relaunch des Webauftritts des LRZ Seit Ende April 2009 präsentiert sich das LRZ auf seinem Webauftritt in neuem Gewand. Am auffälligsten für die Nutzer waren die Anpassungen an den Zeitgeschmack: kleinere serifenlose Schrifttype, gegliedertes Browserfenster, Grafik im Seitenkopf und sachlicher wirkende Farbgestaltung. Die neue Gestaltung erweitert die Navigationsmöglichkeiten des Benutzers deutlich: in einer waagerechten Menüleiste findet er die wichtigsten umgebungsunabhängigen Links, und ein zusätzlicher Balken am linken Rand leitet ihn zu thematisch verwandten Artikeln. Die stark funktionale Ausrichtung, nach der alle Gestaltung sich der Information unterzuordnen hat, wurde beibehalten auch jetzt noch wirkt manches eher spartanisch im Vergleich zu mancher kommerziellen Seite. Dem Ziel der Barrierefreiheit, also der möglichst unbehinderten Nutzbarkeit auch durch Menschen mit visuellen oder anderen Einschränkungen, kommt der neugestaltete Webauftritt deutlich näher als der bisherige. Möglich wurde all das durch die Einführung des Content-Management-Systems Fiona der Berliner Firma Infopark. Fiona basiert auf einer vielparametrig konfigurierbaren Datenbank für die Inhalte; dabei wurde die Datenmodellierung, wie sie bisher schon der Verwaltung der Daten zugrundelag, weitgehend übernommen, aber auch noch deutlich erweitert. Die Gestaltung der Seiten ergibt sich dann aus einem Zusammenspiel von Webseitengenerierung durch Fiona aufgrund von Mustern, die vom LRZ erstellt wurden, und von Stylesheets, die aus dem für geringes Entgelt erhältlichen Framework YAML generiert wurden. Die im letzten Absatz beschriebene Optik ist also eher YAML anzurechnen als Fiona; letzteres aber sorgt dafür, dass feste Regeln für alle Artikel durchgesetzt werden, ohne die eine einheitliche Gestaltung von Tausenden von Webseiten überhaupt nicht zu bewältigen wäre. Das geht von der Erfassung von Metadaten über den Artikel über die Überprüfung der Verfügbarkeit von Linkzielen bis zur Berücksichtigung der Sprache, in der der Artikel verfasst ist. Durch die Verwendung eines Editors wird normgerechtes HTML garantiert, wie es sowohl für die Seitengestaltung als auch für die Barrierefreiheit unerlässlich ist. Vor allem aber werden die Autoren von der Notwendigkeit befreit, die Seiten selbst in HTML formulieren zu müssen. Die bisherigen Inhalte des Webservers wurden zum großen Teil in einem automatisierten Verfahren übernommen. Dabei hat es sich als entscheidend erwiesen, dass schon im bisherigen LRZ-eigenen Content- Management-System, dem Publisher, systematisch Metadaten erfasst und mit dem Artikel zusammen verwaltet wurden. Die Metadaten der zu übertragenden Artikel wurden nach festen Regeln an das neue Datenmodell angepasst und mit nach Fiona importiert. Bei dieser Gelegenheit wurden die HTML-Texte durch das frei verfügbare Programm tidy automatisiert von Abweichungen von der HTML-Norm befreit. Diese Maßnahme, von der zunächst nicht klar war, ob sie mehr Nutzen oder Schaden anrichten würde schließlich ist ja bei einem Fehler meist nicht klar, welche Änderung wirklich eine Verbesserung ist, hat sich aber schließlich sehr bewährt. Die Hauptarbeit wurde am Ende nicht von den Artikeln verursacht, die sich genau an die Regeln des Publishers gehalten hatten, sondern von den vielen Hunderten von Dateien, für die Sonderlösungen gefunden worden waren. Hier ging es darum, einerseits die Information im Rahmen des neuen Systems wieder zur Verfügung zu stellen, dabei aber nicht wieder eine vergleichbare Anzahl von Ausnahmen zu schaffen. Die Übernahme aller alten Artikel bis auf die, deren Überholtheit auf den ersten Blick auffiel, hatte natürlich den Vorteil, dass die Information sofort komplett zur Verfügung stand, hat dafür aber den dringend nötigen Hausputz auf später verschoben. Eine Besonderheit im Webauftritt des LRZ ist es, dass nur ein kleiner Anteil an der dargestellten Information ihrer Natur nach systematisch organisiert und dabei ganz eindeutig aktuell oder veraltet ist, so wie etwa der Produktkatalog eines Kaufhauses oder das Vorlesungsverzeichnis einer Hochschule. Vielmehr handelt es sich einerseits um Fachartikel sehr unterschiedlicher Ausführlichkeit, die ganz allmählich veralten, und andererseits um viele zusätzliche Daten, für die es keine überall anwendbaren Ordnungskriterien gibt. Die neuen automatisch eingefügten Navigationsmöglichkeiten erleichtern zwar die Orientierung; die Analyse, welche Nutzer welche Informationen brauchen

28 22 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme und wie sie sie dann finden, ersetzen sie jedoch nicht. Diese Arbeiten der inhaltlichen Redaktion und auch der Anpassung ans Medium Web manche Artikel haben immer noch die Gestalt von Umdrucken anstelle von Webseiten kann kein Programmsystem den fachkundigen Menschen abnehmen. Hier ist noch viel zu tun, wenn der neue Webauftritt sich nicht nur durch neue Optik, sondern vor allem durch bessere Nutzbarkeit auszeichnen soll. Die Voraussetzungen dafür sind jetzt geschaffen Unterstützung der Redakteure des Webauftritts der BAdW Auch im Berichtsjahr lag nicht nur der Betrieb der Fiona-Software und der zugrundeliegenden Systeme, sondern auch die Unterstützung der Redakteure aus der BAdW und Anpassungen der Konfiguration an deren Wünsche beim LRZ. Hervorzuheben ist besonders die Schulung von Mitarbeitern der BAdW in der Nutzung und Konfiguration dieser Software Webhosting Entwicklungen Das Webhosting am LRZ erlaubt eine vielfältige Nutzung von einer einfachen Präsentation von Webseiten bis hin zu interaktiven Webumgebungen für Content-Management, Portale, Blogs etc. Ziel ist dabei immer, möglichst weitgehend auf die Bedürfnisse und Wünsche der Nutzer einzugehen. Im Berichtsjahr gab es die folgenden Arbeitsschwerpunkte Content-Management-System Typo3 für die TUM In Zusammenarbeit mit dem Medienzentrum der TUM wird ein Konzept erarbeitet und implementiert, das es sämtlichen Fakultäten und Einrichtungen der TUM ermöglichen soll, ihren Webauftritt mit dem frei verfügbaren Content-Management-System Typo3 zu realisieren. Ziel ist dabei neben einem einheitlichen Aussehen aller Webauftritte (Corporate Design) auch ein effizienter Einsatz von technischen und personellen Ressourcen durch Konzentration und gemeinsame Arbeit an einem einheitlichen Konzept. Dabei soll den Betreibern der einzelnen Webauftritte jedoch gleichzeitig so viel Gestaltungs- und Nutzungs-Freiheit wie möglich belassen werden. Das Typo3-Projekt knüpft unmittelbar an das vorangegangene Joomla!-Pilot-Projekt an, das unter den gleichen Randbedingungen erfolgreich anlief und auch noch eine Weile parallel laufen wird. Um mehrere Dutzend Webserver auf einem einheitlichen Typo3-System laufen zu lassen, wird am LRZ eine speziell dafür aufgesetzte Betriebsumgebung geschaffen, die es den Betreuern am Medienzentrum ermöglicht, alle Webserver zentral in einem standardisierten Pool zu verwalten, beginnend vom formalen Antrag für die Einrichtung einer Typo3-basierten Website bis hin zur Übergabe des fertig vorinstallierten Typo3-Systems an die für die Inhalte des Webauftritts zuständige Einrichtung (Fakultät, Lehrstuhl, Projekt, etc.). Außerdem soll es möglich sein, dass eine Einrichtung das gesamte Typo3-System vollständig übernimmt und in eigener Verantwortung pflegt, wenn es Anforderungen gibt, die im Rahmen des Standard-Pools nicht mehr erfüllbar sind. Notwendige Sicherheits-Updates, Versionsänderungen und Erweiterungen können zentral durch das Medienzentrum eingespielt werden und stehen damit unmittelbar allen zur Verfügung. Der technische Betrieb konnte im Berichtsjahr schon weitgehend realisiert werden, so dass bereits erste produktive Websites in Betrieb gingen. Ein Schwerpunkt der Arbeiten im kommenden Jahr wird im Bereich der Verwaltung der gehosteten Webserver liegen (siehe auch Abschnitt Neukonzipierung der Webhosting-Umgebung ) E-Learning-System Moodle für das gesamte Hochschulnetz Das verstärkte Interesse an E-Learning an den Hochschulen spiegelt sich auch in gestiegenen Anforderungen an das Webhosting wieder. Zu diesem Thema hat es Mitte des Jahres am LRZ ein Treffen mit Vertretern von LMU, TUM, HM und LRZ gegeben, bei dem die Erfahrungen mit von diesen Einrichtungen bisher selbst betriebenen verschiedensten Lernplattformen ausgetauscht wurden. Es zeigte sich, dass es ein weit verstreutes Netz von Einzelinstallationen gibt, die teilweise hochschulweit genutzt werden, teilweise aber auch nur individuelle Installationen für einen engen Nutzerkreis sind. Der insgesamt dadurch aufzubringende Betreuungsaufwand ist relativ hoch und es fehlt sowohl den Studenten als auch der Hochschule selbst oft der Überblick über das zur Verfügung stehende Kursangebot. Von besonderer Bedeutung ist für viele auch eine Anbindung des Kursangebotes an die Virtuelle Hochschule Bayern (VHB), was in dieser stark heterogenen Umgebung zusätzliche Probleme macht.

29 Jahresbericht 2009 des Leibniz-Rechenzentrums 23 Um auch in diesem Bereich Ressourcen und Wissen zu konzentrieren, wurde beschlossen, basierend auf der sich stark verbreitenden frei verfügbaren Lernplattform Moodle ein Pilotprojekt am LRZ anzusiedeln. Die Herausforderungen in diesem Projekt liegen zum einen beim Betrieb einer web-basierten Lernplattform mit äußerst heterogenen Anforderungen aus den verschiedensten Hochschulbereichen. In den meisten Fällen muss Moodle durch Zusatzpakete und Applikationen erweitert werden, um eine optimale Lernumgebung und gewünschte Funktionalitäten zu realisieren. Beispielsweise würde eine virtuelle Tafel ( Whiteboard ) im Kursraum nur dann realisierbar sein, wenn man zusätzlich einen Applikationsserver betreibt, der Streaming erlaubt. Erschwerend zu den unterschiedlichen Anforderungen kommt noch hinzu, dass es oft zahlreiche ähnliche Erweiterungen gibt, die im Prinzip dem gleichen Zweck dienen. Hier muss eine möglichst für alle brauchbare Lösung gewählt werden. Zum anderen ist auch die zentrale Verwaltung der Nutzer der Lernplattform eine wichtige Randbedingung. Da es im allgemeinen notwendig ist, sich für den Zugang als Dozent oder Lernender zu validieren, müssen Anbindungen an die an den Hochschulen vorliegenden zentralen Verwaltungsdaten sowie an die VHB geschaffen werden. Die Tatsache, dass eine Reihe dieser Verwaltungsdaten bereits auf Servern am LRZ liegt, ist dabei ebenfalls von Vorteil (siehe Identity Management). Ein Großteil der System-Pflege (Rechner, Betriebssystem, Datensicherung, Basis-Installationen Moodle) kann vom LRZ übernommen werden und dadurch die Hochschulen entlasten. Die Idee wäre, beispielsweise fakultätsweise Moodle-Instanzen aufzusetzen, die am LRZ betrieben werden und für die jede Fakultät einen Beauftragten ernennt, der mit dem LRZ in Kontakt ist und betriebliche Fragen koordiniert. Die Hochschule könnten sich dadurch wieder mehr auf die didaktischen und inhaltlichen Aufgaben konzentrieren. Das Pilotprojekt sieht vor, im Laufe des Jahres 2010 wenige einzelne individuelle Moodle-Installationen aus dem Bereich der LMU ans LRZ umzuziehen und dort produktiv einzusetzen. Die damit gemachten Erfahrungen können dann in die Konzepte für eine Zentralisierung und Aufgabenteilung zwischen Hochschule und LRZ einfließen Neukonzeption der Webhosting-Umgebung Die gesamte Webinfrastruktur muss auf ein neues Betriebskonzept umgestellt werden, was zunächst technisch durch die anstehende Abschaffung des langjährig genutzten Dateisystems AFS ausgelöst wurde, was aber auch durch die höheren Anforderungen notwendig ist, die sich beispielsweise alleine durch die beiden Projekte Typo3 und Moodle ergeben. Neben den technischen Einzelheiten, die neu definiert werden müssen, ist dies auch eine starke Herausforderung an die Verwaltung der gehosteten Webserver. Durch die beiden Projekte wird klar, dass zu einem einzelnen Webauftritt in Zukunft deutlich mehr Parameter benötigt werden als bisher, aus denen eine genaue Zuordnung sowohl zu den für die Inhalte verantwortlichen Personen als auch insbesondere zu den technisch zur Realisierung benötigten Komponenten hervorgeht Webhosting Statistik Auf die zentralen WWW-Server am LRZ wurde im Jahr 2009 durchschnittlich ca. 44 Millionen Mal pro Monat zugegriffen. Diese Zahl ist allerdings aus mehreren Gründen nur bedingt aussagekräftig. Zum einen ist eine echte Zählung der Zugriffe gar nicht möglich, da auf verschiedenen Ebenen Caching- Mechanismen eingesetzt werden (Browser, Proxy). Andererseits werden nicht Dokumente, sondern http- Requests gezählt. Wenn also z. B. eine HTML-Seite drei GIF-Bilder enthält, so werden insgesamt vier Zugriffe registriert. Tabelle 9 zeigt die durchschnittliche Zahl der Zugriffe und den durchschnittlichen Umfang der ausgelieferten Daten pro Monat; die Daten sind nach den vom LRZ betreuten Bereichen aufgeschlüsselt. Die Zahlen für das LRZ enthalten auch die Zugriffe auf viele persönliche WWW-Seiten von Hochschulangehörigen. Zusätzlich wird die Zahl der Seitenaufrufe, das ist die angeforderte Zahl der echten Dokumente, genannt. Als echte Dokumente gelten dabei Textdokumente, also keine Bilder oder CGI-Skripte.

30 24 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Server (Domain) Leibniz-Rechenzentrum (lrz.de) Ludwig-Maximilians-Universität München (lmu.de) Technische Universität München (tum.de) Einrichtungen im Münchner Hochschulnetz (mhn.de) Einrichtungen im Münchner Wissenschaftsnetz (mwn.de) Bayerische Akademie der Wissenschaften (badw.de) Sonstige Zugriffe in Mio. 15,12 4,12 13,20 3,78 2,59 0,85 4,22 Seitenaufrufe in Mio. 3,42 0,63 0,88 0,88 0,11 0,20 0,23 Datenumfang in GByte 766,3 175,2 560,4 77,3 114,5 126,9 71,1 Gesamt 43,88 6, ,7 Tabelle 9: Monatliche Zugriffe auf die WWW-Server am LRZ Ende 2009 unterhielt das LRZ 16 virtuelle WWW-Server für eigene Zwecke. Für Hochschulen und hochschulnahe Einrichtungen wurden insgesamt 515 (Vorjahr: 423) virtuelle WWW-Server betrieben. Einrichtung (Domain) Leibniz-Rechenzentrum (lrz.de) Ludwig-Maximilians-Universität München (lmu.de) Technische Universität München (tum.de) Bayerische Akademie der Wissenschaften (badw.de) Einrichtungen aus dem Münchner Hochschulnetz (mhn.de) (z. B. Hochschule für Politik) Einrichtungen aus dem Münchner Wissenschaftsnetz (mwn.de) (z. B. Zoologische Staatssammlung München) Andere (z. B. Bayerisches Nationalmuseum) Webserver Webserver 2008 Gesamt Tabelle 10: Anzahl virtueller WWW-Server Zope-Hosting Zum Jahresende gab es insgesamt 15 unabhängige gehostete Sites, und zwar 10 individuelle Zope- Instanzen mit individuellen Sites (meist Plone), sowie eine TUM-Zope-Instanz mit 5 elevateit-sites Datenbanken Die Größe der bestehenden MySQL-Datenbanken wächst weiterhin rapide. Einzelne Datenbanken erreichen zwischenzeitlich die 1 TB Datenbankgröße und erfordern neue Verfahren der Datenbanksicherung. Für die CMS-Installation Fiona wurden erstmals InnoDB-Datenbanken, das heißt transaktionsorientierte MySQL-Datenbanken eingerichtet. Zusätzlich wurde diese Instanz auf eine MySQL Enterprise Lizenz (Goldsupport) umgestellt. Die für virtuelle Webserver der Münchener Hochschulinstitute eingerichtete Datenbankinstanz lief ununterbrochen (365 Tage à 24 Stunden) und bearbeitete 1 Milliarde DB-Anfragen. Neben den bestehenden MySQL-4.1-Instanzen wurden weitere MySQL-Datenbanken der Version 5 installiert und in Betrieb genommen. Viele der neueren Clientanwendungen für MySQL (Typo3, Joomla! etc.) erfordern MySQL-Datenbanken der Version 5.

31 Jahresbericht 2009 des Leibniz-Rechenzentrums 25 Nahezu alle neuen Instanzen der MySQL-Server laufen unter VMware als virtuelle Maschinen. Zur Automatisierung der Datenbanksicherungen und zur Vereinheitlichung der Backup-Vorgänge der MySQL- Datenbanken wurde das Produkt Zmanda beschafft und installiert. Zur Sicherung der InnoDB-MySQL-Datenbankdateien wurde das Produkt InnoDB-Hot-Backup gekauft. InnoDB-Hot-Backup ist ein Online-Backup-Tool mit dem man eine InnoDB-Datenbank bei laufendem Betrieb sichern kann. Das Dienstangebot bei den Oracle-Datenbanken blieb weitgehend unverändert. Für das neue Jahr steht hier eine Überführung der Oracle-Datenbankinhalte der Anwendung Action Request Software (ARS) in das neu beschaffte System iet ITSM-Solutions an. Dieses System arbeitet mit der Datenbank Microsoft SQL Server als Datenbank-Engine. Am Jahresende 2009 betrieb das LRZ 11 Instanzen (Vorjahr: 9) von MySQL (6 MySQL 4.1 und 5 MySQL 5), die etwa 450 GByte Daten (Vorjahr: 400 GByte) verwalten. Damit werden unter anderem ca. 280 virtuelle Webserver (Vorjahr: 240) versorgt. Darüber hinaus finden die MySQL-Services hausintern in 30 Projekten intensiven Gebrauch. Auch die Performancedaten des HLRB II werden in einer MySQL-Datenbank gespeichert und dadurch konsolidiert im Internet angezeigt. Die MySQL- Datenbankserver verarbeiten derzeit permanent ca Anfragen aus dem Netz pro Sekunde (Vorjahr: 700). 1.5 Grafik, Visualisierung, Multimedia Visualisierungs-Projekte Neben einer großen Zahl von Führungen und Exkursionen, die regelmäßig im LRZ stattfinden, tragen wir sowohl zu wissenschaftlichen Projekten als auch zur Ausbildung bei: Dr. Ewert, Klinikum FFB (LMU): Qualitätskontrolle von Operationen im Fußwurzelbereich Dolag, Astrophysik (MPI): Stereoskopische Aufführung einer Urknallsimulation; Präsentation am Girls-Day Prof. Heinzeller, Anatomie (LMU): Rekonstruktion und Visualisierung humaner Embryonen Prof. Matzge-Karasz, Paläontologie (LMU): Rekonstruktion und Visualisierung von versteinerten und lebenden Muschelkrebsen; stereoskopische Projektion beim Habilitationsvortrag Dr. Ruthensteiner, Zoologische Staatssammlung (LMU): Rekonstruktion und Visualisierung von Meeresschnecken; stereoskopische Projektion am Tag der offenen Tür Dr. Einwag, Archäologie (LMU): Visualisierung einer altorientalischen Stadt (13. Jh. v. Chr.); Informationsveranstaltung für das Seminar Archäologie und Informationstechnologie Hr. Hessing, Institut für Klassische Archäologie (LMU): Visualisierung von Ausgrabungen und Rekonstruktionen Höfling, Neumann, Angewandte Physik (LMU): Visualisierung der Interaktion von Proteinen Hr. Peller, Fachgebiet Hydromechanik (TUM): Visualisierung von Strömungsdaten im Hydromechanik-Seminar Dr. Weinert (LRZ): Entwicklung von CAD/CAM-Technologie für die Implantologie in der Zahnmedizin; Implementierung eines virtuellen Artikulators mit Parallelisierung auf die GPU; Export von Daten für medizinische Studien; Simulation von Kieferbewegungen mitsamt Kollisionsberechnung Dr. Satzger, Dr. Jamitzky (LRZ): Molekulare Dynamik; Präsentation am LRZ und zur ISC 09, Hamburg Hr. Wagner und Hr. Hechler (BMW): Erfahrungsaustausch Hr. Imhof und Hr. Laforsch, Ökologie (LMU): Rekonstruktion, Visualisierung und Vermessung von Dornenkronenseesternen mit 3-D-Metriken Hr. Hauser, Gene Center (LMU): Visualisierung von Proteinen; Präsentation zum Jubiläum Dr. Guminsky, Kunstpädagogik (LMU): Seminar über virtuelle Welten

32 26 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Nutzung des Streamingservers Das LRZ betreibt seit 2001 einen Streamingserver. Der Server wurde ursprünglich auf eine Initiative der Unterrichtsmitschau der LMU hin aufgebaut, die auch jetzt noch zu den stärksten Nutzern dieses Dienstes zählt. Insgesamt liegen derzeit auf dem Streamingserver mehr als 4000 Filmbeiträge mit einem aggregierten Datenvolumen von 510 GByte. Die einzelnen Filme sind häufig Aufzeichnungen von Vorträgen oder Vorlesungen mit einer Länge von Minuten, aber auch teilweise kürzere Lehrvideos, die zum Beispiel die Ausbildung in der Medizin unterstützen. Vorlesungsaufzeichnungen werden normalerweise in drei Varianten erstellt und abgelegt, als hochaufgelöstes Video mit einer Bandbreite von ca. 1 Mbit/s, als niedriger aufgelöstes Video mit ca. 400 Kbit/s und einer Variante, die nur aus der Tonspur besteht und nur eine Bandbreite von ca. 50 Kbit/s benötigt. In den letzten Monaten hat die Nutzung des Streamingservers kontinuierlich zugenommen. Die Statistik der vergangenen sechs Monate zeigt insgesamt Verbindungen, das entspricht mehr als tausend Verbindungen pro Tag. 1.6 Serveradministration und Applikationsunterstützung Der Betrieb von Serversystemen für Internetdienste erfordert eine Reihe von Arbeiten, die inhaltlich eher zum Betriebssystem oder zur systemnahen Software gehören, die aber auf das Applikationsportfolio am jeweiligen Serversystem zugeschnitten sind. Ob dabei das Serversystem eine physische Maschine ist oder aber eine virtuelle, spielt auf dieser Ebene kaum eine Rolle. Zu diesen Aufgaben gehören beispielsweise die Auswahl des erforderlichen Betriebssystemumfangs, je nach den Voraussetzungen der geplanten Anwendungen, die Deaktivierung von nicht benötigten Netzdiensten aus Sicherheitsgründen und weitere Sicherheitsmaßnahmen wie Zugangsbeschränkungen und Security-Patches, die Überwachung der Verfügbarkeit und der Funktion auf Applikationsebene, die Messung der Systemauslastung unter Berücksichtigung der Erfordernisse der Applikationen zum Tuning und zur proaktiven Ressourcenplanung, die Erstellung von Operateuranleitungen zur Problembehebung, die Unterstützung und Beratung der mit der Applikation betrauten Mitarbeiter, um eine optimale Nutzung des Systems zu erreichen sowie die Fehlersuche an der Schnittstelle zwischen Applikation und Betriebssystem. Da diese Systemadministration sowohl mit dem eigentlichen Rechnerbetrieb (Installation und Deinstallation, Installation eines Basis-Betriebssystems, Firmware, Anbindung ans Rechnernetz, hardware- und netznahe Funktionsüberwachung) als auch mit der Applikationsadministration eng verwoben ist, können diese Aufgaben im einen oder im anderen Bereich angesiedelt sein, und es ist in jedem Fall eine enge Zusammenarbeit erforderlich. Die Ansiedlung beim Rechnerbetrieb bietet sich an, wenn die Applikationen von den Endbenutzern oder von den Kunden des LRZ eingebracht werden (Mitarbeiter-Arbeitsplätze, Hosting/Housing, High-Performance-Computing), wenn eine hohe Anzahl gleichartiger Systeme vorliegt oder wenn die Applikationsadministratoren dem Betrieb organisatorisch benachbart sind. Bei den Netzdiensten mit ihrem eher individuellen Applikationsprofil hat es sich bewährt, die Systemadministration organisatorisch im Umfeld der Applikationen anzusiedeln Serveradministration in BDS Der Abteilung BDS oblag Ende 2009 die Administration folgender Serversysteme: 21 virtuelle Maschinen mit Linux-Betriebssystem 33 physische Maschinen mit Linux-Betriebssystem 20 physische Maschinen mit Solaris-Betriebssystem 160 Serversysteme für die IT-Infrastruktur des Bibliotheksverbundes Bayern (Details siehe Abschnitt 1.10 BVB; diese Systeme werden in diesem Abschnitt nicht mehr betrachtet) Diese Maschinen wirken im Umfeld der Webservices (Webserver, Content-Management, verschiedene Backendserver), der Datenbanken, der Lizenzverwaltung und weiterer Netzdienste (FTP, Mailinglisten).

33 Jahresbericht 2009 des Leibniz-Rechenzentrums 27 Sie beherbergen auch einige Dienste der Rechnerüberwachung und -steuerung (OVO, Konsolserver, Administratorengateways) sowie des Netzmanagements und der Netzüberwachung. Bei den virtuellen Systemen liegt der Rechnerbetrieb bei der Betreibergruppe der VMware-Systeme in der Abteilung HLS; bei den physischen Systemen werden die Maschinen von den Systemadministratoren auch betrieben. Im Jahr 2009 wurden neben den oben erwähnten Daueraufgaben folgende Sonderdienste durchgeführt: Mehrere Dienste wurden von realer Hardware unter Solaris oder Linux auf virtuelle VMware- Maschinen verlagert oder neu auf virtuellen Maschinen eingerichtet. Insbesondere wurde für den FTP-Server eine neue Software eingesetzt und der Server auf eine virtuelle Linux-Maschine verlagert. Dadurch wird er auch dem künftigen administrativen Umfeld gerecht, insbesondere dem Wegfall von AFS als rechnerübergreifendem Dateisystem. Auch auf realer Hardware betriebene Systeme wurden auf andere Hardware verlagert, neu installiert oder grundlegend überarbeitet. Das Server- und Dienstmonitoring auf Applikationsebene wurde wesentlich ausgebaut. Dazu wurden einzelne Monitoring-Tools (z.b. der INT-Syslog-Server und der Simple Event Correlator (SEC)) in ein Monitoring-Gesamtkonzept integriert sowie der Nagios Satelliten-Server verbessert und erweitert. Außerdem wurden die Anforderungen der Systemadministration in abteilungsübergreifende Arbeitskreise eingebracht: Mit dem Arbeitskreis Continuity (siehe Abschnitt 4.3 AK Continuity) wurden ein Lastabwurfplan und ein Wiederanschaltplan für den Kontext Major Incident erstellt. Mit dem Arbeitskreis Informationsmanagement (siehe Abschnitt 4.4 AK Informationsmanagement) wurden Vorschläge zur Verbesserung des LRZ-Informationsmanagements erarbeitet Service für das Münchner Wissenschaftsnetz Wie schon in den Vorjahren gibt es Daueraufgaben nicht nur beim Betrieb der obengenannten Server, sondern darüber hinaus als Dienst im gesamten Münchner Wissenschaftsnetz: Verteilung von Software im Rahmen des Sun Campus-Vertrages, Beratung der Anwender im MWN in Bezug auf den Sun Campus-Vertrag, Unterstützung der Anwender bei der Nutzung der LRZ Lizenzserver; speziell bei Ansys und Matlab ist der Unterstützungsbedarf sehr hoch, Unterstützung bei Beschaffung, Installation und Konfiguration von Hardware und Software, Unterstützung und Beratung von Systemadministratoren im MWN bei Problemen zu Hardware und Software ( bootet nicht mehr, Platte defekt, was tun?,...) sowie Unterstützung von Systemadministratoren im MWN bei Security-Problemen oder bei Hackervorfällen 1.7 Desktop- und Applikationsservices Die zentralen Themen gruppieren sich nach wie vor um den Aufbau und Betrieb von Infrastrukturdiensten im Münchner Wissenschaftsnetz. Dazu gehört der Betrieb von Windows Servern für interne und externe Kunden, die Anbindung des Speichers für die Wissenschaft an Arbeitsplatzrechner unter Windows und Linux, die Nutzung eines MWN-weiten Active Directories für Arbeitsplatzrechner bei Institutionen in einem delegierten Administrationsmodell, dem Aufbau eines mandantenfähigen Softwareverteilungstools und der Nutzung von Sharepoint 2007 als Collaborationsplattform. Weitere (Pilot-) Kunden aus LMU und TUM konnten für diese Dienste im Life-Cycle-Management von Arbeitsplatz-PCs gewonnen werden. Insbesondere wird auch die LRZ-eigene PC-Landschaft (Pool, Kursräume, Spezialarbeitsplätze, Mitarbeiter-PCs, Server) nach und nach in die neue Management-Infrastruktur aufgenommen und dort betrieben. Das dient nicht zuletzt der Erfahrungssammlung für das eigene Dienstportfolio.

34 28 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Sicherheitsdienste für Desktops im MWN Antiviren-Service Auf der Grundlage eines Landesvertrages über die Antiviren-Software der Fa. SOPHOS hat das LRZ eine Service-Infrastruktur zur automatischen Verteilung und Installation von SOPHOS-Virensignaturen für alle Nutzer im Münchner Wissenschaftsnetz eingerichtet, verbunden mit entsprechenden Beratungsleistungen zur Nutzung für Endbenutzer. In 2009 hat das übertragene Volumen die Menge von 17,5 (Vorjahr 20) TByte erreicht. Die Anzahl der Zugriffe im Jahre 2009 verdeutlicht Abbildung 5. Es ist zu berücksichtigen, dass PC-Clientsysteme oft mehrmals am Tag zugreifen. Als jeweils ein Client werden auch sog. Proxys gezählt, die wiederum eine Weiterverteilung der Daten an ihre PC-Clientsysteme ermöglichen. Die tatsächliche Zahl von Clients wird auf ca geschätzt (weiterführende Serviceinformationen siehe: Abbildung 5 Anfragen an den Sophos-Antivirenservice im Jahre Windows Software Update Service Als weiterer Basisservice für das automatische Update von Windows-Betriebssystemen und Microsoft Applikationen wie Internet Explorer oder Office wird der Windows Software Update Service (WSUS) als MWN-weiter Dienst angeboten. Der Service ist seit längerem mit guten Erfahrungen innerhalb des LRZ in Benutzung und kann auch von allen Endkunden im MWN über das LRZ benutzt werden. Im April 2009 wurde der Dienst auf die virtuelle Infrastruktur umgezogen. Die hohe Akzeptanz des Service im Münchner Wissenschaftsnetz verdeutlicht Abbildung 6 der Serveranfragen in 2009 (weiterführende Serviceinformationen s Active Directory im Münchner Wissenschaftsnetz Als weiteren, großen Infrastrukturdienst betreibt das LRZ für das MWN ein mandantenfähiges Active Directory. Dieses AD ist so angelegt, dass einzelne, große Institutionen wie LMU, TUM oder die BADW voneinander getrennt agieren können. Der Aufbau eines zentralen, MWN-weiten AD wurde im Jahr 2007 im Rahmen der Bereitstellung von Exchange und den Fileservices auf Basis von NetApp mit CIFS notwendig. Im letzten Jahr wurde nun die Nutzung des ADs auf die Integration und Verwaltung von Clients ausgedehnt. Ziel ist es dabei, Synergien bei der Administration von Desktop-PCs zu erschließen und Mehrwerte im Funktionsumfang für Anwender und Administratoren nutzen zu können. Dieses Remote Desktop Management Serviceangebot ist seit langem am LRZ erprobt.

35 Jahresbericht 2009 des Leibniz-Rechenzentrums 29 Abbildung 6 Anfragen zum Software Update Service (SUS) in 2009 Jede Organisationseinheit erhält eine vordefiniert Unterstruktur (Organisational Unit OU) in diesem Directory, die wiederum in Fakultäten und Lehrstühle weiter untergliedert werden kann. Auf diesen Ebenen können Computerkonten, Gruppen, Funktionskennungen oder auch Ressourcen für Exchange, eingetragen werden. Damit es nicht zu Namenskonflikten kommt, wurde ein verbindliches Namenskonzept für Objekte im Active Directory entwickelt. Zur Erfüllung ihrer Aufgaben wird den Teil-Administratoren ein Set an Werkzeugen über zwei Terminalserver auf Basis von Windows Server 2003 und 2008 zur Verfügung gestellt. Die Einrichtung dieser Strukturen wurde in 2008 für die TU München umgesetzt und wird stetig in Absprache mit der TU München angepasst. Für die LMU wird die Struktur bei Bedarf angelegt. Abbildung 7 Active Directory im MWN

36 30 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Die Benutzerkonten und zentralen Gruppen werden über die beiden Metadirectories am LRZ gepflegt. Dabei kommen Softwarelösungen der Firma Novell zum Einsatz. Mit diesem Active Directory können alle Clients ab Windows 2000 verwaltet, Mac OS 10 und Linux- Systeme integriert werden. Momentan sind aus den drei großen Mandanten TUM, LMU und BADW rund 1000 Rechner im AD integriert. Es wurden bisher rund 160 Teiladmins aus 105 Einrichtungen registriert und in 2009 haben sich an der Infrastruktur knapp 7000 verschiedene Nutzer angemeldet. Dabei wurden Dienste wie das Ablagesystem oder die Groupware Exchange genutzt. Abbildung 7 gibt einen schematischen Eindruck von den am Directory beteiligten Organisationen, Rollen, Client-Systemen (linke Bildhälfte), die im Active Directory verwaltet werden. Ebenso stützen sich viele Anwendungen und Dienste (rechte Bildhälfte) auf die im Directory abgelegten Benutzer und Konfigurationsdaten Provisionierung der Benutzer in das Active Directory In 2009 wurde die Provisionierung der Benutzerkonten der TU München aus dem Metadirectory in das Active Directory durch den Identity Manager Driver for Scripting von Novell abgelöst. Mit der bisherigen Lösung auf Basis von DirXML konnten bislang nur Objekte erzeugt oder gelöscht, bzw. Attributsänderungen direkt in das AD geschrieben werden. Komplexere Abläufe wie Gruppenänderungen waren zwar möglich, bedeuteten aber auf der Metadirseite einen sehr hohen Arbeitsaufwand. Durch die Limitierungen im DirXML Treiber waren mehrstufige Aktionen ausserhalb des Active Directories, wie zum Beispiel das Anlegen einer Exchange Mailbox, nicht möglich. Mit der Produktivführung von Exchange im Sommer 2009 für die TU München war aber eine automatische Provisionierung von Exchange Mailboxen notwendig und so entschied man sich für den IDM for Scripting, der nun nicht mehr direkt ins AD schreibt, sondern die Attributsänderungen an Powershell Skripten übergibt. Damit wurde auf der AD Seite eine enorme Flexibilität gewonnen, da nun die jeweiligen Dienste über angepasste Powershell Skripte direkt angesprochen werden können. Auch konnte mit dem Scripting die Protokollierung deutlich verbessert werden, so dass jetzt jeder einzelne Provisionierungsprozess detailliert nachvollzogen werden kann. Durch die Scriptinglösung hat sich leider die Systemlaufzeit einer einzelnen Aktion deutlich erhöht. Dies ist im Alltagsbetrieb kein Problem, kann aber bei Massenoperationen, wie zum Semesterwechsel, zu deutlichen Verzögerungen führen. Hier wird zurzeit noch nach Verbesserungen gesucht, um die Script- Laufzeiten zu verringern. Eine Hoffnung ist dabei das nächste Release des Scritping Drivers, das bereits in einer alpha-version getestet wird. In 2010 soll dann die Umstellung des Treibers für die SIM- Anbindung folgen Desktop Management Die PC-Gruppe hat unterschiedliche Modelle für die Bereitstellung von aktuellen Windows- Arbeitsplätzen für verschiedene Kundengruppen entwickelt. Die Lösungen reichen dabei vom vollwertigen Mitarbeiterarbeitsplatz, über Terminalserverlösungen für Mitarbeiter bis zum virtuellen Desktop für Testzwecke. Für Studenten werden sowohl vollwertige Rechnerpools als auch auf Terminalserverlösungen basierende Pools angeboten. Light Desktop Pool und Kurs Fullmanaged Desktop LRZ BADW 173 TUM LMU 117 HMT 60 HFF 8 Summen Tabelle 11: Desktop-Management durch das LRZ im MWN

37 Jahresbericht 2009 des Leibniz-Rechenzentrums 31 Im Rahmen des AD für das MWN kam der Light-Desktop hinzu, in der Institutionen ihre Rechner in die Infrastruktur integrieren können und so die Vorteile eines AD für das Desktopmanagement mit nutzen können, ohne selbst die Infrastruktur zu betreiben. Die PC-Gruppe übernimmt dabei keine administrativen Aufgaben auf den Rechnern. So setzen sich die verschiedenen Rechnergruppen zahlenmäßig Ende 2009 wie in Tabelle 11 gezeigt zusammen. Bei den Bestandskunden für den Remote Desktop Management Service in der ADS/LRZ-Domäne fanden in 2009 einige Umrüstungen statt: - TUM-Sport (37 PCs): Umrüstung des PC-Pools auf Dell-Hardware Basis, Umzug in die neue Domäne ads.mwn.de, Umstellung auf LRZ-Kennungen - HS Musik und Theater (23 PCs): Modernisierung eines Pools auf HP Basis und Neuaufbau eines Pools auf Lenovo Basis - BADW: laufende Modernisierung der Hard- und Softwareausstattungen, Terminalserver auf Basis Windows 2003 für Nicht Windows Nutzer und Teleworker - LRZ: laufende Modernisierung der Hard- und Softwareausstattungen, Windows 7 Verteilung Im Jahr 2009 wurden viele Stunden für Kundenberatung erbracht, um das Angebot Desktop Light zu nutzen. Besonders erwähnenswert sind dabei WZ Weihenstephan, TUM Chemie und LMU Biologie Department I Server Management Die PC-Gruppe betreut im Rahmen ihrer Tätigkeit auch zahlreiche Server. Zum einen zur Erbringung der Hintergrunddienste für den Clientbetrieb, wie das Active Directory, Exchange oder die Softwareverteilung SCCM, zum anderen für andere Abteilungen oder für externe Kunden. Das letzte Jahr stand dabei im Zeichen der zunehmenden Servervirtualisierung. Neue Server werden nur noch als virtuelle Instanzen in Betrieb genommen und zahlreiche Server auf physischer Hardware wurden virtualisiert. Dabei konnten Neuanschaffungen von Hardware, die aus der Garantie gelaufen war, vermieden werden und auch Stromkosten eingespart werden. Bislang sind die Erfahrungen mit den virtualisierten Maschinen sehr positiv, weshalb versucht werden soll, die Virtualisierung von Hardware in 2010 weiter voran zu treiben System Center Configuration Manager Im Bereich des Life Cycle Management von Windows Desktops ist eine stärkere Abstützung auf Werkzeuge erforderlich. Dazu wurde in 2008 der Microsoft System Center Configuration Manager (SCCM) getestet und in 2009 in Produktion gesetzt. Der SCCM löst dabei den WDS von Microsoft ab, der aber immer noch für die Installation von älteren OS wie Windows XP in der BADW Verwendung findet. Der SCCM wurde notwendig, da die bisherigen Lösungen an ihre Grenzen kamen. Darum wurde mit der Einführung von Windows Vista damit begonnen, SCCM aufzubauen und mit der Einführung von Windows 7 wurde das Werkzeug schließlich in Produktion genommen. So ist es nun möglich, neben der reinen Erstinstallation auch Softwareupdates im laufenden Betrieb zu verteilen und nicht mehr nur zur Bootzeit. Die Datenbank des SCCM ermöglicht ein ausführliches Reporting der Verteil- und Installationsvorgänge und damit eine verbesserte Kontrolle der Verteilvorgänge. Durch die integrierte Inventarisierung, können sich die Administratoren relativ schnell einen Überblick über Hardware und die installierte Software auf den Rechnern machen. Durch die Integration eines Remotesupporttools ist es den Administratoren nun auch möglich, aus der Ferne auf die Clients zuzugreifen und den Desktop der Endanwender zu spiegeln, um bei Problemen besser zu unterstützen, statt immer vor Ort gehen zu müssen. Datenschutzaspekte sind dabei berücksichtigt worden. Derzeit sind rund 370 Systeme an den SCCM angebunden. In 2010 soll als nächstes das im SCCM integrierte Patchmanagement angebunden werden, das wegen der größeren Flexibilität gegenüber WSUS bei den vom LRZ betreuten Rechnern Verwendung finden wird. Das Reporting soll noch ausgebaut werden, um noch mehr Informationen von den Clients zu bekommen. Der SCCM wird mandantenfähig für die Teiladmins im MWN-AD ausgebaut werden. Eine weitere wichtige Aufgabe ist die Anbindung an den automatischen Provisionierungsprozess im Rahmen der Servervirtualisierung.

38 32 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Microsoft Office Sharepoint Services In 2009 wurde mit dem Aufbau einer Kollaborationslösung auf Basis von MOSS 2007 begonnen. Ziel ist zum einen die Ergänzung der Groupwarelösung von Exchange 2007, da hier die public-folder weg gefallen sind und diese durch MOSS ersetzt wurden. Zum anderen bietet MOSS die Möglichkeit für Gruppen die Zusammenarbeit zu verbessern um z.b. gemeinsam an Dokumenten zu arbeiten oder die Zusammenarbeit besser über Gruppenkalender, Besprechungsbereiche, Benachrichtigungen, Wikis oder gemeinsame Aufgaben zu organisieren. Es gibt auch die Möglichkeit, komplexere Prozesse in Workflows abzubilden, die häufig in Verwaltungen zum Einsatz kommen. Der Zugriff auf die Ressourcen erfolgt webbasiert. Hierbei mussten leider Einschränkungen bei der Unterstützung von zu Internet Explorer alternativen Browsern wie Firefox oder Safari festgestellt werden. Auch ist die Integration in die Office Applikationen wie Outlook oder Word nicht ganz durchgängig. Das Webportal und das Rechtesystem führen immer wieder zu Verwirrung bei den Anwendern. Seit Ende des Jahres 2009 wird nun die neue (Beta-) Version MOSS 2010 untersucht, was von Anfang an das Ziel des Projektes war. Erste Tests waren vielversprechend. In der neuen Version ist die Unterstützung von alternativen Browsern durchgängig und Dokumente können nun online, innerhalb des Browsers, bearbeitet werden, ohne auf dem Client eine Officeapplikation zu benötigen Projekte im Rahmen der Lehrlingsausbildung Der PC-Gruppe waren in 2009 zunächst zwei und dann, ab September, vier Auszubildende der Fachrichtung Fachinformatiker Systemintegration und IT-System-Elektroniker zugeordnet. Die Azubis sollen sowohl den Alltag eines Systemadministrators kennenlernen, als auch projektorientiert arbeiten. Als Vorbereitung für die Azubis auf ihr Abschlussprojekt in 2010 wurde besonderen Wert auf die Durchführung von Projektarbeiten gelegt. Hierbei ist vor allem der Aufbau einer Terminalserverlösung als Ersatz für den bestehenden Pool am LRZ zu nennen. Dabei konnten die Azubis die ganze Bandbreite der Windows Systemadministration umsetzen, von der automatisierten Installation, über Gruppenrichtlinien, servergespeicherte Profile, Terminalserverlösungen und die Integration in eine bestehende Infrastruktur für Backup, Virenscanner und Patchmanagement. Der Pool wird zukünftig von den Azubis eigenverantwortlich betrieben und sämtliche Wartungsaufgaben obliegen ihnen. Im Rahmen des Lehrlingsaustausches im Herbst 2009 mit dem Wissenschaftszentrum Weihenstephan der TU München wurde eine Teststellung zur MAC-Adressen-Authentifizierung von Clients an einem Switch aufgebaut. Dabei musste ein AD installiert und der Netzwerkrichtlinienserver von Microsoft in Zusammenarbeit mit der Abteilung KOM konfiguriert werden. Nach erfolgreichen Tests soll diese Lösung nun im Frühjahr 2010 für den Pool am LRZ umgesetzt werden und damit die Konfiguration auf den Switches ablösen. Weitere, wichtige Aufgaben der Auszubildenden in 2009 waren: - Aufbau von Kiosk-PCs - CAD Systeme modernisieren - Modernisierung der Kursräume am LRZ - Remote support Tool auf Basis von UltraVNC - Migration von Adressbüchern nach Outlook - Softwarepaketierung - Mitarbeit im allgemeinen Life-Cycle Management der Rechner am LRZ 1.8 Server- und Benutzerzertifizierung nach X.509 Das LRZ ist mit mehreren Zertifizierungs- und Registrierungsstellen (CAs und RAs) in die Zertifizierungshierarchie Global der Public-Key-Infrastruktur des Deutschen Forschungsnetzes (DFN-PCA) eingebunden, deren Wurzelzertifikat von einer kommerziellen CA (T-TeleSec Trust Center der Deutschen Telekom AG) beglaubigt wird. Damit gibt es keine Notwendigkeit für die Endbenutzer, das Wurzelzertifikat explizit durch Import als vertrauenswürdig zu kennzeichnen, wenn das schon vom Hersteller der Software erledigt wurde. Nach jahrelangem Hin und Her hat sich auch der Hersteller Mozilla (Produkte

39 Jahresbericht 2009 des Leibniz-Rechenzentrums 33 Firefox und Thunderbird) zur Aufnahme dieses Wurzelzertifikats in seine Produkte ab Juli 2009 entschlossen. Das LRZ betreibt im Rahmen dieser Hierarchie eine Zertifizierungsstelle (CA) sowie für die beiden Münchner Universitäten jeweils eine Registrierungsstelle (RA). Die vorher betriebene Server- Zertifizierungsstelle für das Münchener Wissenschaftsnetz ist damit obsolet geworden; ihre letzten Zertifikate haben im Juni 2009 ihr Verfalldatum erreicht. Insgesamt gibt es am LRZ vier Registrierungsstellen, die derzeit neue Zertifikate ausstellen: eine RA für die Bayerische Akademie der Wissenschaften einschließlich des LRZ selbst sowie für solche Einrichtungen im Münchner Wissenschaftsnetz, die keine eigene CA betreiben (69 neue Zertifikate im Jahr 2009) eine Server-RA für die TU München (42 neue Zertifikate im Jahr 2009) eine Server-RA für die LMU München (15 neue Zertifikate im Jahr 2009) eine Server- und Nutzer-RA für das Grid-Computing im Münchner Wissenschaftsnetz und an der Universität der Bundeswehr München (zusammen 144 neue Zertifikate im Jahr 2009) Die drei erstgenannten gehören dabei jeweils zu einer CA bei der jeweiligen Einrichtung; die Grid-RA gehört zu einer CA, die von der DFN-PCA betrieben wird. 1.9 Bearbeitung von Missbrauchsfällen Das LRZ ist bei der DENIC eg (d.h. bei der Registrierungsstelle für Domains unterhalb der Top Level Domain DE ) als Ansprechpartner für Domains des Münchner Wissenschaftsnetzes (MWN) eingetragen (u.a. für uni-muenchen.de, lmu.de, tu-muenchen.de, tum.de und fh-muenchen.de). Ähnliches gilt für die IP-Netze, die dem LRZ zugeteilt wurden. Damit ist das LRZ Anlaufstelle für sehr viele Anfragen und Beschwerden, die diese Domains bzw. IP-Adressen betreffen Statistik der Missbrauchsfälle Im Jahr 2009 nahm die Zahl der entdeckten Missbrauchsfälle gegenüber dem Vorjahr deutlich zu (siehe Abbildung 8). Die sehr hohe Zahl der Fälle hat nach den Erfahrungen des LRZ folgende Gründe: Durch die weiter zunehmende Kriminalisierung des Internet werden die Tools der Hacker, Viren- Bastler und Spammer inzwischen überwiegend von Profis und Spezialisten entwickelt, die teilweise hoch qualifiziert sind. Dementsprechend nimmt die Wirksamkeit dieser Tools kontinuierlich zu. Die Zahl der elektronischen Schädlinge (Viren, Würmer, trojanische Pferde usw.) nimmt beständig zu; inzwischen tauchen an einem Tag mehr als (!) neue Schädlinge bzw. Varianten/Modifikationen schon existierender Schädlinge auf. Außerdem versuchen die Schädlinge immer intensiver, sich vor einer Entdeckung zu schützen. Als Folge nimmt die Erkennungsrate der Viren-Scanner ab. Leider ist das Sicherheitsbewusstsein bzw. -verhalten zu vieler MWN-Benutzer nach wie vor unzureichend. Diesem setzt das LRZ diverse sicherheitsrelevante Dienste entgegen. Zu den insgesamt Abuse-Fällen des Jahres 2009, die MWN-Rechner betrafen, erhielt das LRZ Hinweise, Beschwerden, Anfragen usw. von außerhalb. Zum Glück verletzten nur bei ganz wenigen Sicherheitsvorfällen MWN-Benutzer absichtlich die Nutzungsregeln; der überwiegende Teil der Fälle betraf Rechner, die von Würmern, trojanischen Pferden, Botnet-Drohnen usw. befallen wurden; die eingedrungenen elektronischen Schädlinge versuchten dann ihrerseits, sich weiter zu verbreiten, oder der Rechner wurde zu einem Teilnehmer an einem Botnet und verursachte danach Schäden (z.b. durch Versenden von Spam-Mails). die über aktuelle Sicherheitslücken angegriffen, kompromittiert und dann für weitere Angriffe missbraucht wurden.

40 34 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Vom LRZ selbst entdeckte Fälle Gemeldete Fälle Abbildung 8 Entwicklung der Missbrauchsfälle im MWN seit 1998 Art der Vorgänge Anzahl der Fälle Involvierte Rechner / Benutzer des MWN Eingegangene Beschwerden, Anfragen usw. Fälle mit rechtlichen Aspekten: Copyright-Verletzungen Anfragen von Strafverfolgungsbehörden Sonstige Fälle Teilsumme Sonstige kompromittierte Rechner: DFN-CERT: Automatische Warnungen DFN-CERT: Sonstige gemeldete Fälle Sonstige Beschwerden (u.a. DoS) Port-/Vulnerability-Scans Teilsumme Organisatorische Vorgänge: Aktualisierung der Monitoring-Ausnahmelisten Aufheben von Sperren Sonstige Fälle Teilsumme Fälle im Bereich Spam-Versand über kompromittierte Rechner Unberechtigte Spam-Beschwerden / NDR Hinweise auf / Fragen zu Phishing-Aktionen Unberechtigte Spam-Beschwerden / Legitim Sonstige Mail-Fälle 4 4 Teilsumme Sonstige Fälle Summe der gemeldeten Fälle Tabelle 12: Fälle, die dem LRZ gemeldet wurden, oder organisatorische Vorgänge

41 Jahresbericht 2009 des Leibniz-Rechenzentrums 35 Ca. 40% der bearbeiteten Fälle gehen auf Beschwerden, Hinweise, Anfragen usw. zurück, die dem LRZ von außerhalb geschickt wurden, oder auf organisatorische Vorgänge (siehe Tabelle 12). Bei diesen Fällen sind folgende Punkte besonders erwähnenswert: Die Zahl der von außerhalb gemeldeten Fälle nahm von 393 im Jahr 2008 um 140% auf 944 zu. Dies wurde allein durch zwei Entwicklungen verursacht (nähere Details siehe unten in Abschnitt 1.9.2): o Drastische Steigerung der Beschwerden wegen Verletzung des Urheberrechts o Das LRZ nutzt seit Mitte März 2009 den Dienst Automatische Warnungen des DFN-CERT. In den meisten Fällen der unberechtigten Spam-Beschwerden handelte es sich um Non-Delivery- Reports (NDR); diese werden fast immer durch einen Wurm oder Spammer verursacht, der die eigene Mail-Adresse missbraucht. Wenn ein Mail-System (z.b. die Mail-Server des LRZ) eine einmal angenommene nicht zustellen kann, ist es laut Norm verpflichtet, den (vermeintlichen) Absender in einem NDR darüber zu informieren. Dies gilt selbst dann, wenn die ursprüngliche sehr wahrscheinlich von einem Wurm oder Spammer stammte. In diesem Fall ist der Empfänger des NDR ein indirektes Opfer. Manche Empfänger fühlen sich durch diese nicht selbst ausgelösten NDRs derart belästigt, dass sie sich beim Betreiber des korrekt arbeitenden Mail-Systems beschweren. Bei Unberechtigte Spam-Beschwerden / Legitim erhielt das LRZ Beschwerden über s, die nach Ansicht des LRZ einen legitimen bzw. seriösen Inhalt hatten. In diesen Fällen handelte es sich meist um Rundbriefe einer Organisation des MWN oder um Beiträge eines seriösen Newsletters. Manche Nutzer tragen sich selbst bei einem Newsletter ein, vergessen dies dann aber nach einiger Zeit und fühlen sich dann von Beiträgen des betreffenden Newsletters belästigt. Bei den Monitoring-Funktionen (siehe unten) gibt es zwangsläufig jeweils eine Ausnahmeliste mit Rechnern, bei denen das auffällige Verhalten legitim ist. Die Aktualisierung dieser Listen betraf überwiegend das Mail-Monitoring, weil es relativ viele legitime Ursachen für ein erhöhtes Mail- Aufkommen gibt: o Inbetriebnahme eines neuen Mail-Servers, -Gateways oder Servers für Mail-Verteiler o Regelmäßiges Verschicken von Rundbriefen mit vielen Empfängern o Verschicken von Benachrichtigungen durch ein System, das die korrekte Funktion / Verfügbarkeit von Diensten oder Rechnern überwacht Das LRZ geht i.a. aktiv auf die Betreiber von Rechnern zu, bei denen das Mail-Aufkommen vermutlich legitim ist (z.b. wenn im DNS-Namen der String mail vorkommt). Dies ist auch der Grund dafür, dass die Fälle dieser Gruppe nur selten von LRZ-Kunden initiiert werden. In vielen Fällen müssen kompromittierte Rechner zur Sicherheit am Internet-Übergang gesperrt werden. Wird ein betroffener Rechner innerhalb von wenigen Wochen wieder gesäubert, wird das Aufheben seiner Sperre noch innerhalb des ursprünglichen Abuse-Falls abgewickelt. Liegt die Sperre jedoch schon mehrere Monate oder evtl. sogar schon Jahre zurück, wird das Entsperren in einem gesonderten Fall bearbeitet. Zu den von außerhalb gemeldeten Fällen kamen weitere, auf die das LRZ im Rahmen der Netzüberwachung selbst aufmerksam wurde (siehe Tabelle 13). Die Monitoring-Funktionen am Internet-Übergang (d.h. am Übergang vom MWN zum X-WiN) sind trotz ihrer Einfachheit erstaunlich wirksam; folgende Indikatoren eignen sich erfahrungsgemäß sehr gut, um kompromittierte Rechner zu entdecken: Bei der ersten Gruppe ist der Indikator derart treffsicher, dass das LRZ riskiert, die auffällig gewordenen Rechner automatisch am Internet-Übergang zu sperren; die zuständigen Netzverantwortlichen werden selbstverständlich ebenso automatisch sofort davon verständigt. o Auf dem Rechner läuft ein FTP-Server, der auf einem Nicht-Standard-Port arbeitet (d.h. nicht auf dem allgemein üblichen Port 21). o Der Rechner ist mit dem Wurm Conficker infiziert. o Der Rechner ist mit dem Wurm Torpig infiziert. Bei den restlichen Indikatoren werden Benachrichtigungs-Mails vorformuliert; ein Mitglied des Abuse-Response-Teams entscheidet jedoch jeweils, ob die auch abgeschickt und der Rechner evtl. zusätzlich gesperrt werden soll.

42 36 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme o Der MWN-Rechner öffnet innerhalb kurzer Zeit viele Mail-Verbindungen zu anderen Rechnern im Internet. Diese MWN-Rechner sind fast immer kompromittiert, wobei der Rechner zum Versenden von Spam- oder Phishing-Mails missbraucht wird. o Der MWN-Rechner öffnet innerhalb kurzer Zeit extrem viele Verbindungen zu anderen Rechnern im Internet. Durch zusätzliche Indikatoren kann man erkennen, ob es sich wahrscheinlich um einen massiven Port-Scan oder um einen Denial-of-Service-Angriff (DoS) handelt. o Der Rechner fällt durch einen außergewöhnlich hohen Datenverkehr auf. Es handelt sich dabei auch manchmal um Rechner, die für die Verteilung urheberrechtlich geschützter Daten missbraucht wurden. Zu den aufgeführten Indikatoren gibt es natürlich jeweils eine Ausnahmeliste von bekannten sauberen Rechnern, die dadurch vor einer Sperre geschützt werden. Neben den Monitoring-Funktionen am Internet-Übergang verbessert auch noch der sogenannte NAT-o- MAT durch automatisierte Mechanismen die Sicherheit des MWN. Es handelt sich dabei primär um ein transparentes NAT-Gateway, das bei den Rechnern mit privater IP-Adresse nicht konfiguriert werden muss. Zusätzlich zur Adressumsetzung sorgt ein AutoMAT für eine Bandbreitenregelung und verhindert weitgehend Angriffe auf andere Rechner durch Port-Scans, DoS und Spam-Versendung: Der NAT-o- MAT blockt automatisch kompromittierte Rechner, die den Betrieb beeinträchtigen, und veranlasst den Besitzer eines derartigen Rechners durch geeignete Hinweise, seinen PC zu säubern. In schweren Fällen schickt der NAT-o-MAT außerdem noch eine Hinweis-Mail an die zuständigen Netzverantwortlichen. In der Statistik werden nur diese Fälle gezählt. Ist der Rechner mit den Würmern Conficker oder Torpig infiziert, sperrt der NAT-o-MAT diesen Rechner nach einer Vorwarnung dauerhaft; das Aufheben der Sperre erfolgt durch ein Mitglied des Abuse-Response-Teams. Seit 2006 wirkt sich der NAT-o-MAT nicht mehr nur auf Rechner mit privaten IP-Adressen aus, die Dienste im Internet in Anspruch nehmen wollen. Durch ein geeignetes Policy-based-Routing werden auch sämtliche VPN- und Einwahlverbindungen (Modem, ISDN und M-net) zwangsweise durch den NAT-o-MAT geleitet. Dementsprechend nahmen auch die vom NAT-o-MAT erkannten Missbrauchsfälle drastisch zu. Art des Monitoring, Anzahl der Anzahl der Fälle durch das die verdächtigen Rechner entdeckt wurden Rechner Entdeckte kompromittierte Rechner: NAT-o-MAT (schwere Fälle) Wurm Conficker Viele Mail-Verbindungen zu anderen Rechnern im Internet Port-Scans Extrem hoher Datenverkehr DoS 8 8 FTP-Server, der auf einem Nicht-Standard-Port arbeitet 7 7 Wurm Torpig 6 6 Sonstiger Angriff 4 4 Teilsumme False Positives: Viele Mail-Verbindungen zu anderen Rechnern im Internet 6 8 Port-Scans 1 1 Wurm Conficker 1 1 Teilsumme 8 10 Summe der vom LRZ endeckten Fälle Tabelle 13: Kompromittierte Rechner, die vom LRZ selbst entdeckt wurden Bei den selbst entdeckten Fällen (siehe Tabelle 13) kann man False-Positives leider nicht ganz vermeiden. Im Falle des Mail-Monitoring handelte es sich um lange Zeit vollkommen unauffällige Rechner, die plötzlich ein ungewöhnliches Mail-Aufkommen zeigten. In diesen Fällen gab es auch keine Hinweise für

43 Jahresbericht 2009 des Leibniz-Rechenzentrums 37 eine legitime Mail-Quelle: Die Rechner hatten weder einen aussagekräftigen DNS-Namen noch konnte auf dem Mail-Port ein Mail-Server kontaktiert werden. Zum Glück war in den meisten dieser Fälle das verdächtige Mail-Aufkommen der betroffenen Rechner nicht besonders hoch; die zuständigen Netzverantwortlichen wurden deshalb überwiegend nur informiert und die Rechner nicht sofort gesperrt. Es handelte sich meist um erst kürzlich in Betrieb genommene Mail-Server oder -Gateways oder um Rechner, von denen nur relativ selten (oder auch nur einmalig) Rundbriefe, Einladungen, usw. an sehr viele Empfänger verschickt wurden Besondere Ereignisse Im Jahr 2009 gab es die folgenden besonderen Entwicklungen und Ereignisse: Der Wurm Conficker tauchte im Oktober 2008 auf und treibt seit dieser Zeit auch im MWN sein Unwesen. Zu Beginn verbreitete sich Conficker ausschließlich über eine kritische Schwachstelle, durch die er selbständig von außen in einen Windows-Rechner eindringen konnte. Microsoft stellte schon Ende Oktober 2008 einen Security-Patch zum Schließen dieser Lücke bereit. Spätere Versionen von Conficker können sich zusätzlich noch über Netz-Laufwerke und Wechseldatenträger (wie z.b. USB-Sticks) verbreiten. Auch nach mehreren Monaten nahm im MWN die Zahl der Neuinfektionen nicht ab. Deshalb wurde Anfang August 2009 ein spezialisiertes Intrusion-Detection-System (IDS) in Betrieb genommen, mit dem man infizierte Rechner finden kann. Das IDS wurde später erweitert, damit es auch den Wurm Torpig erkennen kann. Trotz dieser Maßnahmen war Conficker auch Ende 2009 im MWN immer noch sehr aktiv Fälle Beschwerden Abbildung 9 Entwicklung der Fälle wegen Verletzung des Urheberrechtsgesetzes seit 2003 Die Zahl der Fälle wegen Copyright-Verletzungen hat gegenüber 2008 mit 239 Fällen um knapp 140% (!) auf 570 Fälle zugenommen (siehe auch Abbildung 9). Es handelte sich dabei um Beschwerd s von Organisationen, die amerikanische oder europäische Rechte-Inhaber vertreten. Selbst wenn diese Fälle bis jetzt noch keine juristischen Konsequenzen haben, sind es keine Kavaliersdelikte; auch nach deutschem Recht ist es verboten, copyright-geschütztes Material (überwiegend Filme und MP3s und teilweise auch Software) in File-Sharing-Netzen anzubieten. Unabhängig davon verstößt es auch gegen die Nutzungsordnung des LRZ bzw. MWN. Das DFN-CERT beobachtet und analysiert eine Reihe von Quellen, um Probleme zu entdecken, die sich auf Systeme der DFN-Anwender beziehen. Darüber hinaus werden eigene Sensoren betrieben, um die Informationsbasis weiter auszudehnen. Das DFN-CERT sammelt, korreliert und normiert die-

44 38 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme se Daten und stellt jedem DFN-Anwender den Zugriff auf die Daten seiner Einrichtung zur Verfügung. Das LRZ nutzt seit Mitte März 2009 diesen Dienst Automatische Warnungen und erhält in diesem Rahmen entsprechende Hinweis-Mails. Da an das MWN mehr als Endsysteme angeschlossen sind, trifft beim LRZ an nahezu jedem Werktag eine Warnung ein, die fast immer mehrere auffällig gewordene IP-Adressen enthält wurden mehrere Phishing-Angriffe auf Mail-Accounts von MWN-Teilnehmern durchgeführt, auf die leider einige Teilnehmer hereinfielen. Auch bei Wissenschaftlern hat sich immer noch nicht herumgesprochen, dass man nach einer Aufforderung per niemals Account-Daten herausgeben darf. Durch entsprechende Schutzeinrichtungen bei den Mail-Systemen des LRZ konnte aber verhindert werden, dass die gestohlenen Mail-Accounts in großem Umfang zum Versenden von Spam-Mails missbraucht wurden. Ende 2009 wurde entdeckt, dass neben den legitimen DNS-Domains des LRZ (lrz-muenchen.de, lrz.de usw.) eine Reihe von sogenannten Tippfehler-Domains registriert wurden, d.h. Domains mit ähnlich klingendem Namen wie z.b. lrz-munchen.de (kein e nach dem u ) oder lry.de (bei einer englischen Tastatur sind die Buchstaben z und y miteinander vertauscht). Für diese Domains wurde das DNS so konfiguriert, dass beliebige Kombinationen von z.b. *.lrzmunchen.de auf zwei Rechner gelenkt wurden, auf denen ein SSH-Server lief. Diese Konstruktion diente möglicherweise dazu, Kennungen und Passwörter von Benutzern zu stehlen, die sich bei der Eingabe des Rechnernamens vertippt hatten. Als Konsequenz hat das LRZ seine Kunden entsprechend gewarnt. Außerdem hat das LRZ bei seinen eigenen DNS-Servern alle bekannten Tippfehler-Domains eingetragen; dadurch haben diese innerhalb des MWN nicht mehr funktioniert. Wer sich allerdings außerhalb des MWN befindet (z.b. zuhause am privaten PC), sollte bei der Eingabe von Rechnernamen sehr sorgfältig sein. Das LRZ untersucht auch, ob man gegen diesen offensichtlichen Missbrauch mit rechtlichen Schritten erfolgversprechend vorgehen kann. Von diesem Problem sind auch noch andere große Einrichtungen im MWN betroffen. Zur legitimen Domain tu-muenchen.de existiert z.b. die Tippfehler-Domain tumuenchen.de (ohne Minuszeichen). gibt sich sogar als der Web-Server der TU München aus. Auch 2009 waren die Spammer wieder sehr aktiv und haben viele kompromittierte Rechner im MWN dazu missbraucht, Spam-Mails zu verschicken. Dabei ist es keine Seltenheit, wenn ein Rechner mehr als Spam-Mails pro Stunde verschickt. In diesem Zusammenhang gab es auch den absoluten Rekord an externen Beschwerden seit 1998: Als Reaktion auf eine besonders aktive Spam-Schleuder trafen 177 (!) Beschwerden ein. In einer Phishing-Aktion wurden die Zugangsdaten zu diversen Bankkonten gestohlen (Kontonummern, PINs, TANs usw.). Daran beteiligte Kriminelle haben danach einen kompromittierten MWN- Rechner dazu missbraucht, von dort Online-Überweisungen durchzuführen und damit von den gekaperten Bankkonten Geld ins Ausland zu schaffen. Als Folge haben innerhalb von wenigen Wochen 8 Polizeidienststellen und Staatsanwaltschaften entsprechende Auskunftsersuchen an das LRZ geschickt IT-Bibliotheksverbund Bayern Seit Mai 2008 ist das Rechenzentrum der Verbundzentrale des Bibliotheksverbundes Bayern (BVB) in das LRZ integriert. Es handelt sich um insgesamt 160 Betriebssysteminstanzen (Solaris, Linux, Windows), die teils auf physischen, teils auf virtuellen Maschinen realisiert sind. Die physischen Maschinen und die Wirtssysteme für die virtuellen Solaris-Systeme werden dabei vom BVB-IT-Team betrieben, während die virtuellen Linux- und Windows-Systeme auf der VMware-Farm des LRZ (siehe Abschnitt Virtualisierung) laufen. Die Betreuung der Anwendungen geschieht nicht durch das LRZ, sondern durch die Verbundzentrale des BVB in der Bayerischen Staatsbibliothek. Zum einen dienen die Systeme als Lokalsysteme der angeschlossenen Bibliotheken (alle Fachhochschulbibliotheken, sechs Universitätsbibliotheken, viele weitere staatliche Bibliotheken) und verwalten die Datenbanken mit den Katalogen, die Such- und Bestellmöglichkeiten (OPAC) für die Bibliotheksnutzer, die Verwaltung der Ausleihe und zahlreiche weitere Dienste. Zum anderen wird eine Verbunddatenbank von etwa 1 Terabyte Größe betrieben, die mit den lokalen Datenbanken abgeglichen wird, und die

45 Jahresbericht 2009 des Leibniz-Rechenzentrums 39 zur Suche im gesamten Verbund und für die Fernleihe aus anderen Bibliotheken gebraucht wird. Die eingesetzte Software ist hauptsächlich SISIS als Bibliothekssystem und Sybase als Datenbank auf den Lokalsystemen sowie Aleph als Bibliothekssystem und Oracle als Datenbank auf den Verbundsystemen. Als Suchmaschine wird Fast eingesetzt. Viele weitere Softwareprodukte für die zentrale Fernleihe, für kontextsensitive Verlinkung, für Web-Oberflächen, zur Digitalisierung und für andere Aufgaben werden daneben verwendet. Die Verbundsysteme und die Lokalsysteme dienen hauptsächlich den Bibliotheken des Bibliotheksverbundes Bayern (BVB) und des Kooperativen Bibliotheksverbundes Berlin-Brandenburg (KOBV), mit dem eine enge Zusammenarbeit besteht. Nur einzelne Bibliotheken außerhalb dieses Bereiches werden mitversorgt Rechnerbeschaffung Ein Teil der Rechnersysteme des Bibliotheksverbunds Bayern (BVB) sind veraltet und müssen dringend abgelöst werden. Daher wurde im Frühjahr ein entsprechender Großgeräteantrag begonnen. Der Antrag beschäftigt sich mit der Ersetzung eines Großteils der Rechnersysteme des BVB, sowie mit einer Erweiterung bestehender Systeme zur Steigerung der Redundanz und Leistungsfähigkeit. Der Antrag wurde am in vollem Umfang genehmigt. Als erste Charge wurde noch 2009 ein HP-Bladecenter mit 16 Rechnern geliefert, das 2010 für den Suchmaschinencluster des Verbundsystems in Betrieb genommen wird Zentrale Authentifizierung und Sicherheitskonzept Fast alle BVB-Server wurden zusätzlich zur lokalen Authentifizierung an den LRZ-SIM-Server zur zentralen Authentifizierung angebunden. Außerdem wurde den Dienstebetreuern die Möglichkeit gegeben, über sudo definierte administrative Aktionen nach einer Authentifizierung am LRZ-SIM-Server durchzuführen. Durch dieses Konzept wurden folgende Verbesserungen erreicht: Single Sign On, keine lokalen administrativen Rechte mehr notwendig, Nachvollziehbarkeit administrativer Änderungen Firewall-Cluster Die zentrale Firewall der BVB-Netze im LRZ wurde von einer Einzelserverlösung mit Standby-Maschine auf eine Clusterlösung umgebaut. Die Lösung hat sich nach einigen Anlaufschwierigkeiten als sehr zuverlässig und leistungsfähig erwiesen Virtualisierung VMware Im Laufe des Jahres wurden einige Altsysteme durch den Einsatz der zentralen LRZ-VMware-Umgebung ersetzt. Unter anderem wurden folgende Systeme bzw. Dienste virtualisiert: Allegro WebOPACs Opus-Server Windows ADS-Domaincontroller Fast-Suchmaschinen der lokalen Bibliothekssysteme der Fachhochschulen und der staatlichen Bibliotheken Weiterhin wurde der neue Dienst Webcontrol für die Bibliotheken auf virtuellen Systemen bereitgestellt. Als Entlastung der alten Windows-Domainencontroller und zum Aufbau der neuen Citrix-Farm, die 2010 die alte Farm mit 13 Rechnern ablösen wird, sind 4 neue virtuelle Windows-Systeme auf der VMware- Farm des LRZ in Betrieb genommen worden. Insgesamt betreibt das LRZ 15 virtuelle Maschinen auf Basis von VMware für den BVB.

46 40 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme Solaris-Zonen Die betriebssystemnahe Virtualisierung über Solaris-Zonen wurde für eine Vielzahl von alten und neuen Diensten eingesetzt. Folgende Dienste wurden auf Solaris-Zonen migriert oder produktiv gesetzt: Infoguide/Touchpoint des Verbundsystems und lokaler Bibliothekssysteme Metalib Kontextsensitive Verlinkung SFX Zentrale Fernleihe (ZFL) SISIS Lokalsysteme Der Einsatz von Solaris-Zonen im Sun-Cluster konnte erprobt werden. Die Erkenntnisse daraus wurden in das Konzept zur Ersetzung der Serverinfrastruktur in den Großgeräteantrag eingebracht. Durch den Einsatz von Solaris-Zonen konnte auf Seiten der lokalen Bibliothekssysteme eine Trennung des Backend- und Frontendsystems durchgeführt werden. Neben der erhöhten Sicherheit durch diese Trennung ermöglicht dies auch eine flexiblere Gestaltung der Web-OPACs und so eine einfachere Anpassung für die einzelnen Bibliotheken. Der Einsatz von gesicherten Verbindungen über HTTPS konnte so verwirklicht werden. Insgesamt werden ca. 40 Solaris-Zonen betrieben, 30 davon wurden 2009 neu eingerichtet Neue Hardware für Mybib Ein weiteres Mybib-System von Imageware (webbasiertes Workflowsystem zur elektronischen Dokumentenlieferung und Digitalisierung) wurde für die Staatsbibliothek installiert und wird jetzt im Housing- Betrieb vom LRZ betreut Neue Dienste Um den Zugang zum Internet in den Benutzerräumen der Bibliotheken einzuschränken bietet OCLC als Zusatzkomponente zu den SISIS-Lokalsystemen Webcontrol an. Dieser angepasste http-proxy nutzt das Lokalsystem u.a. zur Authentifizierung der Nutzer. Dieser Dienst wird vom BVB angeboten und ist für sechs kleinere Bibliotheken im Einsatz. Die Webcontrols laufen auf VMware-Maschinen. Die Seite des DFG Projekts Generischer Linkresolver und die zugehörigen Webanwendungen werden auf einer Solaris Zone produktiv gesetzt. Siehe auch

47 sync async Jahresbericht 2009 des Leibniz-Rechenzentrums 41 2 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme 2.1 Entwicklung bei der Datenhaltung Überblick Aus Sicht der Systemarchitektur gliedert sich die Datenhaltung in die Massenspeicher der Archiv- und Backupsysteme mit den Bandbibliotheken (Abschnitt 2.1.2), auf die sich die Langzeitarchivierung (Abschnitt 2.1.3) abstützt, und den Bereich der Onlinespeicher (Abschnitt 2.1.4), bei denen wiederum zwischen NAS(Network Attached Storage)- und SAN(Storage Area Network)-basiertem Datenspeicher unterschieden wird. Der Umfang der in den Bandbibliotheken gespeicherten Daten wuchs im Jahr 2009 von 5 Petabyte auf über 9 Petabyte an. Um den Zuwachs zu bewältigen, wurden in erheblichem Umfang neue Kassetten beschafft und die Bandlaufwerke des Hochleistungsarchivs durch neue Laufwerke ersetzt, die in der Lage sind, die Kassetten in doppelter Dichte zu beschreiben. Am LRZ selbst und an den anderen Kommissionen der Bayerischen Akademie der Wissenschaften wird gemeinsam nutzbarer, hochverfügbarer NAS-Speicher eingesetzt. Der Dienst wurde zum Wintersemester 2008 erstmals im Rahmen des Großprojekts IntegraTUM angeboten und ist im Anschluss an Integra- TUM, das im September 2009 erfolgreich abgeschlossen wurde, in den Regelbetrieb übergegangen. Auf dem Gebiet der Langzeitarchivierung führte die Zusammenarbeit mit der Bayerischen Staatsbibliothek zu sehr effizienten Ergebnissen, von denen alle Beteiligten profitieren. Neben den gemeinsamen, forschungsorientierten Arbeitsgebieten, wie z.b. im DFG-geförderten Projekt BABS2, übernahm das LRZ außerdem Aufgaben eines IT-Providers für die Bayerische Staatsbibliothek. Die Massendigitalisierung des urheberrechtsfreien Buchbestands der BSB durch Google hat im Jahr 2009 ganz erheblich an Fahrt aufgenommen. Kontinuierlich wuchs die Anzahl an gescannten Büchern, die am LRZ aufbereitet und archiviert wurden. 10 GE Ethernet TB 6070C 68 TB 50 TB 3050C 67 TB TSM Server TSM Server Servercluster TSM Server async NAS TB 6070r 95 TB 210 TB R TB 96 Port Storage Area Network 96 Port Massenspeicher Bibliothek mit Stellplätzen und 20 Bandlaufwerken Disk Cache + DB 100 TB Bibliothek mit Stellplätzen und 20 Bandlaufwerken Abbildung 10 Beantragte Erweiterungen

48 42 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme In einem Großgeräteantrag wurde 2009 die Beschaffung eines hochverfügbaren Speichers für die Server- Virtualisierung, die Erweiterung vorhandener Plattenspeichersysteme und die Ersetzung eines technisch veralteten Archiv- und Backupsystems beantragt (farbliche Codierung siehe Abbildung 10). Der Antrag wurde genehmigt und die beantragten Komponenten wurden in der zweiten Jahreshälfte beschafft und teilweise noch in 2009 installiert. Der Produktionsbetrieb wird im Frühjahr 2010 aufgenommen Archiv- und Backupsystem Das Archiv- und Backupsystem des LRZ besteht aus zwei großen Systemen mit Bandrobotern: einem (neueren) Hochleistungssystem HABS und einem (älteren) System mit LTO-Bandlaufwerken für moderatere Anforderungen (LABS). Softwareseitig wird das gesamte System mit dem Tivoli Storage Manager (TSM) von IBM betrieben. Sowohl Hardware als auch Software werden ständig weiterentwickelt. Auf Softwareseite fand 2009 ein kleinerer TSM-Releasewechsel von Version 5.4 auf 5.5 statt. Auf der Hardwareseite wurden die Titanium-A-Laufwerke des HABS durch Titanium-B-Laufwerke ersetzt. Es wurden eine weit gehende Ersetzung des LABS beantragt, die Ausschreibung durchgeführt und erste Lieferungen installiert. Migration von Titanium A auf Titanium B Im Sommer 2009 wurden alle 26 Bandlaufwerke des HABS vom Typ Titanium A durch eine weiterentwickelte Version der Laufwerke (Modell B) ersetzt. Die neuen Laufwerke sind in der Lage, die vorhandenen Kassetten in doppelter Dichte (1 Terabyte statt 0,5 Terabyte) zu beschreiben. Dies bedeutet, dass die alten Kassetten (6.000 Stück), die eine erhebliche Investition darstellen, weitergenutzt werden konnten. Im Laufe des Sommers wurde der gesamte Datenbestand der Bibliothek (5.000 TB) umkopiert, um die höhere Kapazität nutzen zu können. Die Kapazität der Bibliothek konnte so verdoppelt werden. Zusätzlich wurde die Bibliothek weiter ausgebaut. Sie umfasst nun Stellplätze (slots) für Kassetten. Ein wichtiger und gewünschter Nebeneffekt der Migration ist die Tatsache, dass beim Umkopieren sämtliche Daten mindestens einmal komplett gelesen werden und dadurch eventuelle Schäden frühzeitig erkannt werden (periodisches Prüflesen zur Sicherstellung der Lesbarkeit). Ersatz für das LTO-Archiv- und Backupsystem Das System LABS dient primär der Datensicherung kleiner bis mittlerer Serversysteme, daneben auch der Archivierung kleiner bis mittlerer Datenmengen. Die Ersetzung des Systems ist vor allem wegen der unzureichenden Kapazität und I/O-Leistung der 8 Jahre alten LTO2-Technologie sowie der hohen Wartungskosten dringend notwendig. Der Großgeräteantrag zur Ersetzung des Systems, der im März eingereicht wurde, wurde im Frühsommer positiv beschieden. Noch im Sommer wurde eine europaweite Ausschreibung für ein neues System (siehe Abbildung 11) gestartet. Aus der Ausschreibung ging die Firma SUN Microsystems als Sieger hervor. Vertragsabschluss war Anfang November, erste Komponenten des Systems wurden noch im Dezember geliefert. Zur Überbrückung der Zeit bis zur Inbetriebnahme des neuen Systems wurden sechs weitere Bandlaufwerke der neuesten LTO-Generation in einer der beiden älteren Bandbibliotheken installiert. Sie dienen gleichzeitig der Erprobung der neuen Technologie und dem Auffangen von Kapazitätsengpässen an diesen Systemen. Konkret wurden die Archivkopien, die das LRZ für das Rechenzentrum der Max-Planck- Gesellschaft aufbewahrt, auf LTO4 verlagert und analog zur Migration von Titanium A auf Titanium B wurden 90% der Daten auf den LTO2-Bändern der Bandbibliothek auf LTO4-Bänder migriert. Untersuchung neuer Technologien Die rasche technologische Weiterentwicklung und das beständige Wachstum im Speicherumfeld erfordern kontinuierliche Tuning-Maßnahmen sowie die Evaluation und den Einsatz neuer Technologien. Besonders zu nennen sind hier - die Einführung des Dreiwegeverfahrens für NDMP-Backups und - die Untersuchungen zur Multipathing-Anbindung von Storage-Komponenten, - die Tests zur Eignung von Solid State Disks als TSM Disk Cache und - die Evaluation von TSM Release 6, das 2010 eingesetzt werden soll.

49 Jahresbericht 2009 des Leibniz-Rechenzentrums 43 9 x Worker 2 Quad Core, 3 rd -Level Cache, 2.8 GHz 48 GB DDR3 Memory 1 x Dual-Port 10 Gbit Ethernet PCI Express 2 x Dual-Port 8 Gbit FC HBA 256 GB SSD 3 x Mgmt 1 Quad Core, 3 rd -Level Cache, 2.26 GHz 16 GB DDR3 Memory 2 x Dual-Port 8-Gbit FC HBA Disk Storage Subsystems 12,8 GB/s, IOPS sustained, 32 GB Cache SATA Disks 192 x 1 TB ~ 192 TB FC Disks 96 x 146 GB ~ 14 TB Flash or FC Disks 12 TB Flash or 6 TB Flash + ~19 TB FC or 288 x 146 GB ~ 42 TB FC Automated Tape Library 6100 Slots 16 x LTO4 tape drives 1500 LTO4 Cartridges Abbildung 11 LABS-Ersatz TSM-Workshop Im November 2009 hat erstmalig ein ganztägiger Kurs zur Einführung in das Archiv- und Backupsystem stattgefunden. Der Kurs bestand aus einem Vortragsprogramm am Vormittag, sowie einem optionalen Hands-On-Workshop für TSM-Einsteiger am Nachmittag. Der Workshop war ausgebucht, und auch die Vorträge waren gut besucht. Es ist geplant, den Workshop von nun an einmal jährlich durchzuführen. Abgleich personenbezogener Daten Die Pflege der Kontaktdaten der über 1100 Ansprechpartner auf Kundenseite in den verschiedenen Einrichtungen, die das Archiv- und Backupsystem nutzen, ist eine ebenso wichtige wie zeitraubende Aufgabe beim Betrieb des Archiv- und Backupsystems. Die Fluktuation im Hochschulbereich ist sehr hoch, Ansprechpartner wechseln häufig. Dennoch muss die Zuordnung der Daten zu für sie verantwortlichen Personen sichergestellt werden, damit das System nicht zum Datenfriedhof wird. Bisher wurden die personenbezogenen Daten in einem eigenen, unabhängigen Datenbanksystem mit Webschnittstelle (DATWeb) verwaltet. Im Laufe des Jahres wurde damit begonnen, die personenbezogenen Daten in DATWeb mit den Daten in der zentralen LRZ-Benutzerverwaltung (SIM) abzugleichen und gleichzeitig mit Altlasten aufzuräumen. Nach Abschluss der Aktion sollen personenbezogene Daten nur noch in SIM vorgehalten werden. Konfiguration HABS Ende 2009 Das Hochleistungsarchiv- und Backupsystem HABS (siehe Abbildung 12) besteht aus 16 Serverrechner Sunfire-X4200, 4 Serverrechner Sunfire-X4200m2 für HPC (HLRB II), 2 SAN-Direktoren Brocade Silkworm48000, Je 2 Storage-Server STK FLX380 und SUN 6540 mit 115 Terabyte FCAL Platten und einer Tape-Library STK SL8500 mit Kassetten-Stellplätzen mit 26 STK Ti10000B Laufwerken.

50 44 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Auf dem System laufen 26 TSM-Serverinstanzen mit einer aggregierten I/O-Bandbreite von mehreren Gigabyte/s. Dieser Teil des ABS steht primär den Kunden mit hohen Leistungsanforderungen zur Verfügung. Ein im Hinblick auf die Performance besonders optimierter Teil von HABS besteht aus 4 Sunfire- X4200m2 Server und je einer TSM-Serverinstanz mit speziell konfigurierten Platten. Er dient der Archivierung der Daten des HLRB II. Jeder dieser Server erreicht Transferraten von bis zu 480 MB/Sek bei der Archivierung unter TSM, d.h. den HLRB II-Nutzern steht ein Archivsystem mit einer aggregierten Bandbreite von fast 1 Gigabyte/s zur Verfügung. Konfiguration LABS Ende 2009 Das LTO-Archiv und Backupsystem LABS (siehe Abbildung 13) steht Nutzern mit etwas moderateren Leistungsanforderungen zur Verfügung. Es besteht aus 18 Servern IBM X-Series X346, 4 FC-Switches Brocade Silkworm 3900, 5 Storage-Servern IBM FastT900 alias DS4500 mit insgesamt 95 Terabyte FCAL und SATA Platten, 2 IBM 3584 alias TS3500 Tape Libraries mit je 12 Frames und je 5000 Kassetten-Stellplätzen sowie insgesamt 40 IBM LTO2 Laufwerken (3 davon als Ersatzlaufwerke), 10 LTO4 Laufwerke in einer der IBM 3584 Libraries. Auf diesem System laufen 23 TSM-Serverinstanzen. Statistische Daten Ende 2009 waren in den 3 Libraries Terabyte, verteilt auf 6 Milliarden Dateien gespeichert. Täglich wurden auf die Systeme durchschnittlich 28 Terabyte neu geschrieben, zu Spitzenzeiten mit einer Geschwindigkeit von 2 GB/Sek. Die Daten stammten von Servern des MWN aus 430 Einrichtungen der Münchner Hochschulen. Im Vergleich zum Vorjahr sind Last und Datenmenge weiter gestiegen. Der Zuwachs lag etwas über den Erwartungen. Der Bestand an Kassetten in den 3 Libraries wuchs 2009 von auf an. Die Gesamtanzahl der Kassetten ist nur bedingt als Indikator für den Zuwachs tauglich, da die Kapazitäten der Kassetten je nach Technologie stark variieren (200 GB bis TB). Jeder Rechner oder jeder Rechnerverbund, der auf das Archiv- und Backupsystem zugreifen will, muss unter TSM als sogenannter Node registriert sein. Die Anzahl der Nodes entspricht damit in etwa der Anzahl der Systeme, die ihre Daten im Archiv- und Backupsystem ablegen wurden weit über 1200 Nodes neu registriert und 600 alte Nodes inklusive ihrer gespeicherten Daten gelöscht. Durch das explizite Löschen von Nodes sowie durch automatische Löschprozesse nicht mehr benötigter Daten wird dafür gesorgt, dass das Archiv- und Backupsystem nicht zum Datengrab wird. Um die Datenflut soweit wie möglich zu begrenzen, ist es notwendig, den Kunden des Archiv- und Backupsystems den Umfang ihrer abgelegten Daten bewusst zu machen und sie zum sinnvollen Umgang mit den vom LRZ zur Verfügung gestellten für sie kostenlosen Ressourcen anzuhalten. Ein eigens für diesen Zweck bereitgestellter Server erlaubt es den Kunden, sich direkt umfassend über den eigenen Datenbestand zu informieren. Gleichzeitig werden die Nutzer in regelmäßigen Abständen von diesem Server über die von ihnen verbrauchten Speicherressourcen via informiert. Integriert sind Werkzeuge, die der betrieblichen Überwachung und Analyse der Systeme dienen. Nutzer mit besonders auffälligem Datenprofil werden direkt angesprochen. Alle Kontaktdaten werden zusätzlich regelmäßig auf ihre Aktualität überprüft. Entsprechend den Benutzungsrichtlinien werden Daten, zu denen sich keine Ansprechpartner mehr ermitteln lassen, nach Ablauf einer festgelegten Frist gelöscht. Zur Erhöhung der Datensicherheit spiegelt das LRZ seine Archivdaten an das Rechenzentrum der Max- Planck-Gesellschaft in Garching (2,1 Petabyte) und umgekehrt (3,6 Petabyte). Den Zuwachs von Speicherbelegung und Dateneingang im Laufe des Jahres 2009 zeigen Abbildung 14 und Abbildung 15.

51 Jahresbericht 2009 des Leibniz-Rechenzentrums 45 Abbildung 12 Hochleistungsarchiv- und Backupsystem HABS Ende 2009

52 46 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Abbildung 13 LTO-Archiv- und Backupsystem LABS Ende 2009

53 Jahresbericht 2009 des Leibniz-Rechenzentrums Backup Archiv Jan Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Abbildung 14 Datenverkehr (Gigabytes/Monat) Der Archiv-Anteil am Datenbestand ist relativ statisch, d.h. es gibt nur wenige Änderungen an den Dateien im Archiv. Archivdaten werden in der Regel einmal ins Archiv übertragen und dort sehr lange aufbewahrt, im Fall der Langzeitarchivierung für Jahrzehnte. Datensicherungen finden regelmäßig statt. Backupdaten werden dagegen häufig ins System geschrieben und die veralteten Daten werden automatisch aus dem Bestand gelöscht. Durch diese Dynamik erklärt sich die im Vergleich zur Archivierung mehr als doppelt so hohe Dateneingangsrate. Der starke Einbruch im Juni 2009 ist im Wesentlichen auf eine mehrwöchige Unterbrechung des Kopierprozesses für Archivdaten vom RZG zurückzuführen. Wegen eines temporären Ressourcenengpasses war es unumgänglich, den Dateneingang für einige Zeit stark einzuschränken. Erst durch die Inbetriebnahme der Titanium-B-Laufwerke hat sich die Situation wieder entspannt Backup Archiv Jan Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Abbildung 15 Datenumfang in Terabytes

54 48 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme 100 Petabyte Archiv und Gebäudeweiterung An dem für das Jahr 2011 geplanten Supercomputer SuperMUC der nächsten Generation werden deutlich mehr Daten anfallen als bisher, für die Nearlinespeicher bereitgestellt werden muss wurden dazu erste Überlegungen angestellt, insbesondere mussten bereits einige Randbedingungen für die Planung der Gebäudeerweiterung festgelegt werden. Im Rechnerwürfel des LRZ steht im Augenblick für die Geräte des Archiv- und Backupbereichs nahezu ein gesamtes Stockwerk mit 560 m 2 Nutzfläche zur Verfügung, der sogenannten DAR (Daten- und Archiv-Raum). Die Dimensionierung erlaubte bisher eine optimale Aufstellung der Geräte. Die sicherheitstechnischen und klimatischen Randbedingungen waren gut geeignet für die langfristige, sichere Aufbewahrung großer Datenmengen. Die Erweiterung des Gebäudes wird Raum für weitere Optimierung lassen. In Zukunft sollen im DAR nur noch Libraries betrieben werden, alle anderen Geräte werden in Räume in der Gebäudeerweiterung umgezogen. Es wird erwartet, dass für den neuen Supercomputer während seiner Standzeit Speicher in der Größenordnung von 100 PB bereitgestellt werden muss. Ein Grobkonzept für eine mehrstufige Installation der dazu notwendigen Komponenten musste bereits 2009 festgelegt werden, damit die Gebäudeplanung sich daran orientieren konnte. Abbildung 16 DAR: Von links nach rechts: 2 LTO-Libraries, Platten u. Server, Library SL8500 Mit einer durchschnittlichen Leistungsaufnahme von unter 50 KW ist der Raum ein Aushängeschild für Green-IT. Der geringe Energiebedarf ist darauf zurückzuführen, dass in dem Raum primär Bandbibliotheken, deren Stromverbrauch gemessen an der Speicherkapazität sehr gering ist, stehen Langzeitarchivierung Das LRZ als Service-Provider für digitale Langzeitarchivierung Veröffentlichungen in digitaler Form nehmen im Wissenschaftsbetrieb wie auch im gesellschaftlichen Leben einen immer höheren Stellenwert ein. Oft wird, wie z. B. bei Dissertationen und bei amtlichen Publikationen, auf ein gedrucktes Pendant ganz verzichtet. Während die Digitalisierung für die Nutzer den Zugang und den Umgang mit der Information beschleunigt und insgesamt erleichtert, entstehen aus organisatorischer, rechtlicher und technischer Sicht neue Herausforderungen. Die Objekte sollen nicht nur verwaltet und gespeichert, sondern auch langfristig zugänglich gemacht werden. Diese Aufgabe wird erschwert durch den raschen technologischen Wandel im Bereich der Hard- und Software und der Datenträger.

55 Jahresbericht 2009 des Leibniz-Rechenzentrums 49 Seit 2004 besteht eine Kooperation zwischen der Bayerischen Staatsbibliothek (BSB) und dem Leibniz- Rechenzentrum, die inzwischen durch drei DFG-geförderte Projekte (BABS, BABS2 und vd16digital) und der BSB-Google Partnerschaft ausgeweitet wurde. Dabei tritt das LRZ für die BSB als Dienstleister für die Langzeitarchivierung, das Attended Housing von Clusterknoten und Hosting von virtuellen Servern auf. Die langfristige Speicherung der Daten übernimmt bei allen Projekten das Archiv- und Backupsystem des LRZ mit dem Softwarepaket Tivoli Storage Manager (TSM) der Firma IBM. TSM verfügt über alle wesentlichen Funktionalitäten, die für Langzeitarchivsysteme Voraussetzung sind. Das Gesamtsystem deckt damit alle wichtigen Bereiche eines langfristig funktionierenden Archivs ab und folgt dem allgemeinen Open Archival Information Systems -Referenzmodell (OAIS). Weitere Details über die hier aufgeführten Langzeitarchivierungsprojekte können über die LRZ- Homepage im Bereich Projekte (http://www.lrz.de/projekte/langzeitarchivierung) gefunden werden. Abbildung 17 und Abbildung 18 zeigen die Entwicklung der Anzahl der Archivobjekte und des Datenvolumens des Langzeitarchivs von Januar 2005 bis Januar Der starke Anstieg der Dateianzahl ab März 2009 ist durch den Produktivbeginn der Archivierung der Google-Digitalisate zu erklären. Bisher wurden von der BSB mehr als 300 Millionen Objekte mit einem Datenvolumen von fast 200 TByte am LRZ archiviert. In Abbildung 18 ist dieser Anstieg weniger auffällig, da die Größe der einzelnen Google- Digitalisate im Vergleich zu den übrigen Digitalisaten eher gering ist. Die aus Sicherheitsgründen erstellte Zweitkopie auf einem weiteren Magnetband verdoppelt in der Praxis die Objektanzahl und das Datenvolumen. Sie ist in den Diagrammen nicht berücksichtigt. Abbildung 17 Objektanzahl im LRZ-Archiv Abbildung 18 Datenvolumen im LRZ-Archiv

56 50 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Neben den Archiv- und Backupdiensten betreibt das LRZ für die BSB einen NAS-Filer, über den Speicherplatz für verschiedene BSB-Projekte bereitgestellt wird. Dieser NAS-Speicher wurde im November 2009 (erneut) um zwei Diskshelves erweitert. Der zusätzliche Speicher kommt auch dem BSB-Google- Projekt zugute, das dort Dateien für die Online-Bereitstellung der Digitalisate ablegt. Der Filer verfügt nun über 14 Disk Shelves mit je 14 Platten. Ein Teil der Shelves ist mit kleinen, schnellen FC-Platten bestückt, der andere Teil mit großen, preisgünstigen SATA-Platten. Insgesamt verfügt der NAS-Filer über eine Bruttokapazität von 137 TB. Die Anzahl der am LRZ für die Staatsbibliothek gehosteten virtuellen Linux-Server ist im Jahr 2009 von 6 auf 13 angewachsen. Die Server dienen zum Archivieren und der Webpräsenz diverser Angebote der Bayerischen Staatsbibliothek: ANWENDUNG CORES BSB-Google: Download-Server, SGE-Job-Submission 4 BSB-Google: Archiv-Server 1 BSB-Google: Webserver 1 Verkündungsplattform: Webserver 1 Bayerische Landesbibliothek Online: Webserver 1 Digitalisate der Staatsbibliothek Bamberg: Webserver 1 Dokumenten-Server 1 Angebote der digitalen Bibliothek 1 Präsentation der dmgh 2 Reichstag Online 1 Biographieportal 4 Archivierung der Digitalisate der BSB (ohne Google) 1 SLES11-Ersatz 4 Projekt BABS2 Abbildung 19 Workflow des Bibliothekarischen Archivierungs- und Bereitstellungssystems

57 Jahresbericht 2009 des Leibniz-Rechenzentrums 51 Start für das DFG-geförderte Projekt BABS2 war Oktober Ziel des Kooperationsprojektes zwischen LRZ und BSB ist der prototypische Ausbau und die Evaluierung eines vertrauenswürdigen und skalierbaren digitalen Langzeitarchives als Teil des Netzwerks nestor für den Erhalt digitaler Information in Deutschland. Die technische und organisatorische Infrastruktur dieses Archivs wurde im Rahmen des Vorgängerprojekts BABS (Bibliothekarisches Archivierungs- und Bereitstellungssystem; realisiert. Der gesamte Workflow beginnend bei der Digitalisierung (Ingest), über das Daten-Management und die Archivierung, bis hin zum Retrieval (Access) ist in Abbildung 19 dargestellt. Im Kontext des Projektes wird unter Vertrauenswürdigkeit (engl. "trustworthiness") die Eigenschaft eines Systems verstanden, gemäß seiner Ziele und Spezifikationen zu funktionieren (d.h., das System tut genau das, was es tun soll). Digitale Langzeitarchive haben den Erhalt von Information zum Ziel, die durch digitale Objekte repräsentiert werden. Deshalb ist es notwendig, sowohl organisatorische als auch technische Maßnahmen zu ergreifen, um so Integrität, Authentizität und Vertraulichkeit sowie Verfügbarkeit und Nutzbarkeit der digitalen Objekte zu gewährleisten. Als Grundlage wird der "Kriterienkatalog vertrauenswürdige digitale Langzeitarchive" herangezogen, der von der nestor-arbeitsgruppe "Vertrauenswürdige Archive - Zertifizierung" unter Federführung der BSB und der Humboldt-Universität zu Berlin entwickelt wurde. Die Entwicklungen der letzten Jahre haben gezeigt, dass die Zuwächse an digitalen Daten, die der Langzeitarchivierung zugeführt werden, schwer abschätzbar sind. Dies zeigt sich sehr deutlich im Bereich der digitalen Sammlungen der BSB, wo exorbitante Steigerungen zu verzeichnen sind und alle Prognosen früherer Jahre immer wieder nach oben korrigiert werden mussten. Die Anzahl der Google-Digitalisate zum Beispiel stieg von 50 Millionen Dateien auf über 300 Millionen Dateien. Auch entsteht durch die anlaufende Pflichtablieferung elektronischer Publikationen eine nur schwer abschätzbare Menge weiterer Daten. Für die wichtige Frage nach der Skalierbarkeit bezüglich Datenvolumen und insbesondere bezüglich der Anzahl der archivierten Dateien eines digitalen Langzeitarchivs werden im Projekt BABS2 Lösungsansätze gesucht. Im Rahmen des Projektes wurde die Master Thesis mit dem Titel Scalability Analysis of Hierarchical Storage Management File Systems erstellt. Dabei wurde die Skalierbarkeit der beiden HSM-Systeme SAM/QFS der Firma SUN und TSM/HSM der Firma IBM untersucht. Die durchgeführten Tests haben gezeigt, dass SAM/QFS gegenüber TSM/HSM hinsichtlich Performance und Skalierbarkeit besser geeignet ist. Allerdings waren die Ergebnisse ernüchternd, da die Skalierbarkeit beider Systeme doch stärker als angenommen begrenzt ist. Um dennoch eine gut skalierbares Archivsystem zu erreichen war es ratsam, die Daten auf mehrere Archivierungsserver und mehrere Datenknoten (Nodes) aufzuteilen. Durch eine solche Partitionierung wurde ein großes unhandliches Archiv vermieden, das bei weiter steigendem Dateneingang bald nicht mehr zu managen gewesen wäre. Bei weiterem Wachstum ist es möglich, weitere Archiveinheiten hinzuzufügen. Die einzelnen Archiveinheiten bleiben in einer administrierbaren und handhabbaren Größe, was das Datenvolumen und die Anzahl der darin verwalteten Dateien angeht (siehe Abbildung 20). Auch die Datenmigration auf neue Magnetbandtechnologien wird durch das beschriebene Konzept erheblich erleichtert. Abbildung 20 Aufbau einer skalierbaren Archivierungskomponente

58 52 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Neben den Skalierungstests wurden seitens des LRZ Maßnahmen zur Sicherung der Integrität digitaler Objekte untersucht. Die Maßnahmen konzentrierten sich im Wesentlichen auf den Einsatz von Virenscannern, sowie die Generierung, Speicherung und Überprüfung von kryptografischen Prüfsummen und deren Einbindung in den Archivierungs- und Retrievalworkflow. Projekt BSB-Google Im Rahmen einer im Jahr 2007 begonnenen Public-Private-Partnership digitalisiert Google über einen Zeitraum von mehreren Jahren mehr als 1 Million urheberrechtsfreie Druckwerke aus dem Bestand der Bayerischen Staatsbibliothek (BSB). Die BSB erhält Kopien der Digitalisate, die am LRZ konvertiert, gespeichert, archiviert und über den OPAC der BSB weltweit zugänglich gemacht werden. Das LRZ unterstützt die BSB in diesem Projekt als Dienstleister und ist für die Langzeitarchivierung der Digitalisate, das Housing von Clusterknoten für die Formatmigration als Vorbereitung für die Web-Bereitstellung, das Hosting des Speichersystems und das Hosting virtueller Server für Archivierung und Web-Bereitstellung zuständig. Konkret stellt das LRZ zunächst drei virtuelle Server bereit, die sich um den Download, die Verarbeitung, Archivierung und Bereitstellung der Daten im Internet kümmern. Die Originaldateien, die die BSB von Google erhält, werden im Archiv- und Backupsystem des LRZ abgelegt. Die Dateien, die im Internet angeboten werden, werden am LRZ auf einem NAS-System gehostet. Die Umwandlung aller originalen Bilddateien in jeweils zwei Bilddateien mit niedriger Auflösung geschieht am LRZ auf dem Linux- Cluster. In Abbildung 21 ist die Infrastruktur sowie der Workflow im Projekt schematisch dargestellt. Abbildung 21 Workflow im Projekt Google Ende 2008 wurden von Google die ersten Digitalisate bereitgestellt. Bis Ende 2009 wurden rund Bücher heruntergeladen und verarbeitet, der Bestand an Archivdaten im Google-Projekt ist so bis Ende des Jahres auf 37,7 TB angewachsen:

59 Jahresbericht 2009 des Leibniz-Rechenzentrums Abbildung 22 Archivierte Daten in Terabyte Verkündungsplattform: Seit Januar 2009 stellt die Bayerische Staatskanzlei die Verkündungsplattform Bayern (https://www.verkuendung-bayern.de) als kostenfreien Bürgerservice bereit. Ziel ist die amtliche Verkündung von Gesetzen, Verordnungen und Bekanntmachungen des Freistaates Bayern über eine zentrale, fest eingerichtete Publikationsplattform im Internet. Die "Verkündungsplattform Bayern" wird im Auftrag der Bayerischen Staatskanzlei betrieben, wobei die redaktionelle und technische Umsetzung durch die Bayerische Staatsbibliothek erfolgt. Das LRZ betreibt als Dienstleister für die BSB die Hardware für die Webbereitstellung und übernimmt die Langzeitarchivierung der Amtsblätter der Bayerischen Ministerien. Alle Dokumente stehen ab dem Tag ihrer Verkündung auf Dauer elektronisch zur Verfügung. Seit 22. Januar 2009 wurden die vier Amtsblätter der bayerischen Ministerien auf eine elektronische Fassung umgestellt und kostenfrei über das Internet bekannt gemacht: Allgemeines Ministerialblatt (AllMBl), Bayerisches Justizministerialblatt (JMBl), Amtsblatt der Bayerischen Staatsministerien für Unterricht und Kultus und Wissenschaft, Forschung und Kunst (KWMBl) und das Amtsblatt des Bayerischen Staatsministeriums der Finanzen (FMBl). In diesen Amtsblättern werden Verwaltungsvorschriften und sonstige Bekanntmachungen des Freistaates Bayern verkündet. Münchner Arbeitskreis Langzeitarchivierung Der Münchener Arbeitskreis Langzeitarchivierung ist auf Initiative der Bayerischen Staatsbibliothek und der Generaldirektion der Staatlichen Archive Bayerns entstanden und vereint Institutionen aus dem Raum München, die sich aktiv mit der Langzeitarchivierung elektronischer Medien befassen. Der Arbeitskreis bietet die Möglichkeit eines Informations- und Erfahrungsaustausches auf lokaler Ebene und fördert den Transfer von Wissen über Methoden und Techniken. Bei den etwa halbjährlich stattfindenden Treffen an wechselnden Orten werden jeweils andere Themenschwerpunkte gesetzt. Ausgewählte Themen waren z.b. Massendigitalisierung, vertrauenswürdiges Archiv, Datenformatmigration. Eine detailliertere Beschreibung der einzelnen Projektinhalte im Bereich der Langzeitarchivierung ist auf der LRZ-Homepage (http://www.lrz.de/projekte/langzeitarchivierung) zu finden. Auch wenn im Kontext der Kooperation mit der Bayerischen Staatsbibliothek der größte Teil der Aktivitäten bezüglich der digitalen Langzeitarchivierung stattfindet, sollte die Zusammenarbeit mit anderen Einrichtungen wie dem Bayerischen Bibliotheksverbund (siehe Abschnitt 1.10) und der Bibliothek der Technischen Universität München, die die Speicher des LRZ für den bibliothekseigenen Medienserver nutzen, nicht unerwähnt bleiben.

60 54 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Online-Speicher Storage Area Network Wie in vielen großen Rechenzentren wird auch am LRZ sowohl ein Storage Area Netzwerk (SAN) als Grundlage für einen effizienten Datenverkehr, insbesondere für die Datensicherung, als auch die NAS- Architektur zur Bereitstellung von Plattenspeicher genutzt. visualization compute server printer server web server multi media afs clients W2K server Mailserver HLRB II tsm/tcpip rx CIFS NFS local area network / gigabit ethernet tivoli storage manager tsm servers, library manager afs fileservers NAS filers network attached storage storage area network STK SL8500 T10K-B 2 x IBM 3584 LTO2 + LTO4 4 x SUN 6540 FC 3 x IBM DS4500 SATA 2 x IBM DS4500 FC STK D280 FC NetAPP SATA NetAPP FC SUN SATA Storage systems Abbildung 23 Speicherarchitektur Das ursprüngliche SAN, dessen Anfänge auf das Jahr 2000 zurückgehen, wurde vor einigen Jahren in mehrere sogenannte Fabrics aufgeteilt, um so eine höhere Verfügbarkeit gewährleisten zu können. Es werden nun getrennte Fabrics für das Hochleistungsarchiv, das LTO-Archiv- und Backupsystem, das verteilte Filesystem und das SAN-Filesystem des Bundeshöchstleistungsrechners betrieben. An die SAN- Fabrics sind die Storageserver, die NAS-Filer, alle Bandlaufwerke der Libraries und alle Serversysteme mit hohem Datenverkehr, insbesondere die File- und Backupserver angeschlossen. Abbildung 24 zeigt die Topologie des Netzwerks auf den verschiedenen Stockwerksebenen des Rechnergebäudes. Gut zu sehen ist die Anbindung der diversen NAS-Filer, über die der sogenannte NDMP- Backup läuft. Insgesamt gibt es 4 getrennte Fabrics: - Redundantes SAN für das Hochleistungsarchiv: Basis sind zwei FC-Direktoren mit je 96 Ports. Die Direktoren werden als zwei getrennte Fabrics betrieben, um ein Höchstmaß an Ausfallsicherheit (redundant fabric) zu gewährleisten. - SAN für das LTO-Archiv- und Backupsystem: Die Verkabelung der 4 FC-Switches (4x32 Port) des LABS bildet eine Mesh-Struktur. - Redundantes SAN für AFS: Zwei 16 Port FC-Switches sorgen für die redundante Storageanbindung der AFS-Fileserver. - SAN für das CXFS-Filesystem des HLRB II.

61 Jahresbericht 2009 des Leibniz-Rechenzentrums 55 HRR HRLBII 128 AFS Port 128 Port 8 x NAS Home NSR AFS 16 AFS Port 16 Port 2 x NAS mass storage 2 x NAS SFS 2 x NAS BSB 2 x NAS LRZ 6 x NAS Linux HPC DAR LABS 32 Port 32 Port AFS 32 Port 32 Port 16 Port NAS Mirror SFS HABS 96 AFS Port 96 Port NAS Mirror LRZ Abbildung 24 SAN-Topologie Es werden ausschließlich Plattensysteme eingesetzt, deren Controller von LSI Logic stammen. Da die Geräte im Laufe mehrerer Jahre über verschiedene Ausschreibungen beschafft wurden, sind die Modellnamen trotzdem recht unterschiedlich: - StorageTek D280 Der Storageserver D280 der Firma STK hat zwei 2 Gbit Fibre-Channel-Anschlüsse ins SAN, über die eine aggregierte Leistung von 800 MB/s erreicht wird. Intern sind die Systeme mit 146-Gigabyte- Platten bestückt und ebenfalls über Fibre Channel verkabelt. Die Gesamtkapazität beträgt 14 Terabyte. Der Plattenplatz der Systeme wird von den AFS-Fileservern und einem MySQL-Server genutzt. - StorageTek Flexline 380 Storageserver Die Storageserver Flx380 der Firma STK haben acht 4 Gbit Fibre-Channel-Anschlüsse ins SAN, über die eine aggregierte Leistung von 1600 MB/s erreicht wird. Intern sind die Systeme sowohl mit 146- Gigabyte-Platten als auch 300-Gigabyte-Platten bestückt und ebenfalls über Fibre Channel verkabelt. Die Gesamtkapazität beträgt 115 Terabyte. Der Plattenplatz der Systeme wird ausschließlich von den TSM-Servern genutzt. Die 146-Gigabyte-Platten werden als Speicher für die TSM-Datenbanken verwendet, die 300-Gigabyte-Platten für die Plattenpools der Server. - IBM FAStT900 FC und SATA Zwei dieser Storageserver mit einer FC-Kapazität von 32 Terabyte sind an das LABS-SAN angebunden. Die Systeme werden für die TSM-Datenbanken des LABS und TSM-Plattencache für die am stärksten belasteten LABS-TSM-Server verwendet, für die die SATA-Systeme nicht genug Leistung bieten. Homogene NAS-Umgebung Die NAS-Systeme am LRZ haben sich als Speicherplattform aufgrund ihrer Stabilität, Ausfallsicherheit und hohen Datensicherheit durch die Spiegelung auf ein Replikationssystem seit mehreren Jahren bewährt und als strategische Plattform etabliert. Die rapide wachsenden Datenmengen erfordern auch eine gute Skalierbarkeit der eingesetzten Systeme. Abbildung 25 zeigt die Speicherentwicklung wichtiger Systeme im Jahr 2009.

62 56 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Abbildung 25 NAS-Speicherentwicklung von Jan 09 bis Jan 10 Aufgrund der guten Evaluierungsergebnisse der Datendeduplizierung A-SIS der Firma Netapp wurde diese Funktionalität ab Oktober 2009 für den VMware-Datenspeicherbereich produktiv eingesetzt. Bei der Datendeduplizierung wird der Datenbestand nach gleichen Blöcken durchsucht. Sind Doubletten vorhanden, wird ein solcher Block nur einmal gespeichert und die doppelten Datenblöcke freigegeben. Der in der Abbildung 25 ersichtliche Einbruch in der Speicherentwicklung im Oktober 2009 ist durch die Aktivierung der Deduplizierung im VMware-Umfeld zu erklären. Die Deduplizierung bringt in diesem Bereich eine Einsparung von ca. 10 TByte. Gerade im VMware-Umfeld kann Datendeduplizierung sehr vielversprechend eingesetzt werden, da viele Blöcke der einzelnen VMs gleich sind und somit nur einmal auf Platte abgelegt werden müssen. Abbildung 26 zeigt die Konfiguration der Speicherinfrastruktur der Primärspeichersysteme (Produktivsysteme) inklusive der Replikations- und Backupsysteme. Zwischen Primär- und Replikationsspeichersystemen findet mit SnapMirror eine asynchrone Spiegelung der Daten statt, im VMware-Umfeld, wie unten beschrieben, sogar eine synchrone Spiegelung. Zur weiteren Erhöhung der Datensicherheit werden die Daten von den Replikationssystemen zusätzlich über NDMP (Network Data Management Protocol) auf Magnetbänder gesichert. Die Primär- und Replikationssysteme befinden sich in getrennten Brandabschnitten des Rechnergebäudes. Abbildung 26 Primärsysteme, Replikation und Backup

63 Jahresbericht 2009 des Leibniz-Rechenzentrums 57 Hochverfügbarer Speicher für virtuelle Server Um den zukünftigen Speicherbedarf weiter zu decken, wurde Anfang 2009 mit der konkreten Planung für die Beschaffung des benötigten Speicherplatzes für die neue VMware-Infrastruktur und für ein Hochleistungs-NAS-System für den HPC-Bereich begonnen. Im Frühjahr 2009 wurde ein Großgeräteantrag geschrieben und in vollem Umfang genehmigt. Im Sommer 2009 wurde eine europaweite Ausschreibung zur Beschaffung des Speichers durchgeführt. Bereits Ende 2007 wurde damit begonnen, am LRZ VMware als plattformübergreifende Lösung zur Server-Virtualisierung einzusetzen. Um die notwendige hohe Verfügbarkeit bei der Speicherversorgung der neuen VMware-Infrastruktur zu erreichen, wurde ein System beschafft, das seine Daten synchron spiegelt und zusätzlich repliziert. Als nutzbarer Speicherplatz steht VMware zukünftig ca. 55 TByte zur Verfügung. Für die Replikation der Daten wurde das vorhandene Replikationssystem, das 2007 beschafft wurde, entsprechend erweitert. Abbildung 27 zeigt das beschaffte System, das in räumlich getrennten Brandabschnitten aufgebaut und installiert wird. Ab März 2010 soll dieses System produktiv eingesetzt werden. Abbildung 27 Hochverfügbares NAS-System für VMware inkl. Replikation und Backup Hochleistungs-NAS-System für HPC-Anwendungen: Das Linux-Compute-Cluster des LRZ mit derzeit mehr als 1000 Knoten bietet eine Grundversorgung mit HPC-Diensten für Wissenschaftler sowohl für die Münchner Universitäten als auch für andere bayerische Hochschulen. Derzeit sind etwa 250 Projekte mit insgesamt über 2100 Benutzern aktiv. Zusätzlich zu den LRZ-eigenen Rechnern integriert das Linux-Compute-Cluster weiterhin externe Projekte wie D-Grid, das LHC-Tier-2-Zentrum oder die Archivprojekte der Bayerischen Staatsbibliothek, deren Rechner in die Gesamtinfrastruktur eingebunden sind. Da in der Vergangenheit das für das Linux-Compute-Cluster verwendete parallele Dateisystem Lustre häufiger zu Ausfällen geführt hat, wurde entschieden, dieses System zu ersetzen. In der erwähnten Ausschreibung wurde ein skalierbares und für hohen Durchsatz optimiertes NAS-Speichersystem für die Speicherung von großen Datensätzen beschafft, das sich hervorragend in die am LRZ bereits vorhandene NAS-Speicherinfrastruktur integrieren lässt. Die angestrebte Konfiguration besteht aus sechs FAS3170 (2 Nodes je Chassis) der Firma Netapp und verfügt über eine nutzbare Kapazität von knapp über 150 TB. Durch die Konsolidierung wird sich zukünftig auch die Vertretersituation bei Urlaub und Krankheit entspannen.

64 58 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Speicher für die Wissenschaft Das LRZ bemüht sich seit geraumer Zeit um die Bereitstellung von Speicherkapazitäten für alle Studierenden und Mitarbeiter der Hochschulen. Die derzeitige Infrastruktur für die Speicherung von Dateien und Dokumenten an den Hochschulen ist dezentralisiert und die Qualität der angebotenen Dienstleistungen schwankt in Abhängigkeit von der zuständigen Teileinheit, verfügbaren Budgets und den für den Betrieb verantwortlichen Mitarbeitern. Das LRZ stellt in diesem Bereich seit Frühjahr 2008 eine einfach zu bedienende, sichere und zentral administrierte Alternative bereit. Durch eine enge Kopplung mit Verzeichnisdiensten verfügen alle Mitarbeiter und Studierenden sowohl über persönlichen Speicherplatz (aktuell 10 GByte) als auch über den Zugang zu Projektablagen. Gemeinsamer Projektspeicherplatz ermöglicht eine neue Art der Kooperation zwischen verschiedenen Einheiten, die bisher wegen der dezentralen Strukturen nicht möglich war. Weiteres Ziel ist die Versorgung anderer hochschulweiter Dienste mit sicherem, hochverfügbarem Speicherplatz. Hier wurden weitere Pilotprojekte mit der LMU durchgeführt. Die innerhalb des Projektes IntegraTUM (Projektende September 2009) evaluierten und ausgearbeiteten technischen Grundlagen und Randbedingungen für hochschulweite Bereitstellung von Speicher wurde erfolgreich umgesetzt und seit Mitte 2008 in den Produktivbetrieb überführt. Der zentrale Speicher wird gut angenommen, was die stetig steigende Anzahl der eindeutigen Benutzer-Kennungen (ohne Funktionsund lokale Benutzerkennungen) mit simultanen Zugriffen zeigt (siehe Abbildung 28). Die Zugriffe haben sich seit Beginn des Wintersemesters fast verdoppelt. Abbildung 28 Durchschnittliche Anzahl von simultan zugreifenden Kennungen von Feb 09 bis Feb 10 Für das im Dezember 2007 beschaffte Speichersystem, bestehend aus einem Primärspeichersystem (2 x FAS6070) und einem Replikationssystem (FAS6070) wurden Ende 2009 Erweiterungen beschafft. Die Bruttokapazitäten des Primärsystems werden Anfang 2010 von 68 TByte auf 117 TByte und des Replikationssystems von 68 TByte auf 305 TByte (dient auch als Replikationssystem für die VMware Speicherinfrastruktur) erhöht. Die Speicherinfrastruktur des Speichers für die Wissenschaft ist in Abbildung 29 dargestellt. Weiterhin wurden für die Speichersysteme 4 TByte innovativer Flashspeicher beschafft, der als intelligenter Read-Cache eingesetzt wird. Durch den Einsatz dieser Technologie kann festplattenbasierter Speicher für Random-Read-intensive Workloads wie File-Services optimiert und effizienter genutzt werden, da durch den Cache die Anzahl der Platten-IOs reduziert wird. Erste Tests zeigen vielversprechende Ergebnisse. Da den Nutzern nicht unbegrenzt Speicherplatz zur Verfügung gestellt werden kann, wurden die Speicherbereiche der Nutzer und Projekte mit Grenzen, sogenannten Quota, versehen. Auch die maximale Anzahl an gespeicherten Dateien fällt unter Quota. Um den Nutzern der NAS Dienste ein Instrument an die Hand zu geben, das ihnen erlaubt, die aktuelle Belegung der Quota zu beobachten und eventuell auch zu modifizieren, wurde ein Webinterface entwickelt und ab Frühjahr 2009 zur Verfügung gestellt. Dieses Interface unterscheidet drei Nutzergruppen (Standardnutzer, Teil & Fakultätsadministrator) mit unterschiedlichen Berechtigungen.

65 Jahresbericht 2009 des Leibniz-Rechenzentrums 59 Abbildung 29 Infrastruktur des Speichers für die Wissenschaft AFS Allgemein Die Komponenten der AFS- und Kerberos-Umgebung konnten im Vergleich zum Vorjahr fast unverändert bleiben. Der Kern des Produktivsystems besteht aus fünf AFS-Fileservern mit 7,5 TB nutzbarem Speicherplatz und AFS-Datenbank-Server, die unter anderem die Authentifizierung regeln. Auf diesen Servern läuft auch ein Heimdal-basierter Kerberos-Dienst, dessen Datenbankinhalte lediglich mit dem der AFS-Kerberos-Datenbank synchronisiert sind. Daneben dienen noch mehrere andere Rechner und Systeme weiteren wichtigen Funktionen. Backup-Systeme erledigen mit Hilfe eines eigenen dedizierten TSM- Servers die umfassende AFS-Daten- und Systemsicherung. Management-Server sorgen auf der Basis von MySQL-, Nagios- oder Apache-Diensten für die Überwachung der Kerndienste und leiten die Steuerung von automatisierten Aufgaben. Testumgebungen helfen bei Weiterentwicklungen von und Problemlösungen bei allen im Einsatz befindlichen Produkten und Verfahren. Der Funktionsumfang der angebotenen Dienste wurde dieses Jahr erweitert. Im Bereich Autorisierung erlaubt AFS nun geschachtelte Gruppen und erleichtert so die Abbildung hierarchischer Strukturen. Im Backupbereich sorgt eine neu entwickelte Sparoption für mehr Effizienz. Sicherung - nun ganz mit Linux Die gesamten im AFS in AFS-Volumes untergebrachten Daten werden regelmäßig auf zwei völlig verschiedene Arten gesichert. Zum einen wird jede Nacht jedes geänderte Volume als eigenständige schreibgeschützte Kopie auf einen anderen Server kopiert. Diese ReadOnly-Kopie ist online verfügbar und lässt sich bei Verlust des Originalvolumes anstelle desselben aktivieren. Diese Art der Sicherung dient der schnellen Restauration größerer Mengen an verlorenen Daten im Katastrophenfall und ist ein vergleichsweise neues Feature. Zum anderen werden von allen geänderten Volumes mehrmals täglich Backups in Form von Snapshots angelegt und über ein spezielles Backupsystem gesichert. Aus diesen Sicherungen kann jedes Volume auf jedes zurückliegende Datum innerhalb eines gewissen Zeitraums (maximal bis Februar 2007) restauriert werden. Der jeweils letzte Clone ist wieder online zugreifbar und stellt den letz-

66 60 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme ten verfügbaren Sicherungsstand dar. Diese zuletzt genannte Art von Sicherung wird nun völlig unter Linux realisiert, nachdem immer mehr derjenigen AIX-Rechner aus Altersgründen weggefallen waren, auf denen dieser BUTC genannte Sicherungsdienst bislang als Zusammenspiel von TSM- und AFS- Software gelaufen war. Angesiedelt sind die neuen BUTC-Dämonen nun auf den AFS-Fileservern selbst, wo sie ihre Arbeit um vieles schneller und zugleich ressourcenschonender verrichten können. Management - weiter ausgebaut Änderungen gab es naturgemäß bei der Software. Wo immer es sinnvoll und möglich war, wurde die neuestmögliche Dienste- und Anwendungssoftware eingesetzt. Die zuletzt installierte OpenAFS-Version etwa bot serverseitig Fehlerkorrekturen, die das AFS-Dateisystem am LRZ ab September wieder zu einem störungs- und problemfreien Dienst werden ließen. Kontinuierliche Verbesserungen und Erweiterungen gab es ferner wieder im Bereich der eigenen Managementlösung SIB (kurz für Service Information Base), die nicht nur für den Kerndienst AFS eingesetzt wird, sondern auch für den Backup-Service, der für die gesamte AFS- und Kerberos-Umgebung zuständig ist. Mit Hilfe von SIB werden nicht nur für die Administration wichtige und interessante Übersichten und Problembereiche anschaulich dargestellt, sondern können auch regelmäßige Aktionen angestoßen werden. So wird die Verwaltung weiter beschleunigt und erleichtert oder die Durchführung komplexerer Kontrollen und Aufgabenstellungen erst möglich. Diese Infrastruktur wurde neben einer Datenbasis für organisatorische Zwecke auch für den Kerberos- Dienst eingesetzt, um unterschiedlichste Analysedaten aus diesem Umfeld für Kontrollfunktionen der Nutzungsprofile auswerten zu können. Überwachung - stark erweitert Etliche Verbesserungen gab es auch im Bereich der Überwachung der Dienste und der sie realisierenden Server und ihrer Komponenten. So erfolgte eine Ausweitung der Kontrolle interner und externer Plattensysteme und der Verwendung automatischer Restartmöglichkeiten von dafür geeigneten Diensten. Durch dem Einsatz schaltbarer Steckdosenleisten und redundanter Spannungsversorgung für jetzt alle Geräte der gesamten Diensteumgebung konnte die Nagios-basierte Überwachung so um aktive Elemente erweitert werden, dass vorhersehbare Störungen selbsttätig behoben und Ausfallzeiten drastisch reduziert werden konnten. Statistik - zweistelliges Wachstum Verglichen mit dem Vorjahr wuchs der von AFS-Daten belegte Speicherplatz. Im Gesamtmittel stieg er um 21 % auf 4.1 TB brutto (Summe aller Volumetypen) bzw. 2.3 TB netto (nur RW-Volumes), nur Benutzer-Daten betrachtet um 25 % auf 2.6 TB brutto bzw. 1.7 TB netto. Durch anhaltende Bereinigungsaktionen und Löschungen unbenutzter Volumes konnte die Anzahl der Benutzer-Volumes um 58 % auf rund RW-Volumes verringert werden. Die Menge der AFS- und zugleich Kerberos 5-Benutzerkennungen stieg dagegen um 14 % auf knapp Einträge.

67 Jahresbericht 2009 des Leibniz-Rechenzentrums Entwicklungen bei den Rechensystemen Höchstleistungsrechner in Bayern (HLRB II: SGI Altix 4700) Kennzahlen des Systems Abbildung 30 SGI Altix 4700 im Rechnerraum des LRZ Anzahl SMP Knoten 19 CPUs pro Knoten 512 Anzahl Prozessoren 9728 (=19*512) Peakperformance pro CPU 6.4 GFlop/s * Peakperformance pro Knoten 3.3 TFlop/s ** Peakperformance des Gesamtsystems 62.3 TFlop/s ** LINPACK 56.5 TFlop/s ** Hauptspeicher pro Knoten 2056 GByte Hauptspeicher des Gesamtsystems GByte Plattenspeicher 660 TByte ** * 1 GFlop/s = 1 Giga Floatingpoint operations per second = 1,000,000,000 Gleitkomma- Rechenoperationen pro Sekunde 1 TFlop/s = 1 Tera Floatingpoint operations per second = 1,000,000,000,000 Gleitkomma- Rechenoperationen pro Sekunde Tabelle 14: Kennzahlen des Systems Betriebliche Aspekte Im Berichtsjahr 2009 konnte die Betriebsstabilität und die Verfügbarkeit durch das Einspielen kleinerer Software Updates weiter erhöht werden. Durch Upgrade des Betriebssystems auf SLES10 ServicePack 2 im Frühjahr 2009 wurde sichergestellt, dass sicherheitsrelevante Updates weiterhin zur Verfügung stehen.

68 62 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Da der Support, d.h. die Bereitstellung notwendiger Sicherheitsupdates, für diese Version im Frühjahr 2010 eingestellt wird, der Upgrade auf das nächste Major Release SLES 11 wegen der zu erwartenden umfangreichen Test- und Umstellungsarbeiten nicht vor Ende des Jahres durchgeführt werden kann, wird im Frühjahr 2010 als Zwischenschritt die Version SLS10 SP3 des Betriebssystems eingespielt. Etwa zum gleichen Zeitpunkt soll das Batchverarbeitungssystem PBSPro auf die Version 10.2 aufgerüstet werden. Abbildung 31 Übersicht über die Verfügbarkeit des HLRB II (SGI Altix 4700) Die Beeinträchtigung durch Nicht-Verfügbarkeit für LRZ-Benutzer wurde durch Benchmarkläufe durch SGI für den SPECjbb2005 Benchmark auf 512 Cores (Rechnerleistung für geschäftsnahe Internet Anwendungen), sowie den SPECint_rate_base_2006 und den SPECfp_rate_base2006 Benchmark auf jeweils 1024 Cores verursacht. Die hierzu notwendige Rechenzeit stand SGI im Rahmen eines Kooperationsabkommens zur Verfügung. Bei den Benchmarks konnten in allen 3 Bereichen neue Weltrekorde erreicht und die bisherigen Ergebnisse teilweise sogar um das Fünffache verbessert werden. Abgesehen von Ausnahmefällen wie dem o.g. Benchmark und dem Ausfall des cxfs Dateisystems im letzten Jahr blieben sowohl die Ursachen der Ausfälle als auch deren Verteilung gegenüber den Werten von 2008 weitgehend konstant. Signifikante Verbesserungen gab es im Bereich der Numalink- Fehlereingrenzung; hier konnte die Nichtverfügbarkeit von 0,47% auf 0,17% reduziert werden Nutzungsübersicht Die Schwerpunkte der Arbeiten in diesem Jahr lagen auf der Stabilisierung des Betriebs, der Konsolidierung und Abrundung des Softwareangebotes sowie der Optimierung von Benutzerprogrammen. Das Angebot an Chemiesoftware und mathematischen Bibliotheken wurde erweitert. Neue Compilerversionen wurden getestet und installiert. Die abgegebene Rechenzeit (ausgedrückt in Core*Stunden) des HLRB II sind in Abbildung 33 dargestellt. Im Jahr 2009 wurden am HLRB II insgesamt 66 Mio. Core*Stunden abgegeben. Berücksichtigt man die Service- und die Interaktivknoten nicht, so sind das etwa 81% der maximal abgebbaren Rechenzeit. Der Anstieg der abgegebenen Rechenzeit ist auf mehrere Faktoren zurückzuführen: Weniger und lokalisiertere Systemabstürze Weniger und kürzere Wartungen Verbesserungen beim Scheduling Die Favorisierung von größeren Jobs

69 unavailability [%] Jahresbericht 2009 des Leibniz-Rechenzentrums 63 2,00% 1,80% 1,60% 1,40% 1,20% 1,00% 0,80% 0,60% 0,40% Erläuterungen: HLRB II unavailability statistics 2009 DIMM: Memorybausteine CPU: Central Processing Unit Blad: Platine POD: Power On Discovery (Fehler beim Selbsttest nach Power On) IRU: Individual Rack Unit(Enclosure für bis zu 16 Blades) L1: Kontrolleinheit für eine IRU PS: Power Supply, Netzteil NUMA Link Fault Isol: Fehlerfortpflanzung auf andere Partitionen MCA/PTC Timeout: Fehler bei der Seitenverwaltung (Page Table) RRB Timeout: Timeout beim Lesen von Numalink Puffern xpc: Cross Partition Communication Software CXFS or RAID: Plattenfehler 0,20% 0,00% Abbildung 32 Ursachen von Ausfällen Abbildung 33 Abgegebene Rechenzeit des HLRB II (in Core-Stunden) Eine weitere Steigerung der abgegebenen Rechenleistung ist jedoch in den kommenden beiden Jahren nicht zu erwarten.

70 64 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Die mittlere Rechenleistung des Systems konnte von den Anwendern im Laufe des Jahres weiter gesteigert werden. Die mittlere Rechenleistung des Systems liegt etwas oberhalb von 5 TFlop/s. Sie beträgt damit rund das 25-fache der Leistung des Vorgängersystems HLRB I, Hitachi SR8000. Insgesamt wird jedoch angestrebt, eine mittlere Leistung von mehr als 10% der Spitzenrechenleistung zu erreichen, d.h. mehr als 6 Teraflops/s. Abbildung 34 Mittlere Rechenleistung des HLRB II (in GFlop/s). In den ersten beiden Betriebsjahren ist auch die Rechenleistung des Migrationssystems mit aufgeführt. Die Verteilung der abgegebenen Rechenzeit auf einzelne Jobklassen ist in Abbildung 35 dargestellt. Der Schwerpunkt der Nutzung liegt zwischen 128 und 512 Prozessorkernen. Im Jahre 2009 hat die Anzahl von Jobs, die mehr als 1024 Cores verwenden, zugenommen., Es zeigt sich, dass mehr Anstrengungen notwendig sein werden, um die Applikationen für die Nutzung zukünftiger Rechnergenerationen mit mehr als einhunderttausend Cores vorzubereiten und zu optimieren. Abbildung 35 Verteilung der Rechenzeit nach Jobgröße (Legende gibt die Anzahl von Cores an)

71 Jahresbericht 2009 des Leibniz-Rechenzentrums Nutzungsstatistik Die Verteilung der Rechenzeit auf die einzelnen Fachgebiete im Verlauf der Zeit ist in Tabelle 15 aufgeführt. Bemerkenswert für 2009 ist die wachsende Bedeutung der Biowissenschaften und der Chemie. Research Area Computational Fluid Dynamics 37.5% 24.8% 19.2% 24.9% Astrophysics/Cosmology 4.0% 20.1% 22.7% 13.3% Physics - High Energy Physics 15.5% 17.3% 18.2% 14.9% Physics - Solid State 14.0% 13.4% 13.2% 10.4% Chemistry 12.7% 7.6% 5.4% 10.0% Biophysics/Biology/Bioinformatics 0.0% 1.9% 6.3% 6.6% Geophysics 6.1% 6.7% 2.8% 2.6% Physics - others 4.8% 3.7% 2.4% 2.2% Engineering - Electrical Engineering 0.0% 0.0% 3.1% 2.4% Meteorology/Climatology/Oceanology 0.1% 0.2% 2.5% 2.7% Informatics/Computer Sciences 0.8% 0.3% 1.3% 3.1% Support/Benchmarking 0.7% 2.4% 0.9% 1.6% Engineering - others 0.0% 0.9% 1.1% 1.8% Grid Computing 0.0% 0.0% 0.1% 2.3% Environmental Sciences 4.0% 0.6% 0.2% 1.0% Tabelle 15: Verteilung der Rechenzeit nach Fächern am HLRB II im Jahr 2009 Der Höchstleistungsrechner wurde im Jahr 2009 von Wissenschaftlern aus den in Tabelle 16 angegebenen Ländern bzw. Bundesländern genutzt. Land Anzahl Jobs % Jobs Core-h % Core-h Bayern Baden-Württemberg Brandenburg Nordrhein-Westfalen Berlin Thüringen Hessen Niedersachsen Deutschland Spanien Italien United Kingdom Finnland Sachsen-Anhalt Sachsen Mecklenburg-Vorpommern Niederlande Summe Tabelle 16: Verteilung der Rechenzeit nach Ländern am HLRB II im Jahr 2009 In dieser Statistik sind neben deutschen Bundesländern auch Staaten aufgeführt, die in DEISA (Distributed European Infrastructure for Supercomputing Applications) aktiv sind. Für die Projekte aus Deutschland, die in DEISA und oder von virtuellen Organisationen in D-Grid durchgeführt wurden, kann kein

72 66 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme eindeutiges Bundesland zugeordnet werden; sie wurden deshalb in einem eigenen Punkt Deutschland zusammengefasst. Tabelle 17 gibt die institutionelle Zugehörigkeit der Projekte wieder. Land Anzahl Jobs % Jobs Core-h % Core-h Universitäten Helmholtz-Gemeinschaft Max-Planck-Gesellschaft DEISA Leibniz-Rechenzentrum Summe Tabelle 17: Verteilung der Rechenzeit nach institutioneller Zugehörigkeit am HLRB II im Jahr 2009 Die Großprojekte am HLRB II sind in Tabelle 18 aufgeführt. Project Institution Description Anteil h006z DESY Zeuthen Simulation of N_f equal 2+1 lattice QCD at realistic quark masses h1142 Uni Stuttgart Simulation of the unsteady flow around the Stratospheric Observatory For Infrared Astronomy SOFIA h1021 Uni Jena Dynamics of binary black hole systems 3.3% h014z Uni Würzburg Quantum monte-carlo and exact diagonalization studies of correlated electron systems pr28ca Uni Karlsruhe Direct numerical simulation of gas transfer through the airwater interface in a turbulent flow h0983 TU München Large Scale CFD for Complex Flows 2.9% h0351 TU München Density Functional Investigations of Complex Chemical Systems h1143 Uni Stuttgart Numerical Simulation of a Scram Jet Intake at high Mach number pr26we DESY Zeuthen Exploring Lattice QCD with Exact Chiral Symmetry 2.4% h0672 Uni Erlangen Simulation optischer Eigenschaften von Dünnschichtsolarzellen h0485 Uni Erlangen Hyper-Scale walberla 2.3% h0721 Uni München Structure, Properties and Reactivity of Mineral Surfaces and Interfaces: a density-functional theory (DFT) investigation h1112 DLR Oberpfaffenhofen Modeling the impact of transport (aviation, ships and land traffic) on the climate h009z AI Potsdam Local Supercluster Simulation 1.9% pr32lo Uni Heidelberg The core mass function from magnetised gravo-turbulent fragmentation in star-forming molecular clouds Tabelle 18: Die 15 größten Projekte und ihr Anteil an der Gesamtrechenzeit am HLRB II im Jahr % 3.4% 3.3% 2.9% 2.6% 2.5% 2.4% 2.2% 2.0% 1.8% Vorbereitung für den nächsten Höchstleistungsrechner SuperMUC Im April wurde ein erstes Konzept des LRZ für den nächsten Höchstleistungsrechner mit der Bezeichnung SuperMUC erstellt, das im Mai im Rahmen einer Informationsveranstaltung potentiellen Lieferan-

73 Jahresbericht 2009 des Leibniz-Rechenzentrums 67 ten präsentiert wurde. Basierend hierauf entwickelten die Hersteller ihre ersten Vorschläge, die bei zahlreichen Sondierungsgespräche und Besuchen diskutiert wurden. Parallel hierzu wurde eine erste Version der Benchmarksuite entwickelt und auf verschiedenen Architekturen getestet. Ebenfalls wurden die Spezifikationen und Anforderungen an das neue System in einer Description of Goods and Services zusammengefasst. Diese werden als Diskussionsgrundlage im Verhandlungsverfahren dienen Linux-Cluster Weiterentwicklung des Systems Nach dem starken Ausbau des Clusters im Jahre 2008 sind für das Berichtsjahr im Wesentlichen Anstrengungen zur Konsolidierung der Betriebsstabilität zu verzeichnen. Insbesondere beim parallelen Dateisystem Lustre konnten hierbei Verbesserungen erzielt werden, trotzdem kam es zu einigen größeren Störungen. Da das Ein/Ausgabe-Nutzungsprofil für Lustre unvorteilhaft ist, wurde eine Ablösung dieses Dateisystems durch NAS-basierten Speicher mit einer erheblich verbesserten Metadatenleistung beantragt und beschafft. Ein weiterer Problembereich ist die Konfiguration des Sun Grid Engine Warteschlangensystems, wo die Integration weit gefächerter Anforderungen aus dem Bereich des Cluster-Housing eine Herausforderung darstellt. Das Linux-Cluster einschließlich aller gehosteten Knoten umfasst mittlerweile etwas mehr als 5000 Prozessor-Kerne mit einer aggregierten Rechenleistung von 45 TFlop/s sowie mehr als 750 TByte an Hintergrundspeicher. Zum Vergleich: der Höchstleistungsrechner HLRB II hat 9728 cores mit aggregiert 62 TFlop/s und 660 TByte Hintergrundspeicher; der Abstand zum Linux-Cluster wird sich bis zur Beschaffung eines Nachfolgesystem noch weiter verringern Linux-Cluster AG Aufgabe des Arbeitskreises Linux-Cluster ist es, gruppen- und abteilungsübergreifend den Betrieb des Linux-Clusters und die durchzuführenden Maßnahmen zu koordinieren. Schwerpunkt war neben den Wartungsaufgaben die Erweiterung des Clusters. Etliche Administrations- und Konfigurationsmethoden, die im Rahmen der Arbeit der Linux AG entwickelt und implementiert wurden, wurden auch auf dem HLRB II zum Einsatz gebracht Nutzung des Linux-Clusters Die Anzahl der aktiven Benutzer am Linux-Cluster ist in Abbildung 36 dargestellt. Innerhalb des Zeitraumes von drei Jahren ist nahezu eine Verdoppelung festzustellen. Dies spricht für die breite Akzeptanz des Clusters und der dort installierten Software. Abbildung 36 Anzahl der aktiven Benutzer im Linux-Cluster

74 68 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Durch die verschiedenen Ausbaumaßnahmen und Erweiterungen insbesondere im Housing-Bereich konnte die abgegebene Rechenleistung kontinuierlich gesteigert werden. Dabei entfallen etwa 40% der Rechenleistung auf parallele Jobs. Dieser Anteil gliedert sich in den Anteil auf, der durch die Altix-Systeme eingebracht wir und den Teil, der durch die kleineren Knoten im Cluster erbracht wird. Serielle Jobs werden auf den Altix-Systemen praktisch nicht gerechnet. Nach der Installation des zweiten Altix-Systems im Jahre 2007 erfolgte hier keine weitere Leistungssteigerung mehr. Schlüsselt man die abgegebene Leistung nach dem Eigentümer und dem Versorgungsbereich auf (siehe Abbildung 37), so erkennt man, dass die Leistungssteigerung weniger durch neue Knoten im allgemeinen Versorgungsbereich des LRZ kommt, sondern im Wesentlichen durch die Hinzunahme von Abbildung 37 Abgegebene Rechenleistung im Linux-Cluster in Core-Stunden dedizierten Housingknoten aus den folgenden Bereichen verursacht ist: astro: Housing Astro-Grid, Datenauswertung Planck-Satellit etc., TU München bauinf: Housing für Lehrstuhl für Bauinformatik, TU München bsb: Bayerische Staatsbibliothek, Digitalisierung für das BABS-Google-Projekt exzellenz: Exzellenz-Cluster der Physik, Universität München geod: Geodäsie, TU München lcg: Large Hadron Collider Grid, Physik Universität München u.a. tu-math: Zentrum für Mathematik der TU München. Abbildung 38 Abgegebene Rechenzeit des Linux-Clusters (in Core-Stunden)

75 Jahresbericht 2009 des Leibniz-Rechenzentrums 69 Die Aufschlüsselung nach der Anzahl Jobs zeigt die großen Durchsatzanforderungen im Cluster für serielle Jobs, vor allem im Bereich des LCG-Tier2-Zentrums. Parallele Programme findet man hauptsächlich auf den Rechnern im allgemeinen Versorgungsbereich des LRZ und im Housing-Bereich auf den Rechnern der TU Mathematik. Die kumulierte Verteilung der Jobs zeigt, dass parallele Jobs meist nur bis zu einer Jobgröße von 64 cores anzutreffen sind. Die kumulierte Verteilung der Wartezeiten für parallele Jobs zeigt einen deutlichen Anstieg über die Jahre. Wartezeiten von mehreren Tagen für größere Jobs sind nun eher die Regel. Dies hat dazu geführt, dass Benutzer mit Jobs ab 64 Cores verstärkt auf den Höchstleistungsrechner ausweichen mussten. Im Bereich der seriellen Jobs ist nur ein leichter Anstieg der Wartezeiten zu vermelden. Abbildung 39 Anzahl serieller Jobs Abbildung 40 Anzahl paralleler Jobs

76 70 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Abbildung 41 Kumulierte Verteilung der Jobgrößen Abbildung 42 Kumulierte Verteilung der Wartezeiten für parallele Jobs. Die Kurven geben an, wie viel Prozent der Jobs jeweils unterhalb der abgegebenen Wartezeit liegen. Um die Wartezeiten wieder auf ein erträgliches Maß zu bringen, ist deshalb für 2010 die Ersetzung der Itanium Komponenten und die Beschaffung von weiteren Knoten im Cluster geplant; diese sollen vorrangig für parallele Jobs verwendet werden.

77 Jahresbericht 2009 des Leibniz-Rechenzentrums Nutzungsstatistiken für das Linux-Cluster Gruppe Institution/Fachbereich Anzahl % Jobs Core-h % Core-Std LCG LCG (Large Hadron Collider Computing Grid) LMU Physik LMU Biologie TUM Chemie TUM Maschinenwesen LMU Chemie und Pharmazie BAY Universität Regensburg TUM Elektrotechnik und Informationstechnik BAY Universität Bayreuth LRZ LRZ TUM Mathematik TUM Bauingenieur- und Vermessungswesen TUM Wissenschaftszentrum Weihenstephan für Sonstige Hochschulnahe Einrichtungen - Sektion BAY Universität Erlangen Körper Bay. Staatsminist./Bay.Staatsbibliothek LMU Geowissenschaften TUM Informatik BAY Universität Würzburg Sonstige Sonstige LMU Medizinische Fakultät LMU Mathematik, Informatik und Statistik TUM Fachhochschule Weihenstephan TUM Medizin TUM Zentralbereich TUM Feinwerk- und Mikrotechnik BAY Katholische Universität Eichstätt TUM Architektur BAY Universität Augsburg LMU Zentrale Einrichtungen und Verwaltung Sonstige Sonstige Hochschulen LMU LMU München TUM TU München LCG LCG (Large Hadron Collider Computing Grid) BAY Bayerische Universitäten LRZ Leibniz Rechenzentrum Sonstige Sonstige Körper Körperschaften Summe Summe Tabelle 19: Linux-Cluster Nutzung nach institutioneller Zugehörigkeit und Fachgebiet Speichersysteme am Linux-Cluster Auf dem Cluster kamen im Berichtszeitraum zwei Permanentspeichersysteme zum Einsatz: Für die HOME-Bereiche hochwertiger NAS-Speicher mit Ausfallsicherheit, garantierter Datenintegrität sowie Gruppenquota Für pseudotemporäre oder projektbezogene Datenhaltung zwei Lustre-Dateisysteme mit Größen von ca. 150 bzw. 50 TByte, mit hoher verfügbarer Bandbreite, aber ohne Datenintegritätsgarantien und (für den pseudotemporären Bereich) mit einer Mischung aus Gleit- und Hochwasserlöschung.

78 72 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Mit dem hochwertigen NAS-Speicher wurden sehr gute Erfahrungen bezüglich Stabilität, flexibler Administrierbarkeit sowie Daten- und Metadatentransferleistung gemacht; der einzige beobachtete Nachteil liegt im Quotasystem, das Quota nur auf Gruppenebene vergeben kann und damit dem einzelnen Nutzer Kontrolle über etwaige Quota-Überschreitungen partiell entzieht. Dieser Missstand sollte im Lauf des Jahres 2010 durch aktualisierte Betriebssoftware auf den NAS-Filern behoben werden, sodass dann ggf. wieder Quota auf Benutzerebene vergeben werden könnten. Trotz mehrfachem Einspielen von Software-Updates gab es hingegen mit Lustre wiederholt Stabilitätsprobleme, von denen ein Teil auf Konfigurationsfehler zurückging, ein anderer jedoch auf Software- Fehler, die insbesondere durch Ausfälle der Netzwerkinfrastruktur ausgelöst wurden. Darüber hinaus war das beobachtete Nutzerprofil von großen Anzahlen relativ kleiner Dateien dominiert, was dem optimalen Nutzungsmuster von Lustre, nämlich breitbandigem I/O auf große Dateien, nicht entspricht. Aus diesen Gründen wurde im Berichtsjahr die Beschaffung eines stärker auf Metadatenleistung ausgerichteten Ablöse-Systems auf Basis von NAS-Speicher in die Wege geleitet, dessen Inbetriebnahme für Anfang 2010 avisiert ist Wartungsmaßnahmen Im Berichtszeitraum wurden zwei Wartungsmaßnahmen durchgeführt, die eine größere Unterbrechung des Benutzerbetriebes erforderten. Die im März 2009 durchgeführte Wartung fand in Verbindung mit Elektroarbeiten sowie der Installation eines neuen großen Netzwerk-Switches und eines durch die Physik der LMU gehosteten neuen Clustersegmentes statt und dauerte daher vier Tage. Softwareseitig wurde das Betriebssystem auf SLES10 SP2 angehoben, und das Lustre Dateisystem auf Version Eine weitere, eineinhalbtägige Wartung wurde im Oktober 2009 durchgeführt; hierbei wurden auf dem Cluster Kernel-Updates zur Behebung von Sicherheitslöchern installiert sowie Korrekturen der Verkabelung an den gehosteten LHC-dCache Knoten durchgeführt. Die Altix Systeme wurden einer Hardware- Wartung unterzogen Remote Visualisierungsserver Technik Computergestützte Visualisierungstechniken sind heute aus der Wissenschaft nicht mehr wegzudenken und mit zunehmender Leistungsfähigkeit der Rechner steigen auch Größe und Komplexität der Datensätze sowie die Ansprüche der Forscher, schnell und zuverlässig zu aussagekräftigen Ergebnissen zu kommen. Idealerweise möchten Wissenschaftler ihre Daten an ihrem eigenen Schreibtisch auswerten. Eine solche lokale Auswertung am eigenen PC ist aber schwierig bis unmöglich, wenn die Datensätze sehr groß sind (mehrere Gigabyte), teure Spezialsoftware benötigt wird oder nur parallele Verarbeitung es ermöglicht, flüssig zu arbeiten. Remote-Visualisierung bedeutet, dass der Anwender seinen PC über das Internet von überall her mit dem Visualisierungsserver am LRZ verbinden kann und somit auf einfache Weise Zugang zu einem Hochleistungsrechner hat, der speziell auf Visualisierungsanforderungen zugeschnitten ist. Der Rechner am Schreibtisch dient dann nur noch zur Anzeige der Bilder, die das Visualisierungssystem am LRZ erzeugt hat. Die rechenintensive Erzeugung der Diagramme, Bilder oder Filme geschieht auf den Hochleistungsrechnern am LRZ. Der Dienst Remote-Visualisierung wird von den Benutzern sehr gut angenommen, was an der auf hohem Niveau liegenden Auslastung der Hardware-Reservierungen abzulesen ist, so dass Anwender bereits temporär vom automatischen Reservierungssystem abgewiesen werden mussten. Inzwischen wurden dedizierte Remote-Visualisierungs-Server für HLRB II und Linux-Cluster in Produktionsbetrieb genommen. Insgesamt stehen den Anwendern nun 3 Server mit zusammen 80 Cores und insgesamt 12 Hochleistungsgraphikkarten zur Verfügung. Sämtliche Visualisierungs-Server sind auch per Grid-Zertifikat benutzbar. Wegen der hohen Nachfrage nach GPGPU-Programmierung (speziell NVIDIA CUDA) wurde hierfür ein dediziertes CUDA Testsystem angeschafft (1 Workstation mit Intel Nehalem EX, 1 Tesla C1060 Karte und 1 GeForce 9800 Grafikkarte).

79 Jahresbericht 2009 des Leibniz-Rechenzentrums 73 Abbildung 43 Prinzip der Remote Visualisierung (rechts) im Gegensatz zur lokalen Visualisierung (links) Computational Steering auf der Ars Electronica Das Leibniz-Rechenzentrum (LRZ) war am 6. September mit einem Vortrag und Live-Demonstrationen In-silico Experiments Live from LRZ im Rahmen der Konferenzreihe Pixelspaces des Ars Electronica Futurelab in Linz vertreten. Bei der Konferenzreihe werden im Rahmen eines Themensymposiums und einer Themenausstellung aktuelle Strömungen aufgegriffen und aus der Sicht eines Atelier-Labors diskutiert. Austragungsort für die Konferenzreihe war dieses Jahr das neue Ars Electronica Center, das zu Jahresbeginn 2009 eröffnet wurde. Besucher haben die Möglichkeit, virtuelle 3D-Welten im Deep Space zu erforschen, einem 3D-Kino mit einer 16m breiten und 9m hohen Leinwand. Für die Demonstration simulierte das LRZ ein reales Experiment live im Computer ( In-silico Experiment ). Dabei wurde die Simulation eines Protein-Moleküls mit mehr als Atomen auf 500 Prozessoren des Höchstleistungsrechners SGI Altix 4700 des LRZ gestartet. Jede Sekunde (nach ein paar hundert Simulationsschritten) wurden die neu berechneten Positionen sämtlicher Atome von München nach Linz übertragen und dort in Stereo 3D visualisiert. Die Simulation reagierte sofort auf Änderungen von Eingabeparameter und berechnete die neuen Atom-Bewegungen, was in Linz dann live zu sehen war. Abbildung 44 Auf der 16m breiten und 9m hohen Leinwand des Deep Space wurde die interaktive Molekulardynamik-Simulation eines Proteinmoleküls live in Stereo 3D gezeigt, mit einer Online- Verbindung zum Höchstleistungsrechner HLRB II (Foto: H. Satzger).

80 74 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme 2.3 Software und User Support im Bereich Hochleistungsrechnen Entwicklungsumgebung Intel Compiler und Tools: Die Compiler, Bibliotheken und Tools wurden im Rahmen der Softwarewartungsverträge mit der Firma Intel ständig aktualisiert; insbesondere ist hier das Erscheinen des Compiler-Releases 11.1 mit wesentlich erweiterter Fortran 2003 Unterstützung (objekt-orientierte Konzepte), einigen C++0x-Features sowie stabilisiertem OpenMP 3.0 Support zu erwähnen. PGI Compiler: Für die Nutzung von Hardware-Beschleunigern am LRZ handelt es sich hierbei um Tesla- Karten der Firma NVidia bietet der PGI Fortran Compiler in seinem neuesten Release direktivengesteuerte Unterstützung. Die Lizenzierung des Produktes wurde entsprechend erweitert. Eclipse: Mit Eclipse gibt es seit geraumer Zeit eine von IBM quelloffen freigegebene Entwicklungsumgebung, die ursprünglich in erster Linie von Java-Programmierern eingesetzt wurde, jedoch in den letzten Jahren erhebliche Fortschritte bei der Unterstützung von HPC-relevanten Programmiersprachen wie C++ und Fortran gemacht hat. Diese Unterstützung ist in der Form von Plugins (CDT bzw. Photran) integrierbar. Darüber hinaus ist für die Entwicklung paralleler Programme auch remote development prototypisch implementiert worden (PTP, parallel tools platform), sowie auch Grid-Unterstützung (g-eclipse) verfügbar. Es ist derzeit noch nicht möglich, diese Tools für den Produktionseinsatz zu empfehlen; jedoch sind die erzielten Fortschritte so deutlich, dass die bislang geltenden Einschränkungen in nicht allzu ferner Zeit entfallen dürften. Scalasca: Im Berichtsjahr konnte das Performanceanalysetool Scalasca (SCalable performance Analysis of LArge SCale parallel Applications) auf dem HLRB II installiert und in Betrieb genommen werden. Scalasca ist ein Open Source Projekt des Jülich Supercomputing Centre (JSC) mit der Zielsetzung OpenMP, MPI and hybride OpenMP/MPI Anwendungen zu analysieren. Kernstück ist eine benutzerfreundliche Präsentationsschicht. Scalasca wird eingesetzt, um Performancebottlenecks zu identifizieren und Möglichkeiten zur Codeoptimierung aufzuzeigen. Zahlreiche Features unterstützen dies: skalierbares Profiling und Tracing von Anwendungen auch für sehr große Programme, automatische Trace-Analyse, die Ineffizienzen in den Kommunikationsmustern und Synchronisationen aufdeckt, Möglichkeiten sich auf wesentliche Programmteile zu konzentrieren sowie die Integration von Hardware Performance Countern. In einem gemeinsamen Kurs von JSC und LRZ konnten sich Benutzer über das Produkt informieren und erste Erfahrungen damit sammeln Anwendungen Das Software-Portfolio wurde erneut erweitert und durch Versions-Aktualisierung auf dem jeweils neuesten Stand gehalten. Die wichtigsten Änderungen sind in den folgenden Unterabschnitten beschrieben. Quantenchemie: Neu beschafft wurden die Softwarepakete Schrodinger und Castep. Die neueste Version (09) der Standardsoftware Gaussian wurde lizenziert. Für die Version 5.5 des Paketes VASP wurde mit den Autoren eine spezielle Maintenance-Lizenz abgeschlossen. Computer-Algebra: Neben dem parallelen MATLAB-Add-on StarP sind hier Updates für MATLAB selbst, sowie auch für den MATLAB-Klon Octave und die Statistik-Software R zu nennen. Letztere gestattet durch Einbindung etwa von MPI nun auch massive Parallelisierung. Fluid-Dynamik: Neue Versionen von OpenFOAM wurden installiert; eine für Cluster-Nutzer verfügbare Lizenz des Visualisierungspaketes TecPlot wurde beschafft.

81 Jahresbericht 2009 des Leibniz-Rechenzentrums 75 Visualisierung: Hier sind die Programme Maestro (zum Einsatz im Molecular Modeling), Blender (ein 3D- Graphikpaket) sowie Visit (mit neuerdings unterstützter Parallelität) zu nennen Supportanfragen Die deutlich gesteigerte Anzahl von Nutzern und der große Job-Durchsatz am HLRB II und am Linux- Cluster haben zu einer weiteren Steigerung von Supportanfragen geführt, die nur mittels des Troubleticket-System gezielt abgearbeitet werden können (siehe Tabelle 20). Diese Möglichkeit der Kontaktaufnahme wurde von den Benutzern sehr gut angenommen und hat die Kontaktaufnahme via fast komplett ersetzt Tabelle 20: Anzahl Troubletickets im Bereich Hochleistungsrechnen 2.4 Öffentlichkeitsarbeit HLRB and KONWIHR Results and Review Workshop Der im zweijährigen Rhythmus stattfindende "HLRB and KONWIHR Results and Review Workshop" wurde am 8. und 9. Dezember 2009 durchgeführt. Auf der einen Seite dient dieser Workshop der Begutachtung der wissenschaftlichen Forschungsprojekte, die in den beiden Jahren 2008 und 2009 Rechenzeit am HLRB II Supercomputer verbraucht haben, und auf der anderen Seite können Benutzer des HLRB II ihre Erfahrungen untereinander sowie mit dem Personal des LRZ austauschen. Der Workshop wurde von über 100 Teilnehmern aus ganz Deutschland besucht, unter ihnen Wissenschaftler, Mitglieder des Lenkungsausschusses, sowie Personal des LRZ. Der Workshop war außergewöhnlich interdisziplinär. Die behandelten Gebiete umfassten Informatik, Maschinenbau (vorwiegend mit Strömungsmechanik beschäftigt), Astrophysik, Hochenergiephysik, Geowissenschaften, Physik der kondensierten Materie (beinhaltet sowohl Festkörperphysik als auch Plasmaphysik), Chemie und Biowissenschaften. Während der beiden Tage des Workshops konnten 42 Projekte ihre Ergebnisse in Vorträgen präsentieren. Die Vorträge waren in zwei Parallelsitzungen mit je 10 Vorträgen pro Tag unterteilt. Zusätzlich wurde an jedem Tag ein Plenarvortrag gehalten. Aufgrund der Gemischtheit der Disziplinen wurden die Sprecher gebeten, ihre Vorträge so vorzubereiten, dass auch fachfremde Zuhörer folgen konnten. Diese Anregung wurde von den Sprechern sehr gut umgesetzt, was nicht nur zu interessanten Vorträgen auf hohem wissenschaftlichen Niveau geführt hat, sondern auch zu gewinnbringenden Diskussionen zwischen Teilnehmern aus unterschiedlichen Forschungsgebieten. Da die Plenar-Vorträge von der gesamten Teilnehmerschaft besucht wurden, war die Gemischtheit der Zuhörerschaft hier besonders ausgeprägt. Am ersten Tag des Workshops sprach Bernd Brügmann (Astrophysiker von der Universität Jena) über "Black Holes and Gravitational Waves", während der Plenar-Vortrag des zweiten Tages von Sven Schmid (arbeitet bei der NASA für ein gemeinsames Projekt der NASA und der Universität Stuttgart) zum Thema "Characterization of the Aeroacoustic Properties of the SOFIA Cavity and its Passive Control" gehalten wurde. Beiden Sprechern gebührt ein großes Dankeschön für ihre herausragenden Vorträge, da Ihnen der Spagat zwischen allgemeinem Überblick und der Beschreibung der Herausforderungen in ihren Projekten besonders gut gelang. Abgesehen von den Vorträgen bestand die Möglichkeit, Projekte mit Hilfe von Postern zu präsentieren. Diese Möglichkeit wurde von einem weiteren Dutzend Projekte genutzt. Auch vor diesen Postern entstanden aktive Diskussionen unter den Workshopteilnehmern. Die Teilnehmer reichten insgesamt 70 Beiträge für den Berichtsband ein. Momentan befinden sich diese Beiträge im Prozess der Begutachtung durch neutrale Gutachter. Der Berichtsband wird voraussichtlich im Frühling 2010 veröffentlicht werden.

82 76 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Benutzerdiskussion Seit Ende 2009 befindet sich das LRZ in der aktiven Phase der Beschaffung eines Nachfolgesystems SuperMUC für den HLRB II Supercomputer. Da dieses neue System eine Leistung im Bereich von Petaflops/s bieten wird, nutzten die Teilnehmern des HLRB Workshops im Rahmen einer Benutzerdiskussion die Gelegenheit, ihre Anforderungen an die zukünftige Hard- und Software des geplanten Systems darzustellen. Das LRZ konnte seinerseits seine aktuellen Pläne und Konzepte für die Beschaffung präsentieren. Das LRZ wird die Ergebnisse der für beide Seiten sehr gewinnbringenden Diskussion in seine Beschaffungspläne einbringen Supercomputing Konferenzen in Hamburg und Portland Wie auch in den vergangenen Jahren präsentierte sich das Leibniz-Rechenzentrum zusammen mit den Partnern im Gauß-Zentrum (LRZ, HLRS Stuttgart, NIC Jülich) auf der Internationalen Supercomputing- Konferenz. Diesmal fand die Konferenz zum ersten Mal in Hamburg statt mit deutlich mehr Platz und auch noch mehr Interesse an den LRZ Demonstrationen. In Hamburg präsentierte das LRZ mit Hilfe seiner mobilen Stereo-Projektionsanlage Applikationen aus dem Bereich Computational Steering und Applikationen auf Graphik-Prozessoren. In Portland auf der Supercomputing Conference in den USA, dem wichtigsten Treffpunkt der internationalen High-Performance-Computing Community, wurden Simulationen aus dem Bereich der Molekulardynamik, Astrophysik und Grid Computing vorgestellt Veranstaltungen im Bereich Hochleistungsrechnen Das Aus- und Weiterbildungsprogramm des LRZ wird schon seit Längerem mit den anderen Partnern im Gauß-Zentrum koordiniert. Das LRZ konzentriert sich hierbei auf die rechnernahen Bereiche Parallele Programmierung, Programmiersprachen und Werkzeuge, Programmierung und Nutzung von Hoch- und Höchstleistungsrechnern, Performance-Optimierungen, Erstbenutzerkurse. Innerhalb Bayerns werden diese Art Kurse gemeinsam vom LRZ und der HPC-Gruppe am Regionalen Rechenzentrum Erlangen entwickelt und veranstaltet. Auch wächst innerhalb des Gauß-Zentrums das Angebot an gemeinsamen Kursen. Zahlreiche neue Kurse wurden 2009 in das Programm mit aufgenommen: Introduction to modern Fortran and associated Tools, LRZ und HLRS Parallel Programming of High Performance Systems, , LRZ und RRZE Performance Analysis Tools, , LRZ und JSC Scientific Programming with Python, , LRZ Wissenschaftliche 3D Animation mit Blender, , LRZ Introduction to Molecular Modelling, , LRZ Iterative Linear Solvers and Parallelization, , LRZ und HLRS Introduction to the Usage of High Performance Systems, Remote Visualization and Grid Facilities at LRZ, , LRZ Application Scalability, , Cray High-Performance Computing with GPGPUs, , LRZ und NVidia Parallel Programming with dynamic languages, , LRZ

83 Jahresbericht 2009 des Leibniz-Rechenzentrums InSiDE InSiDE (Innovatives Supercomputing in Deutschland) ist die Zeitschrift der drei deutschen Höchstleistungsrechenzentren (HLRS Stuttgart, NIC Jülich und LRZ) und inzwischen auch des Gauss Centre for Supercomputing (GCS). Die Zeitschrift wird an zahlreiche Institutionen und Personen, sowie die Nutzer der Höchstleistungsrechner verschickt. Online-Ausgaben der Zeitschrift sind unter Im Berichtszeitraum wirkte das LRZ an zwei Ausgaben mit, teils durch Benutzerberichte, teils durch eigene Beiträge (siehe Abschnitt 5.10, Veröffentlichungen der Mitarbeiter). 2.5 Aktivitäten für ein nationales und europäisches HPC-Konzept Das Gauss Centre for Supercomputing (GCS) e.v. hat sich unter dem Vorsitz von Prof. Dr. H.-G. Hegering in Europa als führende Kraft für das wissenschaftliche Hochleistungsrechnen entwickelt. Auf der konstituierenden Sitzung des wissenschaftlichen Beirats des GCS im BMBF am 9. November 2009 wurde seitens des Bundesministeriums erneut die Zusage zur Finanzierung auch der 2. Phase der Beschaffung der PetaGCS Rechner gegeben, so dass für das LRZ von einer Summe von 133 Mio. für die Beschaffung und den Betrieb des SuperMUC für die Zeit 2011 bis 2016 ausgegangen werden darf. Zur Beschleunigung der weiteren Entwicklung auf europäischer Ebene hat das GCS ein Kooperationsabkommen mit GENCI, der französischen Institution für das wissenschaftliche Hochleistungsrechnen, und mit dem Supercomputer Center in Barcelona als Vertretung Spaniens abgeschlossen. Der Aufbau einer europäischen Infrastruktur für Höchstleistungsrechnen im Rahmen des Projekts PRACE (Partnership for Advanced Computing in Europe) geht unter der Führung des GCS (Projektkoordinator Jülich) rasch voran: neben sechs Principal Partnern (PP) sind inzwischen 14 weitere Nationen als General Partner in PRACE aktiv. Im November haben sich vier PP (darunter Deutschland) durch ihre Regierungen schriftlich verpflichtet, über fünf Jahre je 20 Mio. pro Jahr an Rechenleistung für die PRACE Infrastruktur zur Verfügung zu stellen, zwei weitere Hosting Members wollen bis Juni 2010 folgen. Die Vorbereitungen für die PRACE-Governance sind weitgehend abgeschlossen, als vorübergehender Sitz für Direktor und Geschäftsstelle wurde Brüssel/Belgien bestimmt. Im November 2009 wurde auch der gemeinsame Antrag der PRACE-Partner für das Implementierungsprojekt (20 Mio. ) bei der EU eingereicht. Die deutsche Stimme im Management Board wird Herr Prof. Dr. A. Bode übernehmen Gauss Centre for Supercomputing Die mit der Gründung des Gauss Centre for Supercomputing (GCS) e.v. vorgesehene Zusammenarbeit der drei Höchstleistungsrechenzentren in Deutschland (Jülich Supercomputing Centre, Leibniz- Rechenzentrum der Bayerischen Akademie der Wissenschaften und Höchstleistungsrechenzentrum Stuttgart) wurde weiter intensiviert. Im Juni 2009 konnte der erste gemeinsame Call des Gauß-Zentrums für Large Scale Projects, das sind Projekte, die mehr aus 5% der Rechenzeit auf den jeweiligen Höchstleistungsrechnern verbrauchen, herausgegeben werden. Beim LRZ wurden drei solcher Projekte eingereicht, die erfolgreich begutachtet wurden. Unter dem Vorsitz von Prof. Dr. H.-G. Hegering hat GCS e.v. im Oktober 2009 als Geschäftsführer Herrn Dr. Claus Axel Müller (bisher Geschäftsführer T-Systems SfR) gewinnen können. Im November wurde der wissenschaftliche Beirat des GCS e.v. auf einer gemeinsamen Sitzung des erweiterten Steuerkreises im BMBF Bonn konstituiert. GCS hat durch die hervorragende finanzielle Ausstattung durch Bund und die Länder Bayern, Baden-Württemberg und Nordrhein-Westfalen in Europa eine führende Stellung im Bereich Hochleistungsrechnen gemeinsam mit Frankreich eingenommen. Im Rahmen von PRACE entsteht mit den sechs Hosting Members in Europa künftig eine leistungsfähige HPC- Infrastruktur für die Wissenschaft.

84 78 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme 2.6 Projekte und Kooperationen BMBF Verbundprojekt ISAR Das zusammen mit den Partnern TUM, RZG, IBM und Partec im Rahmen des BMBF-Förderprogramms IKT Forschung für Innovationen und einem Call für HPC-Software für skalierbare Parallelrechner eingereichte Projekt Integrierte System- und Anwendungsanalyse für massivparallele Rechner (ISAR) startete Anfang 2009 seine Arbeit. Am Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften sind derzeit zwei wissenschaftliche Mitarbeiter für das Projekt angestellt. Die Arbeiten für den Berichtszeitraum konzentrierten sich auf die folgenden Gebiete: Anwendung von Periscope -ein von der TU München entwickeltes automatisches LeistungsanalyseTool für Applikationen- auf den SeisSol-Code (Seismic Wave Propagation Solutions for Realistic 3D Media) Der Simulations-Code SeisSol lässt sich mit Periscope und verschiedenen Strategien auf dem HLRB II (Altix 4700) analysieren. So ermöglichten Analysen mit 510 Cores und der MPI- Strategie die Detektion eines Performance-Bottlenecks im SeisSol-Code ( Load-imbalance in der Hauptschleife). Vergleichende Analysen mit Scalasca (mit 64 Cores) ergaben ein vergleichbares Resultat. Die Rückmeldung des Befundes an die Entwickler des SeisSol-Codes sollten Verbesserungen der Performance ermöglichen. Da der SeisSol-Code ohne gleichzeitige Periscope- Analyse momentan bis 2040 Cores skaliert, werden demnächst Testdurchläufe bis zu dieser Core- Anzahl durchgeführt. Anbindung der Analyseagenten von Periscope an das vorhandene Monitorsystem In Testdurchläufen erfolgte die Anbindung von Analyseagenten an das vorhandene Monitoring- System. Dazu wurden die Agenten von Periscope gezielt an die systemweite Performance- Analyse angepasst. In diesem jetzt implementierten Periscope-System-Monitoring (PerSyst- Monitoring) werden die Grundideen von Periscope (Agentenhierarchie, Suchstrategien, Properties) sowie die Klassenbibliothek zur Implementierung genutzt. Spezifizierung von Performance-Bottlenecks Dazu werden die Properties von Periscope an PerSyst-Monitoring (die systemweite Performance- Analyse) angepasst. Eine komprimierte Ergebnisdarstellung (Informationsreduktion) zu einem Messzeitpunkt wird durch eine Aggregierung der Properties über die laufenden Jobs (JobID; Nutzung des PBS- Systems) bzw. über das System (z. B. Partition, gesamte Rechner) erreicht. Dazu wird momentan die Bestimmung statistischer Parameter einer Property (Mittelwert, Minimum, Maximum, Quantile) genutzt. Entwicklung von Suchstrategien zur Systemüberwachung Es wurden anhand einer konkreten Suchstrategie ( Stall Cycles Analysis ) Testdurchläufe durchgeführt und geprüft, wie eine Verfeinerung der Suche durch eine vorangegangene Messung in der Praxis erfolgen kann. So müssen alle Hardware Performance Counter (HwPC) für eine eventuell vollständige Suche ( worst case ) erfasst werden und in geeignete HwPC-Gruppen eingeteilt werden KONWIHR Software Initiative Multi- und Many-Core Prozessoren haben sich nicht nur im Hoch- und Höchstleistungsrechnen etabliert, sondern dominieren bereits heute den Desktop-Markt. Der technologische Wandel von immer leistungsfähigeren Einzelprozessoren hin zu Vielkernprozessoren, deren serielle Leistung im besten Fall nur noch graduell zunimmt, hat damit Auswirkungen in alle Bereiche der numerischen Simulation. Nur die effiziente und möglichst parallele Nutzung von Prozessorkernen wird in Zukunft eine Leistungssteigerung für numerische Applikationen erlauben. Zu diesem Zweck hat das Kompetenznetzwerk für Technisch- Wissenschaftliches Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR) zum Ziel, Wissenschaftler bei der Anpassung ihrer numerischen Anwendungen an diesen Wandel zu unterstützen. Konkret soll die effiziente und breite Nutzung der verfügbaren Parallelrechner und Clustersysteme gefördert werden.

85 Jahresbericht 2009 des Leibniz-Rechenzentrums 79 Zur Durchführung der Arbeiten sollen Wissenschaftler oder Doktoranden an eines der beiden Rechenzentren, RRZE oder LRZ) für einen Zeitraum von bis zu zwei Monaten eingeladen werden. Dort erhalten sie einen persönlichen Ansprechpartner, der sie bei den Arbeiten unterstützt und berät. Aus dem Bereich des LRZ wurden die folgenden Anträge aus den Fachgebieten Bioinformatik und Medizin eingereicht, die im Laufe des ersten und zweiten Quartals 2010 realisiert werden sollen: Genome Wide Epistatic Study Using High Performance Computing Graphic Cards Adaptation of open-source tools for Next Generation Sequencing (NGS) data alignment for use on high-performance multi-processor Machines Klassifikation anhand von Mikroarray-Daten Projekt: OMI4papps: Optimierung, Modellierung und Implementierung hoch skalierbarer Anwendungen Innerhalb des KONWIHR-Projektes OMI4papps: Optimierung, Modellierung und Implementierung hoch skalierbarer Anwendungen werden folgende Aktivitäten durchgeführt: Analyse der Performance und Anwendbarkeit neuer Programmiersprachen und -paradigmen für hochparallele Systeme Beurteilung von neuen Hardware-Architekturen, insbesondere von Beschleuniger-Systemen mit Grafikkarten bzw. CELL-Prozessoren Evaluierung der Entwicklungsumgebung RapidMind Auswertung der am LRZ betriebenen umfangreichen Datenbank mit den Hardware- Performancecountern der Applikationen des HLRB II im Hinblick auf typische Speicherzugriffsmuster Erweiterung der Benchmarksuite des LRZ Erweiterung des Kursangebots des LRZ im Bereich neuer Programmiersprachen und GPGPU- Programmierung PRACE: Partnership for Advanced Computing in Europe. Das LRZ arbeitet im PRACE-Projekt seit Anfang 2008 in den folgenden WorkPackages (WP) mit: WP2 Organisational Concepts of the Research Infrastructure Schwerpunkt der Mitarbeit des LRZ in WP2 liegt auf den Tasks 2 (Governance Structure) und 4 (Peer Review Process), worin organisatorische Konzepte für die zukünftige europäische HPC Infrastruktur erarbeitet wurden. WP4 Distributed System Management Im zweiten Jahr des PRACE-Projekts konzentrierten sich die Arbeiten in WP4 auf die Bereitstellung der Software für die benötigten Dienste und die Unterstützung der Administratoren der Prototyp-Systeme bei der Installation dieser Software. Dabei konzentrierte sich das LRZ auf die Themenschwerpunkte Globus, Monitoring und Benutzerzugang/Single-Sign-On, um die in DEISA gewonnene Expertise in diesen Bereichen auch in PRACE einzubringen. Im Rahmen mehrerer Arbeitstreffen und regelmäßiger Videokonferenzen wurden die für eine Anbindung von Tier-0-Ressourcen notwendigen Middleware-Tools identifiziert, evaluiert und für eine Installation vorbereitet. Das LRZ hat sich insbesondere um die Vorbereitung, Bereitstellung und Installationsunterstützung der Globus Software gekümmert. Außerdem wurde basierend auf den Erfahrungen aus DEISA auch in PRACE das Monitoring-Tool Inca aufgesetzt, dessen zentrale Komponenten ebenfalls am LRZ laufen. Derzeit werden die acht von PRACE betriebenen Prototyp-Ressourcen damit überwacht. WP6 Software Enabling for PetaFlop/s Systems Innerhalb von WP6 wurden zur Vorbereitung der Software für zukünftige Hochleistungsrechner neue Programmiermodelle untersucht und eine Übersicht der wichtigsten europäischen Codes erstellt. So wurde die Performance von mehr als einem Dutzend europaweit intensiv genutzter Applikationen auf verschiedenen Plattformen vermessen und die Anforderungen an zukünftige Rechner dokumentiert. Das LRZ analysierte, optimierte und skalierte GADGET, ein Softwarepaket zur Simulation der Strukturbildung bei der Entstehung des Universums vom Max-Planck In-

86 80 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme stitut für Astrophysik. Die erzielten Ergebnisse und gewonnenen Best Practices für die Portierung von GADGET auf Blue Gene/P, Power6 und Nehalem EP wurden in mehreren Berichten dokumentiert. Bessere Skalierung und effizientere Verwaltung von Hauptspeicher sind notwendige Eigenschaften für zukünftige Petaflops-Systeme, die in GADGET bereits zu finden sind. Ein weiterer Unterpunkt zur Vorbereitung der Software für zukünftige Hochleistungsrechner untersucht neue Programmiermodelle, um den gestiegenen Anforderungen - vor allem an die massive Parallelität der Hardware - gerecht zu werden. Das LRZ testet hier den Nutzen und die Performanz von neuartigen Sprachen und entwickelt Kursangebote für seine Benutzer. Unter anderem wurde mit Unified Parallel C, Co-Array Fortran und RapidMind experimentiert. WP7 Petaflop/s Systems for 2009/2010 In Task 4 wurde die Risikoaufstellung überarbeitet, verfeinert und erweitert und in einem Abschlussbericht dokumentiert. WP8 Future PetaFlop/s Computer Technologies beyond 2010 In WP8 hat das LRZ im Januar 2009 die Leitung des Arbeitspakets und den Vorsitz von STRA- TOS übernommen. STRATOS steht für PRACE advisory group for STRAtegic TechnOlogieS und ermöglicht eine enge Zusammenarbeit zwischen PRACE-Partnern und Industrievertretern im Bereich zukünftiger Technologien. Innerhalb vom WP8 wurden neun Prototypen angeschafft, installiert und evaluiert. PRACE Prototyp: 2009 wurde am LRZ ein hybrides Prototypsystem angeschafft, um die Eignung eines solchen Systems für den Jobmix am LRZ testen zu können. Das SGI System verbindet einen SGI ICE-Teil, bestehend aus dünnen Knoten mit jeweils 8 Nehalem-EP-Prozessorkernen, zukünftig mit einem SGI UV-System, welches auf dicken ccnuma-knoten mit 256 Prozessorkernen basiert. Das Gesamtsystem soll durch Larrabee- und ClearSpeed-Karten beschleunigt werden. Der ICE-Teil wurde Ende Juli in Betrieb genommen und intensiven Tests unterzogen. Synthetische Benchmarks zum Messen einzelner Komponenten wurden durch Applikationsbenchmarks zur Messung der erzielbaren Anwendungsleistung des Systems ergänzt. Alle Tests zeigen die deutliche Überlegenheit der neuen Intel Nehalem Prozessoren im Vergleich zu anderen, momentan verfügbaren Prozessoren. 2.7 Tätigkeiten im Server-Betrieb Die Tätigkeiten im Bereich der Server-Dienste zeichnen sich auch im Jahre 2009 vor allem durch die ständigen Arbeiten aus, die zur Aufrechterhaltung eines stabilen Betriebes notwendig sind Linux-Serversysteme Bei den physischen Servern ist das Jahr 2009 geprägt durch die stetige Migration der darauf befindlichen Dienste auf virtuelle Maschinen (VMs). Gegen Ende des Jahres sind deshalb nur mehr ein Duzend DELL-Server alter Bauart (PowerEdge 2450, 2550) in Betrieb. Etwa ein Drittel der im Vorjahr aktiven OxygenRAID-Server von AdvancedUnibyte sind abgeschaltet und dienen als Materialersatz für die verbliebenen Hosts. Ein halbes Duzend SUN-Server neuerer Bauart sind aufgrund der Dienstmigration frei für nicht zu virtualisierende Dienste, beispielsweise für die Überwachung der virtuellen Infrastruktur. Erfreulicherweise gab es auch in 2009 keine gravierenden bzw. vermeidbaren Dienststörungen wegen Ausfalls veralteter Hardware Virtualisierung am LRZ Das Jahr 2009 war geprägt durch die Ausschreibung zur Erweiterung des VMware-Cluster und der Inbetriebnahme der Hardware. Der im Vorjahr initiierte VMware Cluster, bezeichnet als ESX-Cluster-1 wurde um ein System, basierend auf einem Server der Modellserie "SUN Galaxy X4150" 4 Cores und 64 Gigabyte RAM, ausgebaut. Als Speichermedium der virtuellen Hosts dient ein NAS-Filer der Firma Net- App. In diesem Jahr wurden intensive Gespräche mit den Serverherstellern geführt und die Ausschreibung durchgeführt. Ausgewählt wurde eine Lösung basierend auf 32 HP BL490G6 Server Blades der Firma HP mit 2x 10 Gigabit Ethernet und 72 GB Arbeitsspeicher.

87 Jahresbericht 2009 des Leibniz-Rechenzentrums 81 Die zweite Jahreshälfte war geprägt vom Aufbau und der Abnahme der gelieferten Hardware sowie von deren Inbetriebnahme. Die Anlieferung der Hardware ursprünglich geplant für Mitte 2009 hat sich wegen nicht lieferbarer Komponenten bis Oktober 2009 hingezogen. Probleme bei der Inbetriebnahme der Server haben einen Testbetrieb bis in den Dezember verzögert. Server-Virtualisierung hat sich im LRZ zu einer etablierten Form des Serverbetriebs entwickelt. Die Server-Virtualisierung auf VMware-Basis hat in den Jahren 2008 und 2009 eine Vertrauensbasis erreicht, sodass Produktions-Server aus allen Bereichen des LRZs die Server-Virtualisierung nutzen. Das starke Wachstum im Bereich Server-Virtualisierung spiegelt sich vor allem in der Anzahl der betriebenen virtuellen Maschinen (vgl. Abbildung 45) wieder. Die Migration von LRZ-Diensten, die bisher eigene Hardware-Ressourcen beansprucht haben, führt zum stetigen Abbau alter Server. Ein reiner Ersatz durch neue Hardware ohne Virtualisierung würde Stillstand bedeuten, denn das gewachsene Dienstleistungsangebot des LRZ hat zur Verknappung von Stellfläche, Strom und Klimatisierung geführt. Abbildung 45 Anzahl virtueller Hosts und Zeitpunkt erster Dienst-Migrationen auf VMware ESX Einhergehend mit der Zunahme virtueller Hosts (siehe Abbildung 45) spielt deren Management eine immer wichtiger werdende Rolle. Deshalb wurde 2009 eine Beta-Version des VMware vlifecycle Managers ausgiebig getestet und weitere Möglichkeiten des Managements in einer von uns betreuten Diplomarbeit evaluiert. Geplant ist, sämtlichen Beteiligten, vom Endkunden über die Entscheidungsinstanzen bis hin zum Administrator, ein zentrales Instrument zur Verwaltung der virtuellen Infrastruktur an die Hand zu geben. Es ist geplant, dass der Prozess von der Beantragung der virtuellen Maschine bis hin zur Provisionierung - soweit möglich und sinnvoll - automatisiert wird. Nicht zuletzt die (geplante) Einführung eines Dienstleistungskatalogs in 2009 macht effiziente Workflows notwendig. Trotz der Beschaffung neuer Hardware und der Inbetriebnahme war es vor allem wegen der Lieferproblematik nicht möglich, den neuen ESX-Cluster zum Produktionsbetrieb zu führen wird geprägt

88 82 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme sein durch die Produktivführung dieses Clusters. Außerdem ist geplant, eine Sicherheitslösung für die Infrastruktur zu evaluieren und umzusetzen PCs unter Linux als Mitarbeiter-Arbeitsplätze Im Bereich der Mitarbeiter-Arbeitsplätze gab es 2009 keine gravierenden Änderungen, weder in Bezug auf den Einsatz neuer Hardware noch beim verwendeten Betriebssystem "Novell/SuSE Linux Enterprise Desktop -Version 10 ServicePack 2", kurz bezeichnet als SLED Zum alltäglichen Betrieb gehören regelmäßige Softwareupdates. Ab April 2010 wird das vorgenannte ServicePack 2 seitens des Distributors Novell/SuSE nicht mehr unterstützt, d.h. notwendige Sicherheits- Updates der Software stehen nicht mehr zur Verfügung. Als Reaktion darauf erfolgt der seit November 2009 verfügbare Upgrade auf die aktuelle Version bzw. das ServicePack 3 wie gewohnt Schritt für Schritt. Neuinstallationen waren nur bedingt durch zahlreiche Neuanstellungen von Mitarbeitern SGI Altix Linux-Cluster Mitarbeiter-Arbeitsplätze Kurs-Cluster BSB + BVB Server Grid-Server Server Basisdienste Virtuelle Hosts Abbildung 46 Anzahl der Linux-Hosts im Leibniz-Rechenzentrum

89 Jahresbericht 2009 des Leibniz-Rechenzentrums Betriebsüberwachung Die Verbesserung der Überwachung ist ein kontinuierlicher Prozess, der auch 2009 fortgesetzt wurde. Hierzu zählt das bereits in den Vorjahren praktizierte Prinzip, die Dienstüberwachung auf mehrere sogenannte Überwachungssatelliten zu verteilen, deren Konfiguration in der Obhut verschiedener Dienstadministratoren liegt. Diese Satelliten sind jeweils einer Gruppe von Servern und damit einer Dienstgattung oder einem Aufgabenbereich zugeordnet. Im LRZ existieren folgende Gruppierungen zur Überwachung: Höchstleistungsrechnen, Linux-Cluster, Mailserver, AFS-Fileserver, TSM-Sicherung, Netzdienste, Webserver, Windows-Dienste usw. Neben der frei verfügbaren Überwachungssoftware Nagios, die bei Linux- und Solaris-basierten Betriebssystemen zum Einsatz kommt, spielt das Softwareprodukt SCOM im Bereich der Windows-Server die zentrale Überwachungsrolle. Hinzu kommen eigens angefertigte Überwachungsskripte. Die Satelliten sind es auch, die sich um die automatische Benachrichtigung derzeit beschränkt auf den Mailversand der jeweiligen Dienstadministratoren kümmern. Meldungen, die darüber hinaus auch Dritten zugänglich sein sollen, zumal außerhalb der regulären Dienstzeit, wenn (Nacht-) Operateure in der LRZ-Leitwarte ein wachsames Auge auf den Dienstbetrieb werfen, werden auf zwei redundante sogenannte Logging-Server weitergeleitet. Die beiden Logging-Server liefern schließlich mittels Agenten sämtliche Informationen an die zentrale Überwachungsschnittstelle HP OpenView Operations (OVO) im Mittelpunkt der LRZ-Leitwarte. OVO dient damit, obwohl weitaus vielseitiger, als mandantenfähiger Sammelpunkt betriebswichtiger Informationen und Störungsmeldungen. Die relativ schlanke Handhabung von OVO ermöglicht es, Alternativen für ein mandantenfähiges sogenanntes Messaging-System zu diskutieren. Mit dem IBM Software Landeslizenzvertrag besteht die Möglichkeit, OVO durch das Teilprodukt Tivoli Netcool/OMNIbus zu ersetzen. Ende 2009 wurde die Software vorgestellt, die in 2010 nach entsprechender Evaluation OVO ersetzen soll. Neben dem zentralen Überwachungssystem der Leitwarte existieren weitere Bildschirme zur Anzeige des allgemeinen Betriebszustands des LRZ. Beispielsweise liefern 4 Monitore Informationen über Speicherkomponenten, genauer gesagt für die Beobachtung der Bandroboter und -laufwerke, der NAS-Filer und TSM-Serverinstanzen. Die Monitore der Leitwarte bilden somit ein Visualisierungsfrontend für eine ganze Reihe von Überwachungsmaßnahmen. Eine Eigenentwicklung eines Werkzeugs zur Datenflussanalyse ermöglicht zum Beispiel, die Auslastung der einzelnen SAN-Ports über die Zeit zu messen und in Diagrammen wiederzugeben. Es kann auch berechnet werden, wie viele Daten in einem bestimmten Zeitintervall durch einen SAN-Port geflossen sind. Zusätzlich kann man akkumulierte Auslastungsdiagramme von logisch zusammenhängenden Ports (z.b. alle Ports eines Servers) erzeugen lassen. Mit diesem Tool können Engpässe im SAN-Bereich pro-aktiv erkannt und so frühzeitig geeignete Gegenmaßnahmen ergriffen werden. Eine weitere z.b. bei Performancemessungen sehr nützliche Eigenschaft dieses Werkzeugs ist, dass die Auslastungsdaten in Echtzeit abgefragt werden können und man sich so den aktuellen Datendurchsatz eines SAN-Ports sekundenaktuell anzeigen lassen kann. So leistete dieses Feature z. B. bei der Performanceoptimierung und -messung der beiden HLRB II-Archivserver gute Dienste. Ferner werden Werkzeuge zur Logdateiauswertung von Betriebssystem-, FC-Switch- und TSM- Logdateien eingesetzt. Dieses Auswertungstool durchsucht die genannten Datenquellen in regelmäßigen Abständen nach Einträgen, welche eine oder mehrere, von den Administratoren vordefinierte, Zeichenfolgen enthalten. Falls für eine Servermaschine, einen FC-Switch oder eine TSM Serverinstanz verdächtige Meldungen gefunden werden, werden diese wiederum automatisch an die betreffenden Administratoren g t. Auch herstellereigene Software wird zur Überwachung eingesetzt. Der Betriebszustand und die Ressourcennutzung aller NAS-Filer zum Beispiel wird mit Hilfe der Überwachungssoftware "Operations Manager" zentral erfasst und in der Leitwarte abgebildet. Zusätzlich kann die Performance der Systeme auch in Echtzeit analysiert werden.

90 84 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme 2.8 Aktivitäten im Bereich Verteilte Ressourcen Grid-Computing entstand in den späten 90er Jahren vor dem Hintergrund, aufwendige physikalische Berechnungen über mehrere Supercomputer verteilt durchführen zu wollen. Daraus entwickelte sich der generelle Wunsch, weltweit vorhandene heterogene Ressourcen wie Rechner, Instrumente, Software und Daten zur koordinierten Lösung sogenannter großer Herausforderungen (grand challenges) verwenden zu können. Typische Grid-Anwendungen sind daher daten- oder rechenintensive Berechnungen, die auf Ressourcen innerhalb sogenannter virtueller Organisationen (VOs) verteilt werden. Beispiele finden sich in der Wettervorhersage, in Astronomie-Projekten, der Hochenergiephysik, in biologischen Genom- Projekten, in der Medikamentenforschung oder in den Wirtschaftswissenschaften. In letzter Zeit hat auch die Industrie ein zunehmendes Interesse am Grid-Computing signalisiert. Schon heute sind sich deshalb viele Analysten darüber einig, dass sich verteilte Systeme, insbesondere Grid-Computing und das in seiner Bedeutung rapide zunehmende Cloud-Computing, das insbesondere zur Deckung von Bedarfsspitzen geeignet ist, mit zu den wichtigsten Technologien der nächsten Jahre und zum Motor völlig neuer Anwendungen entwickeln werden. Die Arbeiten im Bereich Grid-Computing erfordern ein breit gefächertes Know-how und werden deshalb von den Abteilungen Kommunikationsnetze, Hochleistungssysteme und Benutzernahe Dienste und Systeme gemeinsam durchgeführt. Als abteilungsübergreifende Einrichtung war und ist der Arbeitskreis Grid Computing (AK-Grid) maßgeblich an der Koordinierung der verschiedenen Grid-Projekte (D-Grid, DEISA-2, PRACE, LCG Tier-2, LRZ-Grid, Grid Aktivitäten an LMU und TUM) innerhalb des LRZ und im Münchner Raum beteiligt, hilft Synergien auszunutzen und Doppelarbeit zu vermeiden. Darüber hinaus widmete sich der AK-Grid in 2009 dem neu aufgekommenen Thema Cloud-Computing. Aufgrund der räumlichen Nähe und den thematischen Gemeinsamkeiten war es naheliegend, auch Mitarbeiter vom RZG zum Arbeitskreis einzuladen. Bis zu 10% der HLRB II-Rechenleistung sowie ein nicht unerheblicher Teil der Rechenleistung unseres Linux Clusters werden über Grid-Middleware von den Wissenschaftlern in Deutschland und Europa abgerufen. Im Folgenden beleuchten wir einige der in den Grid-Projekten durchgeführten Arbeiten ausführlicher D-Grid (Förderung e-science und vernetztes Wissensmanagement des BMBF) In Deutschland hat insbesondere die D-Grid-Initiative (www.dgrid.de) die Auswirkungen der neuen Technologie Grid auf das wissenschaftliche Arbeiten thematisiert und ein entsprechendes Forschungs- und Entwicklungsprogramm realisiert. D-Grid hat es sich zum Ziel gesetzt, alle Grid-Aktivitäten in Deutschland zu bündeln, um so intern Synergieeffekte auszunützen und nach außen mit einer einheitlichen Stimme sprechen zu können. Die vom BMBF für den Zeitraum von 2005 bis 2010 geförderte D-Grid Initiative will in Deutschland eine e-science- Kultur ähnlich der überaus erfolgreichen britischen e-science initiative aufbauen. Im Rahmen von D-Grid nahm das LRZ 2009 an vielen Workshops und Treffen teil und führte drei Schulungen durch: ein Hands- On-Tutorial über g-eclipse, ein Hands-On-Training zum Web Service Resource Framework (WSRF) und eine Globus-Benutzerschulung für PT-Grid (Plasma-Technologie). Die Förderanträge D-Grid Scheduler Interoperability (DGSI), SLA4D-Grid Service Level Agreements für das D-Grid und Grid Intrusion Detection (GIDS), an denen das LRZ beteiligt ist, wurden Anfang 2009 genehmigt und werden im Folgenden ausführlicher beschrieben.

91 Jahresbericht 2009 des Leibniz-Rechenzentrums 85 Abbildung 47 Die D-Grid Initiative umfasst mittlerweile knapp 30 VOs aus unterschiedlichsten Bereichen, die in dieser Broschüre vorgestellt werden. Das LRZ unterstützt mit seinen Rechnern alle diese VOs. Ref.: ISBN D-Grid Integrationsprojekt (DGI-2) Als Rechenzentrum, und damit als Ressourcenanbieter, war das LRZ vorrangig am sogenannten D-Grid Integrationsprojekt (DGI-2, Laufzeit Jan bis Dez. 2010) beteiligt. Aufgrund langjähriger guter Kontakte zu HPC-Benutzern aus Astro- und Hochenergiephysik trat das LRZ aber auch als assoziierter Partner der Astrophysik- und der Hochenergiephysik-Community auf und beteiligte sich auch an deren Arbeitstreffen. Außerdem ist zur Vertretung der Globus-Ressourcen-Anbieter ein Mitarbeiter des LRZ in das neu gegründete Technical Advisory Board (TAB) des D-Grid gewählt worden. Das LRZ stellt im verteilten Kompetenzzentrum Middleware (Fachgebiet 1) vielfältiges Know-how für die Unterstützung von Benutzern und Ressourcenanbietern bezüglich Globus bereit. Auf den Produktionssystemen des LRZs wurde Globus von GT4.0.7 auf GT4.0.8 angehoben und für Globus GT4.0.8 wurden binäre Distributionen für von Benutzern nachgefragte Betriebssysteme (SLES10) erstellt. Da im D- Grid die Migration von GT4.0 auf GT4.2 beschlossen wurde, wurden auch binäre, angepasste Distributionen für GT4.2.1 für Scientific Linux 5.3 für das D-Grid erstellt. Für einen Übergangszeitraum von 6 bis 12 Monaten sollen nun im D-Grid beide Globus Versionen parallel betrieben werden, da sie nicht 100% kompatibel sind. Nach Ende der Übergangsphase soll dann auf GT4.2 oder gleich auf das neuere GT5 migriert werden. Entsprechend der Grid- und Interoperabilitäts-Philosophie hat das LRZ daran gearbeitet, die Benutzung von gsissh als Login-Methode für die Benutzer zu vereinfachen, indem es RPM-Pakete für gsissh und eine neue Distribution von gsissh-term erstellte und entsprechende Anleitungen zu Installation und Gebrauch veröffentlichte (http://www.grid.lrz.de/en/mware/globus/client/gsissh_term.html ). Das LRZ beteiligte sich an der Erarbeitung eines D-Grid-weiten Betriebskonzepts, der Koordination des Supports (Su- Ko) sowie der Referenzinstallation und pflegte die Installationsanleitung für Globus, die genau auf die Anforderungen der D-Grid-Systeme zugeschnitten ist. Im Rahmen des DGI-Fachgebiets 2-3 hat das LRZ Ressourcen für D-Grid angeschafft und betrieben sowie zentrale Dienste bereitgestellt. Die im Rahmen der D-Grid-Sonderinvestitionen im Herbst 2008 angeschafften Serversysteme (zwei Serversysteme Sunfire X4600) zur Remote-Visualisierung sowie die

92 86 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme dazu notwendige Software (AVS, Amira/Avizo, IDL) wurden Anfang bzw. Mitte 2009 in Betrieb genommen. Das LRZ hat die Ressourcen, die im Rahmen früherer Sonderinvestitionen beschafft wurden, weiterbetrieben und für das D-Grid verfügbar gemacht. Im Jahr 2009 wurden auf diesen Ressourcen fast 1,5 Mio. Jobs submittiert, die ca. 4,4 Mio. CPU-Stunden verbraucht haben. Der Speicherplatz im dcache- Pool belief sich auf ca. 500 TByte. Als zentrale Dienste für D-Grid hat das LRZ Grid-Monitoring mittels der Werkzeuge MDS, WebMDS, GridCSM und Inca sowie den zentralen MyProxy-Server zur Authentisierung der Nutzer betrieben. Das im D-Grid mit LRZ-Beteiligung entwickelte neue Grid-Monitoring-Werkzeug D-MON (s. Abschnitt ) wurde aus dem Experimental- in den Produktionsbetrieb überführt (http://d-mon.d-grid.de/ ). D- MON bündelt nun die Monitoring-Informationen aus allen verwendeten Middleware-Systemen und gibt dem Benutzer einen VO-spezifischen Überblick über das gesamte D-Grid. Zum User-Level-Monitoring vor allem der Globus-Dienste wird in DGI derzeit an dem Aufbau einer Inca-Umgebung gearbeitet. Derzeit werden acht Ressourcen überwacht. Die Produktivführung wird in 2010 erfolgen. Neben Support und Betrieb konzentrierte sich das LRZ im Rahmen vom DGI Fachgebiet 2-4 vor allem auf die Bereitstellung einer einheitlichen Benutzer-Umgebung für D-Grid. Das LRZ hat ein verfeinertes Konzept erarbeitet und publiziert. Nach Konsultationen mit AstroGrid-D sind Standard-Software- Komponenten identifiziert worden, die Teil der einheitlichen Benutzerumgebung werden sollen. Das Modules-Tool wurde gewählt, um eine einfache und einheitliche Bedienung zu gewährleisten. Die Verifizierung und Überwachung dieser Umgebung auf den D-Grid Ressourcen erfolgt mit Inca. Eine Pilot- Installation von Inca wurde dazu in Betrieb genommen. Zurzeit laufen stündlich 360 Middleware- und 32 Software-Stack-Tests. Reporter sind auf acht Produktionssystemen im D-Grid installiert. Es wurde intensiver Globus-Support für alle Communities, allen voran die Astro-Community, geleistet DGSI Das D-Grid-Gap-Projekt D-Grid Scheduler Interoperability (DGSI) konzipiert und entwickelt eine Interoperabilitätsschicht für Scheduling in Service Grids, die es Benutzern einer Community erlaubt, Arbeitslast auf Ressourcen einer anderen Community zu verlagern. Am Juni 2009 nahm das LRZ am Kick-Off Meeting teil. Seitdem gab es fünf weitere Präsenztreffen und eine Videokonferenz, jeweils mit LRZ-Beteiligung. Das LRZ ist als Leiter von Task 4 für die Anbindung lokaler Resource Management-Systeme verantwortlich. Im Rahmen dieses Tasks wird die Anbindung des Scheduling-Systems an das Batch-System Sun Grid Engine implementiert. Das LRZ ist an weiteren vier Arbeitspunkten im Projekt beteiligt und hat an zwei Projektberichten mitgearbeitet SLA4D-GRID Das D-Grid-Projekt Service Level Agreements for D-Grid (SLA4D-GRID) entwirft und realisiert eine Service Level Agreement-Schicht (SLA-Schicht) für das D-Grid. Diese Schicht zur Vereinbarung einer festgelegten Dienstgüte bietet einzelnen Benutzern, ganzen D-Grid Communities, sowie den Anbietern von D-Grid-Ressourcen die Gewährleistung der Ressourcennutzung unter wirtschaftlichen Bedingungen. Am 2. und 3. Juni 2009 nahm das LRZ am Kick-Off Meeting teil. Seitdem gab es drei weitere Präsenztreffen und vier Videokonferenzen mit LRZ-Beteiligung. Innerhalb des Projekts wird das LRZ an der Anbindung der SLA-Software an die in D-Grid eingesetzte Grid-Middleware und das Monitoring sowie and der Koordination mit den Community-Projekten und der Überführung in den Regelbetrieb mitarbeiten CLOUDCOMP2009 Vom 19. bis 21. Oktober 2009 wurde in München die First International Conference On Cloud Computing, CLOUDCOMP2009, durchgeführt, an deren Organisation Prof. Bode als Program Chair beteiligt war (www.cloudcomp.eu).

93 Jahresbericht 2009 des Leibniz-Rechenzentrums DEISA Das zweite Großprojekt des LRZ im Grid-Bereich mit einem Arbeitsschwerpunkt im HPC ist DEISA (Distributed European Infrastructure for Supercomputing Applications, DEISA ist ein Konsortium führender nationaler Höchstleistungsrechenzentren in Europa und betreibt eine langfristig angelegte verteilte Produktionsumgebung für Höchstleistungsrechnen im europäischen Maßstab. Der Zweck dieser seit 2008 im EU-Forschungsförderungsprogramm FP7 von der EU geförderten Forschungs-Infrastruktureinrichtung ist es, wissenschaftliche Forschung in einem breiten Spektrum von Fachgebieten und Technikbereichen dadurch zu fördern, dass europäische Kapazitäten im Höchstleistungsrechnen gekoppelt, verstärkt und erweitert werden. Dies geschieht augenblicklich durch eine tiefgreifende Integration nationaler Höchstleistungsplattformen, die durch ein dediziertes europäisches Höchstleistungsnetz (im Rahmen von GÉANT2/3) mit Hilfe innovativer System- und Grid- Software eng vernetzt sind. LRZ-Mitarbeiter nahmen an DEISA Technical Meetings in Amsterdam, Barcelona, Bologna, Brüssel, Paris und Stuttgart, an DEISA Training Sessions in Jülich und Amsterdam, dem DEISA Symposium in Amsterdam, sowie an zahlreichen DEISA-Videokonferenzen teil und beteiligten sich aktiv an Diskussionen in über 20 DEISA-Mailinglisten. Abbildung 48 Teilnehmer am DEISA-2 Projekt. Mit gestrichelten Linien sind die vier neuen assoziierten Partner CSCS (Schweiz), CCRT/CEA (Frankreich), KTH (Schweden) und JSCC (Russland) gekennzeichnet. Ref

94 88 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme edeisa Im Rahmen der Verlängerung von edeisa leitet das LRZ die sub-tasks GT4 retained components und Workflow and metascheduling tools. Die Überführung des Globus-Testbeds in den Produktiv-Betrieb auf allen DEISA-Sites wurde abgeschlossen und Workflow- und Metascheduling-Software auf ihre Einsatzfähigkeit in DEISA hin getestet. Auf Basis dieser Tests wurde der zentrale GridWay-Meta-Scheduler für DEISA installiert, um Jobs via Globus auch von außerhalb des DEISA-Netzwerks zu den DEISA- Supercomputern schicken zu können, die keine externe Schnittstelle besitzen. Diese vom LRZ erarbeitete neue Funktionalität wurde beim edeisa Abschluss-Review in Brüssel mit großem Erfolg den Gutachtern der Europäischen Kommission präsentiert. In weiteren edeisa-aktivitäten wurden vom LRZ die Geschwindigkeit des Datenübertragungstools GridFTP in DEISA optimiert, der Storage Resource Broker (SRB) untersucht und mehrere Hilfsprogramme zur Benutzerunterstützung geschrieben. Das edeisa-projekt konnte Ende Mai 2009 mit großem Erfolg abgeschlossen werden DEISA-2 Die erfolgreichen Arbeiten von DEISA und edeisa werden seit Mai 2008 im Nachfolgeprojekt DEISA- 2 fortgesetzt. DEISA-2 läuft bis Mitte Abbildung 48 zeigt die Teilnehmer an diesem Projekt. Das LRZ beteiligt sich dabei insbesondere an den Service Activities Technologies, Application Enabling und Operations sowie einer Joint Research Activity Integrated DEISA Development Environment Work Package 2: Dissemination Das LRZ beteiligte sich aktiv an Erstellung und Verteilung des DEISA Newsletters, der sechs Mal pro Jahr erscheint und besonders gelungene Forschungsarbeiten aus DEISA vorstellt.

95 Jahresbericht 2009 des Leibniz-Rechenzentrums 89 Abbildung 49 Der sechs Mal im Jahr erscheinende DEISA-Newsletter berichtet über beeindruckende wissenschaftliche Ergebnisse, die mithilfe der DEISA-Infrastruktur erzielt werden konnten. Das vom LRZ betreute Projekt GravTurb (s. u. DECI-3) ist das Hauptthema der letzten Ausgabe in 2009 (oben rechts). Ref.

96 90 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Work Package 3: Operations Betrieb der Infrastruktur Das LRZ betreibt für DEISA neben der Rechen-Ressource HLRB II auch deren Anbindung an das dedizierte DEISA-Netz, einen Client für das gemeinsame Dateisystem GPFS, die Middlewares Globus und UNICORE für den Benutzerzugang, sowie Dienste zur Benutzerverwaltung, Budgetierung, und Funktionsüberwachung der Benutzerdienste. Mit der zunehmenden Nutzung der DEISA-Infrastruktur spielt die Dienstgüte in DEISA eine immer größere Rolle. In 2009 wurden mehrere Maßnahmen unternommen, um dieser wachsenden Bedeutung gerecht zu werden. Damit einher gehend steigt die Gefahr von Angriffen auf die Infrastruktur, weshalb dem Thema Security mehr Aufmerksamkeit geschenkt wird. Das LRZ beteiligt sich intensiv an diesen Aktivitäten. Um eine stärkere Kontrolle der Service-Qualität in der DEISA Infrastruktur zu gewährleisten und um sicherzustellen, dass auftretende Schwierigkeiten zeitnah gelöst werden, wurden ein Trouble Ticket- System sowie die Rolle des Operator on duty eingeführt. Diese Rolle wurde seitdem mehrfach vom LRZ ausgefüllt. Im Rahmen der Verbesserung der Service-Qualität wurden DEISA-Dienste auf virtuelle Maschinen umgezogen und mit Hilfe des Monitoring-Tools Nagios überwacht Inca Das Monitoring-Werkzeug Inca wird erfolgreich für die Versionsprüfung des DEISA Common Production Environment (DCPE), für die Funktionsüberwachung der Middleware sowie für die Konsistenzprüfung der Benutzerdaten eingesetzt. Die zentralen Inca-Komponenten werden für ganz DEISA am LRZ betrieben. Zahlreiche Updates und Änderungen der Infrastruktur wurden durchgeführt. Dazu zählen die Upgrades zu den neuesten Versionen, die Integration neuer DEISA Ressourcen, die Implementation von Wartungs-Informations-Sichten sowie die Entwicklung von Nutzungs- und Verfügbarkeitsreports. Inca führt regelmäßig mehr als 1000 Tests auf 12 Ressourcen durch. Um die DEISA Inca Infrastruktur stetig zu verbessen, werden derzeit u.a. Inca Reporter für die Überwachung des General Parallel File Systems (GPFS) entwickelt. Um eine zeitnahe Behandlung von Problemen und Änderungswünschen zu gewährleisten, pflegt das LRZ einen engen Kontakt mit dem Inca Entwickler-Team am San Diego Supercomputing Center (SDSC) DEISA Maintenance Message System Wie sich herausgestellt hat, ist eine frühzeitige Information von Administratoren und Benutzern über zukünftige Dienstausfälle durch Wartungen, Anpassungen, Erweiterungen, etc. sehr wichtig. Nur so können die von diesen Diensten abhängigen Personen angemessen darauf reagieren und z.b. auf andere Systeme ausweichen. Zur Automatisierung dieser Informationsmechanismen wurde eine Arbeitsgruppe gegründet, die vom LRZ geleitet wird Work Package 4: Technologies Das LRZ hat eine aktive Rolle bei der Untersuchung des neuesten Globus Releases GT4.2 und der neuimplementierten Middleware UNICORE 6 auf seine Eignung zum Produktionseinsatz in DEISA und hilft mit, die neueste Single-Sign-On-Technologie Shibboleth zu evaluieren. Außerdem beteiligt sich das LRZ an den Aktivitäten im Bereich von Remote Visualization, Cloud-Computing und Virtualisierung sowie zur Evaluierung von Monitoring-Tools Single-Sign-On und Shibboleth Single-Sign On bedeutet für den Benutzer eine spürbare Erleichterung im täglichen Gebrauch der Supercomputer, da er mit einem einzigen Eintippen seines Passworts alle Services der Infrastruktur benutzen kann. Dazu wurde der vom LRZ betriebene Shibboleth Identity Provider, IdP, (siehe Abschnitt 1.3.4) über den Short Lived Credentials Service (SLCS) des DFN zur Authentifizierung in Grids verwendet. Das LRZ zählte hierbei zu den ersten Pilotkunden dieses neuen Services des DFN. Auch diese neue Technologie wurde vom LRZ beim DEISA-2 Review in Brüssel vorgestellt und von den Gutachtern mit Begeisterung aufgenommen.

97 Jahresbericht 2009 des Leibniz-Rechenzentrums Evaluierung neuer Middleware-Versionen: GT4.2 und UNICORE 6 In der ersten Hälfte von 2009 leitete das LRZ zusammen mit dem FZJ ein Arbeitspaket zur Evaluierung des Globus Toolkit Version 4.2. Die Test-Installation befand sich auf einer virtuellen Maschine am LRZ. Im darauffolgenden Herbst wurde Globus 4.2 auf dem HLRB-II für den Produktionsbetrieb installiert. Derzeit laufen sowohl die ältere Globus-Version als auch die neue Version parallel auf dem HLRB II, da einige Komponenten dieser neuen Version nicht abwärtskompatibel sind. UNICORE 6 ist die neueste Version der Webservice-basierten, OGSA (Open Grid Service Architecture) konformen UNICORE Middleware. Ab 2010 soll UNICORE6 die bisher in DEISA in Produktion befindliche Version 5 ablösen. Es wurde die neueste Version an verschiedenen DEISA-Sites einschließlich LRZ auf Produktionsreife geprüft. Dazu wurde diese Version am LRZ installiert und verschiedene Tests und Benchmarks durchgeführt (Job Submission Test, Stress Test der Server Komponenten, Messung der Dateitransfergeschwindigkeit, Bewertung der Benutzbarkeit und Stabilität der Benutzerclients und auch der Dokumentation). Die dabei bis Juni 2009 gewonnenen Erkenntnisse flossen in die Weiterentwicklung zur Version ein, die im Oktober für den Produktionseinsatz vorgeschlagen wurde. Bis zum Dezember 2009 wurde UNICORE 6 dann am LRZ produktionsreif installiert. Somit ermöglicht das LRZ ab 2010 DEISA-Benutzern den Zugriff auf die Ressourcen über die neue Middleware UNICORE Remote Visualization Nach ersten Versuchen mit einer Remote-Visualisierungs-Installation in Italien wurden auch die am LRZ dafür zur Verfügung stehenden Maschinen an DEISA angebunden. Hierzu wurde neben der Installation der notwendigen Middleware sowie der Anbindung an die DEISA-Benutzerverwaltung das RVS-System an das DEISA-Dateisystem GPFS angeschlossen. Nach Abschluss der Evaluierungsarbeiten durch das italienische Rechenzentrum CINECA wird dieses System in 2010 auch in DEISA verfügbar gemacht werden. Den europäischen Nutzern wird dadurch ermöglicht, ihre auf einem der DEISA- Höchstleistungsrechner erzeugten Daten nahtlos auf ihrem heimischen PC in Echtzeit zu visualisieren Cloud Computing und Virtualisierung Im September 2009 wurde auf dem DEISA WP4 Meeting in Amsterdam der neue Subtask T4.3c Evaluation of Cloud and Virtualization tools for HPC systems gestartet. Die Führung dieses neuen Subtasks hat das LRZ übernommen. Zusammen mit dem zweiten Partner CINECA wurden dann bis zum Ende des Jahres 2009 Informationen über die verfügbaren Cloud-Softwarelösungen auf dem Markt gesammelt. Auch wurde bereits vorhandenes Cloud-Knowhow des DEISA Partners SARA für die Evaluierung aufbereitet. Durch einen Besuch der CloudComp2009 in München im Rahmen des Subtasks konnten zudem neueste Forschungsergebnisse in die Evaluierung eingebracht werden. Schließlich wurde ein Fragenkatalog zum Thema Cloud-Computing für eine Umfrage unter DEISA-Benutzern erstellt, die im Jahr 2010 wertvolle Informationen liefern soll, welche Schwerpunkte in der weiteren Evaluierung gesetzt werden sollten Work Package 5: Application Enabling Im Rahmen der Application Enabling-Aktivitäten in DEISA wurde ein Fragebogen ausgegeben, der von 10 DEISA-Partnern beantwortet wurde. Die Resultate wurden zusammengefasst und basierend darauf ein Enabling-Arbeitsablauf entwickelt und etabliert. Die HPC-Applikationen der Projekte (vgl. Abschnitt ) SeBaSim, DNS-HiRe, PASICOM, SAPHERE und walberla wurden verbessert. Für die Projekte Musiprol und ScalLB wurde intensive Unterstützung für die Durchführung der Projekte auf verschiedenen DEISA-Ressourcen geleistet Work Package 6: User Support Der Benutzer steht stets im Fokus der LRZ-Aktivitäten; daher beteiligte sich das LRZ an drei Benutzerschulungen in Stuttgart, Neapel und Jülich. LRZ-Mitarbeiter entwickelten die Schulungsunterlagen, schrieben die Handbücher und hielten jeweils die Globus-Vorlesung und -Übung. Nach den positiven Erfahrungen mit dem Operator on Duty in WP3 wurde einige Zeit später auch die Rolle des Helpdesk on Duty eingeführt, die sich um die Koordination und den reibungslosen Ablauf der Benutzerunterstützung kümmern soll. Auch diese Rolle hat das LRZ seitdem mehrfach ausgefüllt.

98 92 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Work Package 7: DEISA Extreme Computing Initiative Die DEISA Extreme Computing Initiative (DECI) soll eine kleine Anzahl von Flaggschiff - Applikationen, die sich mit komplexen, herausfordernden und innovativen Simulationen beschäftigen, die ohne die DEISA-Infrastruktur nicht möglich wären, identifizieren. Ein weiteres Ziel ist es auch, die internationale Zusammenarbeit zwischen den Forschergruppen und Rechenzentren zu fördern. Die Projekte wurden auf Basis ihres Innovationspotentials, ihrer wissenschaftlichen Güte und ihrer Relevanz für das Forschungsgebiet von den lokalen Begutachtungsgremien bewertet und danach vom DEISA Executive Committee einem Ranking unterzogen. In allen beteiligten Rechenzentren wurde eine Application Task Force gebildet, die diese Projekte identifiziert und anschließend die Benutzer bei ihren Projekten unterstützt. Aus dem Bereich des LRZ wurden für die DECI-3 Ausschreibung in 2008 sechs Projektanträge eingereicht und in 2009 beendet. Alle wurden genehmigt und erfolgreich durchgeführt (siehe folgende Tabellen). DECI-3 Projekt Fachgebiet Ausführungsort Budget (std.cpu hrs) DRatchet Informatics, Engineering EuQuake Earth Sci. BSC, FZJ, LRZ, SARA EPCC, FZJ, LRZ / /2009 GravTurb Astro Sci. LRZ, SARA /2009 HHG Informatics EPCC, FZJ, RZG /2009 OxSim Materials Sci. SARA /2009 PHAGEDA Bio Sci. SARA /2009 Abschluss Datum Für die folgenden Projekte ist das LRZ Execution Site, aber nicht Home Site: DECI-3 Projekt Fachgebiet Heimateinrichtung Budget (std.cpu hrs) Einstein2 Astro Sci. FZJ /2010 ELE-poly-LED Materials Sci. CINECA ETISP2 Bio Sci. EPCC GALFOBS Astro Sci. BSC /2009 GEM Physics RZG PINNACLE Physics SARA /2009 SIMUGAL-LU Astro Sci. BSC /2009 VIPACS Bio Sci. EPCC /2009 Abschluss Datum In 2009 wurden zum ersten Mal zwei (statt bisher nur einem) Aufrufe zur Einreichung von DECI- Projekten durchgeführt. Im Rahmen des ersten davon, DECI-4, wurden insgesamt etwa 70 Anträge eingereicht. Über das LRZ wurden vier Anträge weitergereicht, von denen drei genehmigt wurden. DECI-4 Projekt Fachgebiet Ausführungsort Budget (std.cpu hrs) DNS-HiRe Engineering EPCC, IDRIS /2009 Musiprol Bio Sci. CSC, IDRIS /2009 SeBaSim Earth Sci. BSC, LRZ, RZG läuft Abschluss Datum

99 Jahresbericht 2009 des Leibniz-Rechenzentrums 93 Die abgeschlossenen Projekte erzielten sehr gute wissenschaftliche Ergebnisse. Auch in 2009 hat das LRZ dem DEISA-Projekt wieder Rechenzeit in signifikantem Umfang zur Verfügung gestellt. Die folgenden Projekte wurden am LRZ gerechnet: DECI-4 Projekt Fachgebiet Heimateinrichtung Budget (std.cpu hrs) Status BioMolQM Materials Sci. RZG läuft HPQCD Plasma & Particles EPCC /2009 MillCli Earth Sci. CSC SimFuel Materials Sci. RZG läuft Im Rahmen des zweiten Aufrufs in 2009, DECI-5, wurden über das LRZ sechs Anträge gestellt und davon vier genehmigt. DECI-5 Projekt Fachgebiet Ausführungsort Budget (std.cpu hrs) Status PASICOM Earth Sci. IDRIS läuft SAPHERE Earth Sci. BSC, RZG ScalLB Engineering CINECA, EPCC, FZJ läuft walberla Engineering EPCC, FZJ läuft Work Package 8: DEISA Development Environment Die Erweiterung des Eclipse-Frameworks von IBM zur parallelen Programmierung, PTP, wurde untersucht und auf dem HLRB II evaluiert. Dabei traten unter anderem Sicherheitslöcher zutage. Daher wurde eine Re-Implementierung der Security-Komponente vorgenommen Work Package 9: Enhancing Scalability Im Rahmen dieser Aktivität wurde anhand des Quanten-Chromodynamic-Codes BQCD die Skalierbarkeit und Performanz eines Hybrid-Codes untersucht. Dazu wurden mehrere DEISA-Maschinen wie IBM BlueGene/P, CRAY und SGI Altix verwendet DEISA Executive Committee Die Koordinierung der führenden europäischen Höchstleistungsrechenzentren zur gemeinsamen Abwicklung der ehrgeizigen Ziele einer verteilten europäischen Höchstleistungs-Rechnerinfrastruktur erfordert regelmäßige Management-Treffen des DEISA-Exekutivkomitees. Diese fanden als persönliche Treffen, Telefonkonferenzen und Videokonferenzen statt Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) Das derzeit weltgrößte Teilchenphysikexperiment Large Hadron Collider am CERN sollte im Sommer 2008 starten. Ein schwerer Unfall im September 2008 legte den Beschleuniger jedoch für ein Jahr lahm. Nach umfangreichen Reparaturarbeiten wurde er im September 2009 wieder in Betrieb genommen. Erste Messdaten fielen im Dezember 2009 an. Bei den Experimenten der bedeutenden Wissenschaftsprojekte am CERN entstehen gewaltige Mengen an Daten im Petabyte-Bereich. Für die Auswertung wurde von Anfang an auf verteilte Ressourcen gesetzt. Heute sind dafür weltweit hunderte Cluster in einem Grid dem LHC Computing Grid (LCG) vernetzt. Das LRZ betreibt dabei zusammen mit dem MCSC-Partner RZG und den Hochenergiephysikern aus dem

100 94 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Münchner Raum ein Tier-2-Zentrum (siehe Abbildung 50). Speicher- und Rechenknoten des Tier-2 Zentrums wurden im Rechnerwürfel des LRZs installiert. Den Betrieb bis zur Vermittlungsschicht, der Middleware, übernimmt die Gruppe Verteile Ressourcen. Die Middleware und die darüber liegende Experiment-Software wird von den Physikern der LMU betreut. Derzeit stehen am LRZ für die Speicherung der Experimentdaten und Auswertungsergebnissen 627 Terabyte (TB) zur Verfügung. Durch die Absicherung als RAID beträgt die Nettokapazität 483 TB, die über die dcache-speicherverwaltung bereitgestellt werden. Die LCG-Rechenknoten sind in den LRZ-Linux- Cluster integriert. Dadurch können Kapazitätsengpässe bei einem Projekt umgangen und alle Ressourcen besser ausgelastet werden. Im Moment verwaltet das LRZ LCG-Rechenknoten mit 1180 Cores. Als neuen Service stellt das LRZ dem LCG-Projekt virtuelle Maschinen zur Verfügung. Dabei werden die speziellen LCG-Anforderungen etwa bezüglich des Betriebssystems Scientific Linux unterstützt. Die Überwachungsinfrastruktur am LRZ wurde entsprechend angepasst. Abbildung 50 Tier-Struktur des LHC Computing Grids. Abbildung 51 Ein Blick in den Large Hadron Collider am CERN, dessen Daten auch am LRZ ausgewertet werden. (Ref: https://lhc2008.web.cern.ch/lhc2008/index.html)

101 Jahresbericht 2009 des Leibniz-Rechenzentrums LRZ-Projekt Eclipse4Grid Das interne LRZ-Projekt Eclipse4Grid hat sich zum Ziel gesetzt, das Software-Entwicklungs- Framework Eclipse von IBM für Grid-Anwendungen geeignet zu erweitern. In Kooperation mit dem DEISA-Arbeitspaket 8 wurde die Erweiterung PTP untersucht. Darüber hinaus wurden die Erweiterungen unter die Lupe genommen, die im Rahmen des geclipse-projekts entstanden sind. Unterstützung erhielt das LRZ dabei von den Entwicklern des glogin-tools, das eine Komponente von geclipse darstellt. Dabei wurden einige Fehler repariert und glogin auf einigen Testmaschinen installiert. Des Weiteren wurde PTP auf dem Linux-Cluster installiert, um die Eignung für das LRZ-System zu prüfen. Zusammen mit dem ISAR-Projekt ist ein PTP Workshop für 2010 geplant Cloud-Computing Während beim Grid-Computing der Hauptaspekt die föderale Nutzung von auf die Partner verteilten Ressourcen ist, richtet sich das Cloud-Computing vornehmlich auf die Virtualisierung von Ressourcen. Diese Ressourcen sind nicht mehr unbedingt weiträumig verteilt sondern oft bei einem kommerziellen Anbieter geclustert. So bieten Amazon, Google, aber auch die Deutsche Telekom Cloud Ressourcen gegen Entgelt an. Da dem Benutzer jeweils virtuelle Maschinen unter verschiedenen (Linux) Betriebssystemen angeboten werden, ist die genaue Beschaffenheit der zugrundeliegenden Hardware nur mehr zweitrangig. Durch die Virtualisierung wird auch der beim Nutzer ansonsten oft erhebliche Portierungsaufwand drastisch verringert idealerweise bis auf null, denn der Benutzer kann ein ihm genehmes Betriebssystem auswählen. Im Rahmen des AK-Grid haben die Mitglieder verschiedene Cloud-Computing Anbieter getestet und in Vorträgen die Ergebnisse einander vorgestellt. So wurde die Elastic Computing Cloud (ECC) von Amazon auf Ihre Eignung für das LCG getestet: prinzipiell ist die ECC dafür geeignet, jedoch sind derzeit die auf echter Hardware basierten Tier-2 Zentren (von denen eines auch am LRZ betrieben wird, siehe Abschnitt 2.8.3) noch deutlich kostengünstiger, als das Cloud-Computing bei Amazon. Es wurden auch Experimente mit den Angeboten von Google und der Telekom vorgeführt. Der AK verfolgte auch Bestrebungen der Open Cloud Computing Interface working group des OGF um die derzeit noch proprietären Interfaces der verschiedenen kommerziellen Anbieter zu vereinheitlichen und deren Clouds interoperabel zu machen. Die freien Pakete NIMBUS und OpenNebula zum Aufbau einer Cloud wurden praktisch untersucht, jedoch sind beide noch nicht reif für den Produktionseinsatz. Im nächsten Jahr soll am LRZ prototypisch eine Cloud aufgesetzt und ausgewählten Benutzern zum Test angeboten werden Projektanträge 7. EU-Forschungsrahmenprogramm e-infrastrukturen Für die Ausschreibung FP7-INFRASTRUCTURES des 7. Forschungs-Rahmenprogramms der EU initiierte oder beteiligte sich das LRZ an vielen Projekten. Die Projekte mit Beteiligung der Gruppe VER werden im Folgenden näher beschreiben. Eine Entscheidung über die Genehmigung dieser Projekte fällt voraussichtlich im Frühjahr Initiative for Globus in Europe (IGE) Die Gruppe VER initiierte das Proposal Initiative for Globus in Europe (IGE), um die Belange der europäischen Benutzer stärker in dieser führenden Grid- Middleware zu repräsentieren. Dazu integriert IGE zehn europäische Partner sowie die University of Chicago, die die zentrale Globus Codebasis pflegt. IGE will hauptsächlich koordinierend eingreifen und die europäischen Wünsche bündeln und abstimmen, um sie dann mit einer gewichtigen Stimme gegenüber den anderen Globus-

102 96 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme Entwicklern vorzutragen. Dazu sind ein zentrales europäisches Repository (http://www.ige-project.eu), eine jährliche Globus Europe Konferenz, sowie ein europäisches Globus User Forum vorgesehen. Ein Arbeitspaket beschäftigt sich auch mit Code-Entwicklungen, um die Lücken zu füllen und notwendige Anpassungen an europäische Belange durchzuführen. Durch IGE soll Globus, das sich in Europa einer breiten Benutzerschaft erfreut, bisher aber keine europäische Lobby hatte, in die europäischen Grid-Projekte, allen voran die European Grid Initiative (EGI), getragen werden. Durch Zentralisierung von Funktionen wie Test, Zertifizierung, Training, Support, etc., bei IGE kann Europa durch Synergieeffekte den Aufwand verringern und den Service für die Benutzer verbessern e-infrastructure Sustainable Software Study (eis-cube) Ein weiterer Projektvorschlag, welcher vom LRZ im Rahmen derselben Ausschreibung initiiert und koordiniert wurde, behandelt die wachsenden Bedürfnisse sowohl der unterschiedlichen wissenschaftlichen Communities wie auch der Entscheidungsträger auf nationaler und europäischer Ebene, die aktuellen Technologien und Ressourcen im Bereich des verteilten Rechnens zu überblicken und dessen Verfügbarkeit und Bekanntheitsgrad zu steigern. Dabei werden Hochleistungsrechner (High-Performance- Computing) und durchsatzstarke verteilte Ressourcen (High-Throughput-Computing), führende und regionale Zentren (Tier 0 bis 2) und Gruppen einheitlich betrachtet. Die Projektarbeiten sollen auf der Basis von Grid-Technologie in Zusammenarbeit mit einflussreichen Organisationen in den Grid-Communities, wie OGF, EGI u.a., aufgebaut werden Beteiligung an Projektanträgen anderer Gruppen oder Institutionen Zusätzlich zu den beiden vom LRZ initiierten Projekten war die Gruppe Verteilte Ressourcen an den folgenden EU-Projektanträgen im FP7-Call beteiligt: - Scalable Visualization Infrastructure (SCAVIN, Konsortialführung LRZ, Gruppe HLR) - European Grid Initiative: Integrated Sustainable Pan-European Infrastructure for Researchers in Europe (EGI-InSPIRE, Konsortialführung EGI.eu, Amsterdam) - Partnership for Advanced Computing in Europe - First Implementation Phase Project (PRACE- 1IP (Konsortialführung FZ Jülich) - Virtual Earthquake and Seismology Research Community in Europe (VERCE, Konsortialführung CNRS-INSU, Paris) - Intelligent Application-Oriented Scheduling Framework (IANOS, ATOS Origin Spanien) - Multiscale Applications on European e-infrastructures (MAPPER, Universität Amsterdam) - Distributed Research Infrastructure for Hydro-Meteorology (DRIHM, Universität Genua) Betrieb der Grid-Infrastruktur Der Regelbetrieb der Grid-Dienste wurde durch die Mitarbeiter der Gruppe Verteilte Ressourcen betreut und ausgebaut. Derzeit betreut die Gruppe etwa 40 Server, auf denen ca. 25 Dienste in Produktionsund Testbetrieb laufen. Bei den seit Anfang 2009 in Produktion befindlichen Systemen lag die Verfügbarkeitsquote bei %. Um die Ausfallsicherheit der Dienste weiter zu erhöhen, wurde damit begonnen, sie von physikalischer Hardware auf virtuelle Maschinen aus dem LRZ VMware-Pool zu migrieren. Außerdem wurde die automatische Überwachung der Maschinen und Dienste deutlich erweitert, sowie regelmäßige Kernel-Updates und Security-Checks durchgeführt. Außerdem wurden vorbereitende Maßnahmen eingeleitet, um das Service-Management in Richtung einer ISO/IEC Konformität voranzutreiben. Ein wichtiger Meilenstein ist die Inbetriebnahme der Grid User Administration 2 (GUA2) und deren Kopplung mit dem lokalen Benutzerverwaltungssystem LRZ-SIM. Dies erleichtert und beschleunigt die Verwaltung der Grid-Benutzer erheblich. GUA2 wurde an die Erfordernisse von D-Grid angepasst. Dazu wurde ein neuer Adapter geschrieben, der nun automatisch die D-Grid-weit zentral verwalteten Benutzerkonten der etwa 27 virtuellen Organisationen in die LRZ Benutzerdatenbank LRZ-SIM einträgt. Mittlerweile verwalten wir Grid-Accounts (im Vorjahr waren es 750). Die LRZ Grid Registration Authority wurde ermächtigt, auch die Rolle der Grid Registration Authority der LMU, der TUM und der Universität der Bundeswehr zu übernehmen. Dadurch konnten nicht nur die

103 Jahresbericht 2009 des Leibniz-Rechenzentrums 97 Mitarbeiter der drei großen Münchner Universitäten bei der Grid-Nutzung unterstützt werden, sondern es konnten auch für die Informatikvorlesungen an der LMU und der TUM DFN-policy-konforme Grid- Services (Zertifikate, Globus, UNICORE, etc.) für vorlesungsbegleitende Übungen für Studenten bereitgestellt werden. Insgesamt wurden in User- und 64 Server-Zertifikate erstellt Sonstige Grid-Aktivitäten Im Rahmen einer LRZ Einführungsveranstaltung zur Remote Visualisierung wurde der sichere und einfache Zugang mittels GSI-SSH, der auf X.509-Zertifikaten basierenden Version der allseits bekannten ssh, vorgestellt und in praktischen Übungen eingeübt. Auf der International Supercomputer Conference (ISC09) in Hamburg und auf der SuperComputing 2009 (SC09) in Portland führte die Gruppe VER eine Grid-Demonstration vor. Die vom MPI für Astrophysik in Garching entwickelte Workflow Software Planck Process Coordinator sendet über Globus Grid Middleware Rechenjobs an Ressourcen im Grid. Dort werden aus den astrophysikalischen Daten Bilder von Galaxienkollisionen berechnet, die anschließend zu einem Film zusammengefügt werden. Im Film kann der Wissenschaftler nun die Dynamik dieser kosmischen Ereignisse studieren und die Simulationen mit den Aufnahmen realer Galaxien vergleichen. Alle Mitglieder der Gruppe VER wurden nach ISO/IEC zertifiziert, die internen Arbeitsabläufe und die Arbeitsverteilung wurden reorganisiert und die Arbeitszeitabrechnung wurde auf die aktuellen FP7-Richtlinien der EU angepasst. Und last but not least wurde unser LRZ-Grid-Portal (http://www.grid.lrz.de/), mit dem sich das LRZ seinen Kunden im Grid-Bereich präsentiert, regelmäßig aktualisiert und entwickelte sich zu einem festen Anlaufpunkt für wichtige Informationen aus dem Grid-Umfeld für Benutzer aus der ganzen Welt.

104

105 Jahresbericht 2009 des Leibniz-Rechenzentrums 99 3 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes 3.1 Betrieb des Kommunikationsnetzes Das Münchner Wissenschaftsnetz (MWN) verbindet vor allem Standorte der Ludwig-Maximilians- Universität München (LMU), der Technischen Universität München (TUM), der Bayerischen Akademie der Wissenschaften (BAdW), der Hochschule München (HM) und der Fachhochschule Weihenstephan miteinander. Es wird aber auch von anderen wissenschaftlichen Einrichtungen (u. a. Max-Planck- Gesellschaft, Fraunhofer-Gesellschaft, Kunst-Hochschulen, Museen) mit genutzt. Diese Standorte sind insbesondere über die gesamte Münchner Region (i. W. Münchner Stadtgebiet, Garching, Großhadern/Martinsried und Weihenstephan) verteilt, es gibt aber auch weitere Standorte in Bayern. Derzeit sind an das MWN mehr als 60 Standorte mit mehr als 440 Gebäuden angebunden (siehe Abbildung 52) und es werden mehr als Systeme versorgt. Die Lage von Standorten, die außerhalb des Münchner Stadtgebietes liegen, ist in der Abbildung nicht maßstabsgetreu dargestellt, sondern lediglich schematisch (Himmelsrichtung) angedeutet. Die Größe der zu versorgenden Areale ist sehr unterschiedlich; sie reicht von einem einzelnen Gebäude bis zu einem gesamten Campusbereich (z. B. Garching und Weihenstephan) mit mehr als 30 Gebäuden und mehr als angeschlossenen Endgeräten. QR Triesdorf YX JU Legende : Anschluss >= 10 MBit/s Q (10 MBit/s - 10 GBit/s) YE Anschluss < 10 MBit/s (Funk, xdsl, 2 MBit/s oder 64 kbit/s) Ingolstadt Weihenstephan Versuchsgüter JT JG JV P JZ JS Q Straubing Stand : Oberschleißheim VM Freising A, W AI Garching 8 V 471 YZ Augsburg 471 YR Dachau YS Fürstenfeldbruck 2 ZS Eichenau 8 AUBING Bo d ensee Str. PASING IN Pip ping er Str. RP IM b usch Str. Evers ALLACH OBERMENZING ZY ZM 96 Verdistr. Landsberg er Str. Würmtalstr. IG Martinsried I NYMPHEN YB - YK BURG LAIM 95 Fürsten- ried er Str. RAMERS- DORF FELD- MOCHING MOOSACH Da chau er Str. Arnulf Str. RIED Wolfratsha userstr. LERCHENAU Lerch enau er Str. YE Lindwurmstr. Leo p oldst r.in g olstä dter Str. YL S chleiß ZR SCHWABIN YC h YN YQ eime G L SH ZN LLrs tr. SM S G YF NEUHSN D YA SB N O RA B. MK RE YW RW H ZA K TG SENDLING SOLLN Fra unh oferstr. YU XE XG ZK Rosenh e eim HAIDHSN ZX Ung erer Str. Ob erföhring er Str. r Str. 9 YY FREIMANN Z1 ZJ Kreiller Str. MILBERTS- HOFEN BOGEN- HAUSEN FORSTEN- 94 Putzbrunner Str Wasserburg er Landstr Z2 Iffeldorf XS Zugspitze YO Obernach Wendelstein ZL Abbildung 52 Lage der Standorte im MWN Die Areale des MWN werden zu Dokumentationszwecken auch mit Kürzeln aus 1 oder 2 Zeichen (Unterbezirke) benannt.

106 100 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Münchner Wissenschaftsnetz Teil 1 TUM Eichenau SWH Karlstr. 32 LMU Bad Tölz TUM Thalhausen SWH Vöttinger Str. SWH Lange Point TUM Hirschau LMU Ziemssenstr. LMU Giselastr. LMU Menzinger Str. LMU Maria- Theresia Str. LMU Scheinerstr.1 TUM,LMU Luisenstr. FW ZS FH YH JT P8 PY JH YB TUM ZY Schragenhofstr. ZJ LMU V Oberschleißheim SWH Schäferanger Oberschleißheim T SG YW VW F FO JV SWH Giggenhauser- Str. 25 und 29 P0 SWH SWH Richard-Wagnerstr.16 Gabelsbergerstr. TUM, FH Campus Weihenstephan LMU Konradstr. LL LMU Moorversuchsgut Oberschleißheim ZO SWH Arcisstr.31 TUM Veitshof Weihenstephan T-DSL P1 LMU Zentnerstr.31 VM ZK SWH Preysingstr. 83d Z0 SWH IZB Freising Q,P,J LMU Oettingenstr. ZT JI O FHW Triesdorf SAT LF SWH Franz- Josef Str.4 TUM Mühlenweg Freising ZV JF SWH Steinickeweg 4 YA SWH TUM Chiemgaustr. Schellingstr.33 JR FS D XB P3 JS TUM Scheyern JZ TUM Zurnhausen TUM B Stamm/Nordgelände ZN SWH Paulinum TUM Wasserbau Obernach ORD Maxburgstr.2 LRZ WL,WR,WZ Boltzmannstraße 1 FHG IVV Giggenhauser Str. HMTM Arcisstr. LMU Meiserstr.10 FE BJ LMU SWH Theresienstr. Jakob Balde Haus X-WIN INTERNET YO ZL FZ ZU TUM Barer Str.21 LMU Klinikum Großhadern SR XS UFS Zugspitze I YC TUM Biederstein SB SWH Sauerbruchstr. IK LMU Chemie u. Pharmazie Großhadern IS Staatsbib. Ludwigstr.16 SP IN MPG Neurobiologie K SWH Heiglhofstr. H IT zu A,W,M zu A,W,M MPG IM Biochemie SWH Stettenkas. Schwere Reiter SWH Str.35 Hedwig- Dransfeld-Allee DP SWH Hist. Kolleg KWK Kaulbachstr.15 Kaulbachstr.29 SWH Schröfelhofstr. LMU Wendelstein 120 Kanäle M-net Modem/ISDN-Zugang 60 Kanäle Telekom TUM Klinikum r.d.isar ZQ TUM Pin.d.Mod. Barer Str.40 LMU Bio I Bio II Martinsried N LMU Veterinärstr. BAdW MPG Hofgartenstr. Alfons-Goppel-Str. SW HM Lothstr.34 SWH Kaulbach- Str.25 HP Y7 IG R YV JU Z2 YS Fernsprechnetz/ ISDN IW IA zu G,S zu G,S Z5 IL ZA ZK NK SY YF ZH Z4 Z8 Z3 TUM/FHW Straubing TUM Iffeldorf LMU FFB TUM Wasserchemie LMU Genzentrum Stift.FH Preysingstr.83 LMU Kaulbachstr.37 HS Philosophie Kaulbachstr.31 TUM Lothstr.17 Herzzentrum Lazarettstr. SWH Kreittmayrstr. SWH Nymphen- burger Str. zu YP SWH Lothstr.62 ZE SWH SWH SWH Span.Kolleg Adelheidstr. Heßstr. Dachauer Str. Hochschule Wiss. Einrichtung Studentenwohnheim/ sonstige Einrichtung 10 Gbit/s Glasfaser 1 Gbit/s Glasfaser Mbit/s Mbit/s Glasfaser 2 Mbit/s 64 Kbit/s 256Kbit/s-16Mbit/s Mbit/s DSL Funk/Laser Stand: /Kantor

107 Jahresbericht 2009 des Leibniz-Rechenzentrums 101 Münchner Wissenschaftsnetz Teil 2 MPG Garching AI SWH WW Maschinenwesen zu X-Win, Internet SWH Garching 2 A5 TUM,LMU Campus Garching A,W,M WJ SWH SLC WH A9 SWH Hochschulhaus Garching SWH Jochbergweg LMU Leopoldstr.13 L MPG Föhringer Ring YY Z1 SWH Freimann SWH CVJM Theo-Prosel- Weg TUM Baumbachstr. KUMI Salvatorstr. LMU Martiusstr. TUM Ini.tum Ingolstadt LMU Seestr.13 SWH Albertus Magnus Haus Pasing LMU IFO Poschingerstr.5 TUM IWB Augsburg TUM Connollystr. SWH Helene Mayer Ring SWH Moosacher Str.81 zu R zu LRZ zu I YD zu B ZM XK YL YP TUM Schwabinger Krankenhaus SM YX SH Y8 XF YZ XM TUM Excellenz-Cl. Y6 YN WK YQ LMU Leopold Str.139 ZR SWH Domino WD TUM Winzererstr. IBZ Amalien str.38 Z9 G2 ZF XG HMTM Gasteig WO WG GATE Garching LMU/TUM Deutsches Museum YU WM LMU G,S Business Campus Parkring 4 ITEM Garching Geschwister-Scholl- Platz Stammgelände M-net (Internet-Backup) YM XR XE LMU Infanteriestr. LP ISB Schellingstr.155 SWH Georgen- Str. 14 LMU Edmund- Rumplerstr.13 LMU Edmund- Rumplerstr.9 ZX SWH Felsennelkenanger SWH Kieferngarten Z7 INTERNET XU YT ZG XJ GU XQ GI YJ SI Z6 Y9 Y0 ZC ZI ZW ZZ SWH Josef-Wirth- Weg 19 SWH Paul-Hindemith- Allee LMU Amalienstr.17 HFF Frankenthalerstr. SWH Heinrich- Groh-Str.17 SWH Biedersteiner- Straße 24-30a SWH Oskar v. Miller Ring 25/ Amalien 13 MPG Amalienstr.33 ABK Akademiestr. SWH Kaulbachstr.49 LMU Prinzregentenstr.7 SWH Geschwister- Scholl Steinickeweg 7 SWH Arme Schul- Schwestern Unterer Anger 2 SWH Arme Schul- Schwestern Unterer Anger 17 IHF Prinzregentenstr.24 TUM u. Museen Oettingenstr.15 GN YI LH SE XA YR ZP FV JG LMU Amalienstr.83 LMU Schwere Reiter Str.9 LMU Hohenstaufenstr.1 LMU Ludwigstr.10 TUM Augustenstr.44 TUM Dachau Karl Benz Straße 15 Bay.Theat.Ak. Prinzregenten- Platz 12 BAdW Volkskunde Barer Str.13 TUM Grünschwaige Hochschule Wiss. Einrichtung Studentenwohnheim/ sonstige Einrichtung 10 Gbit/s 1 Gbit/s Glasfaser Glasfaser Mbit/s Mbit/s Glasfaser 2 Mbit/s 64 Kbit/s 256Kbit/s-16Mbit/s Mbit/s DSL Funk/Laser Stand: /Kantor

108 102 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Das LRZ ist für das gesamte Backbone-Netz und einen Großteil der angeschlossenen Institutsnetze zuständig. Eine Ausnahme bilden die internen Netze der Medizinischen Fakultäten der Münchner Universitäten (u. a. Rechts der Isar (TUM), Großhadern und Innenstadt-Kliniken (LMU)) sowie der Informatik der TUM. Sie werden von den jeweiligen Rechenzentren der Fakultäten selbst betrieben und betreut. Das LRZ ist jedoch für die Anbindung dieser Netze an das MWN zuständig. Das MWN ist mehrstufig realisiert: Das Backbone-Netz verbindet mittels Routern die einzelnen (Hochschul-)Standorte (Areale) und Gebäude innerhalb der Areale. Innerhalb eines Gebäudes dient das Gebäudenetz mittels Switches zur Verbindung der einzelnen Rechner und der Bildung von Institutsnetzen. Eine Sonderstellung nimmt das Rechenzentrumsnetz ein, das die zentralen Rechner im Rechnerwürfel des LRZ miteinander verbindet. Etwas genauer lässt sich diese Realisierung wie folgt beschreiben: Die Router werden über das Backbone-Netz miteinander verbunden und bilden den inneren Kern des MWN. Die Verbindungsstrecken des Backbone-Netzes sind je nach Nutzungsgrad verschieden ausgeführt. Im Normalfall sind die Strecken Glasfaserverbindungen, die langfristig von der Deutschen Telekom und M-net angemietet sind. Auf den Glasfaserstrecken wird mit 10 Gbit/s übertragen. Die Verbindung der Strecken übernehmen fünf Backbone-Router, die untereinander aus Redundanzgründen ein Dreieck bilden. Netze mit einer geringen Zahl von Endgeräten werden, überwiegend mit SDSL-Verbindungen (bis zu 10 Mbit/s) von M-net oder WLAN- Verbindungen auf Basis von IEEE a oder g (bis 54 Mbit/s), vereinzelt aber auch noch mit 64 kbit/s-verbindungen der Telekom angebunden. Die Switches eines Gebäudes oder einer Gebäudegruppe werden mittels Glasfaser zum allergrößten Teil mit 1 Gbit/s, aber auch mit 10 Gbit/s an die Router herangeführt. In den Gebäuden geschieht die Anbindung von Datenendgeräten über Ethernet. Die Anbindung wird entweder über Twisted-Pair -Kupferkabel (100/1000 Mbit/s) und Lichtwellenleiter (100 Mbit/s oder zum Teil 1 Gbit/s) oder zu einem sehr geringen Teil noch über Koaxial-Kabel (10 Mbit/s) realisiert. Server-Rechner werden fast immer mit 1 Gbit/s angeschlossen. Die zentralen Rechner im LRZ (der Bundeshöchstleistungsrechner HLRB II, die Linux-Cluster, die Server des Backup- und Archivsystems und die zahlreichen Server-Systeme) sind untereinander größtenteils mit 10 Gbit/s mittels Switches verbunden. Diese Netzstruktur der zentralen Rechner ist über einen Router (10 Gbit/s) mit dem MWN-Backbone verbunden. Im MWN wird ausschließlich das Protokoll TCP/IP benutzt. Die folgenden Abbildungen zeigen die für das Backbone-Netz verwendeten Strecken, deren Übertragungsgeschwindigkeiten und Endpunkte. Hieraus lässt sich die Ausdehnung des Netzes ablesen Backbone-Netz Das Backbone des Münchner Wissenschaftsnetzes, bestehend aus Routern und Glasfaserstrecken, zeigt Abbildung 53. Aus der Abbildung ist die Struktur des Backbone ersichtlich. Den Kern des Backbones bilden Cisco Catalyst 6509 Switch/Router, die untereinander mit 10 GBit/s verbunden sind. Die Anbindung der Standorte erfolgt über LWL (Lichtwellenleiter). Das LRZ selbst ist über einen virtuellen Router (bestehend aus zwei 6509) an das Backbone angebunden. Alle Telekom-Glasfasern enden im zentralen Netzraum des TUM-Stammgeländes. Die M-net Glasfasern enden im zentralen Netzraum des LMU-Stammgeländes. Das Router-Backbone bildet mehrere Zyklen, die der Redundanz dienen. Bis auf die Router in Weihenstephan und an der Hochschule München haben alle eine mindestens doppelte Anbindung an das Backbone. Die Router unterhalten sich über Punkt-zu-Punkt Verbindungen mittels OSPF (Open Shortest Path First). Der Verkehr fließt von der Quelle zum Ziel über die Leitungen mit der kleinsten Hop -Anzahl (Weg, der über die wenigsten Router führt).

109 Jahresbericht 2009 des Leibniz-Rechenzentrums 103 Abbildung 53 Das Backbone des Münchner Wissenschaftsnetzes Ausnahmen zu dieser generellen Regel bildet der über Policy-Based-Routing geführte Verkehr, der in einem eigenen VLAN (Virtuell LAN) fließt und spezielle VLANs, die über das gesamte MWN gezogen wurden. Dies ist nötig, um die besonderen Anforderungen von MWN-Mitnutzern (MPG-Institute, Staatsbibliothek, ) zu erfüllen. Auch die Internet-Anbindung ist redundant ausgelegt. Es gibt zwei Anbindungen an das X-WiN und eine an M-net. Dabei ist die Hierarchie so gewählt, dass die höchste Priorität die Internet-Anbindung 1 (siehe Abbildung 53) hat. Fällt diese aus, wird zur Internet-Anbindung 2 gewechselt. Erst wenn diese auch ausfällt, wird der Weg über M-net gewählt. Die Umschaltung zwischen den Internet-Anbindungen wird automatisch über Routing-Protokolle gesteuert Gebäude-Netze In den Gebäuden existiert grundsätzlich eine strukturierte Verkabelung bestehend aus Kupferkabeln (Kategorie 5/6, TP) oder Multimode-Lichtwellenleiter-Kabeln (50/125µ). Zu einem sehr geringen Anteil ist jedoch in sehr wenigen, noch zu sanierenden Gebäuden, immer noch Ethernet-Koax-Kabel (yellow cable) verlegt, wobei sich aufgrund von Sanierungsmaßnahmen der Umfang in diesem Jahr weiter verringert hat. Als aktive Komponenten zur Verbindung mit den Endgeräten werden (Layer2-)Switches eingesetzt. Ende 2008 wurde eine Switch-Auswahl durchgeführt, bei der Switches der Firma HP Procurve gewonnen haben, da diese für die Anforderungen im MWN am besten geeignet sind. Derzeit sind vor allem Switches der Serien HP ProCurve 4200 und 5400 im Einsatz. Andere stackable HP-Switches vom Typ HP ProCurve 2610 sind in kleineren Netzanschlussbereichen, vom Typ HP ProCurve 2910 für Serveranschlüsse bei Instituten und im Rechnerwürfel des LRZ in Betrieb. Verstärkt wurden in 2009 HP ProCurve-Switches der Serie 5400 aufgebaut. Kennzeichen dieser Netzkomponenten sind 10GE und anspruchsvolle Features wie QoS und Meshing. Alle diese Geräte sind modular aufgebaut und bieten über einzubauende Schnittstellenkarten Anschluss von bis zu 288 Geräten. Die Switches der Klasse 4000M und 2524 sind die derzeit ältesten Komponenten. Da eine Beschaffung dieser Geräte über HP nicht mehr möglich ist ( End of

110 104 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Life ), wurde 2009 begonnen, diese Switches durch neuere Modelle zu ersetzen. Dies wird im Jahr 2010 fortgesetzt. Um den gesteigerten Bandbreitenbedarf für die interne Vernetzung des Linux-Clusters realisieren zu können wurde 2008 ein Switch gesucht, der in einem Chassis mit einer (redundanten) Switching-Fabric in der Lage ist, möglichst viele 10 GE Ports zu unterstützen. Diese Anforderungen wurden am besten von einem Cisco-Switch vom Typ Nexus 7000 erfüllt, der Ende 2008 beschafft und 2009 in Betrieb genommen wurde und derzeit GE-Anschlüsse realisiert. Im Endausbau sind bis zu GE-Anschlüsse in einem Chassis möglich. Zum Jahresende 2009 wurden vom LRZ insgesamt 990 Switches betrieben. Einen Vergleich zu den Vorjahren zeigt Tabelle 21: Ende 2009 Ende 2008 Ende 2007 Ende 2006 Ende 2005 Anzahl Switches davon HP-Switches davon Cisco-Switches davon 3Com-Switches Anzahl TP-Ports Anzahl Glasfaser-Ports Tabelle 21: Switches im Jahresvergleich Die Verteilung nach Switchtypen ist im Teil über die maschinelle Ausstattung des LRZ zu finden Rahmenvertrag für die Beschaffung von Switches Für die Beschaffung von Switches der Firma HP bestand bereits seit Jahren ein Rahmenvertrag, der den Bezug dieser Komponenten zu besonders günstigen Konditionen über die Firma Microstaxx vorsah. Im Jahre 2009 musste dieser Vertrag erneuert werden. Im Rahmen einer europaweiten Ausschreibung, an der sich etwa ein Dutzend Lieferanten beteiligten, erhielt die Firma Microstaxx wieder den Zuschlag. Im April wurde schließlich der neue Rahmenvertrag unterzeichnet, an dem sich neben dem LRZ auch andere bayerische Hochschulen beteiligen. Diesen wird damit die Möglichkeit gegeben, auch die günstigen Konditionen, die der Vertrag bietet, zu nutzen. Zusätzlich zu dem alten Vertrag beinhaltet der neue auch die nach der Übernahme der Firma Colubris durch HP neu hinzugekommene Produktpalette an Wireless- Komponenten (Access-Points, WLAN-Controller usw.) Wellenlängenmultiplexer Das LRZ setzt seit 1997 Wellenlängenmultiplexer (Wavelength-Division-Multiplexer, WDM) auf den angemieteten Glasfaserleitungen der lokalen Provider (Telekom und M-net) ein. Hierdurch lassen sich auf Leitungsebene getrennte Strukturen aufbauen. WDM-Systeme werden derzeit im MWN dazu verwendet, um die verfügbaren Glasfaserleitungen parallel zum Produktionsnetz für folgende Dienste zu nutzen: Kopplung von Nebenstellenanlagen (TK-Kopplung) Realisierung von standortübergreifenden Intranets (z.b. Medizin, Verwaltung) Realisierung von Testnetzen parallel (Fiber-Channel-Kopplung von Speichernetzen usw.) Im MWN werden aktuell auf 13 Verbindungen WDM-Systeme eingesetzt WLAN (Wireless LAN) Die seit dem Jahr 2000 eingerichteten Zugangsmöglichkeiten über WLAN wurden 2009 weiter ausgebaut. Ende Dezember 2009 waren 1324 (Vorjahr 1065) WLAN Accesspoints in 221 (199) Gebäuden installiert. Die Accesspoints sind vor allem in öffentlichen Bereichen wie Hörsälen, Seminarräumen, Bib-

111 Jahresbericht 2009 des Leibniz-Rechenzentrums 105 liotheken und Foyers installiert. Das Angebot erfreut sich steigender Beliebtheit, zeitweise waren mehr als 3000 gleichzeitige aktive Verbindungen aufgebaut. Insgesamt wurden über verschiedene Geräte (MAC-Adressen) registriert, dabei am Tag über Die am stärksten frequentierten Accesspoints waren mit bis zu 93 gleichzeitigen Verbindungen belegt (siehe Abbildung 54 und Abbildung 55). Abbildung 54 Anzahl aktiver WLAN-Verbindungen (5-Minuten-Mittel) Abbildung 55 Entwicklung der Belegung über das Jahr 2009 (Tagesmittel) In den Bildern zeigt der blaue bzw. dunklere Bereich den Anteil von Verbindungen mit IEEE g (54 Mbit/s). Als Zugangskomponenten werden Accesspoints der Typen CN320 (HP MSM 310), CN330 (HP MSM 320) und MAP625 (HP MSM 422) der Firma Colubris (jetzt HP) eingesetzt. Mit den MAP625 werden auch Verbindungen mit IEEE n im 5GHz-Band angeboten, mit denen Geschwindigkeiten bis zu 300Mbit/s erreicht werden können. Im Laufe des Jahre 2009 wurden folgende Bereiche neu mit WLAN ausgestattet: Hochschule für Philosophie LMU Edmund-Rumpler-Str. 13 LMU Martinsried Mensa LMU Oettingenstraße 67 Baracke Musikhochschule Barer Str. 34 Musikhochschule Gasteig Olympisches Dorf Mensa TUM Gabelsberger Str. 45 TUM Gabelsberger Str. 49 TUM Garching Exzellenzcluster Universe

112 106 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes TUM Klinikum rechts der Isar Hörsäle TUM Klinikum rechts der Isar Lern- und Trainingszentrum TUM Schellingstraße 33 TUM Versuchsgut Grünschwaige TUM Winzerer Str. 45 TUM Wissenschaftszentrum Straubing Folgende Areale waren Ende des Jahres 2009 mit WLAN versorgt: (nur zum geringen Teil flächendeckend): Akademie der bildenden Künste Musikhochschule Luisenstr. 37a Bayerische Akademie der Wissenschaften Olympisches Dorf Mensa Bayerische Forschungsstiftung, Prinzregentenstr. 7 Pinakotheken Freifläche Nord Deutsches Museum Stiftung Arbeitsrecht, Infanteriestr. 8 Exzellenzcluster Universe TUM Barer Str. 21 HM Dachauer Str. 98 TUM Deutsches Museum HM Heßstr. Gebäude R TUM Eichenau HM Infanteriestr. 14 TUM Gabelsberger Str. 45 HM Karlstr. 6 TUM Garching Chemiegebäude HM Lothstr. 13 Mensa und Bibliothek TUM Garching Exzellenzcluster Universe HM Lothstr. 21 TUM Garching Maschinenbau HM Lothstr. 34 TUM Garching Medizintechnik HM Pasing, Am Stadtpark 20 TUM Garching Mensa HM Weihenstephan Geb. 172 TUM Garching Physikdepartment Hochschule für Philosophie TUM Garching Physikdepartment II FH Weihenstephan Bibliothek TUM Garching Physikdep. E18 Neutronenhütte FH Weihenstephan Bioinformatik, Altes Bauamt TUM Garch. Umformtechnik und Gießereiwesen FH Weihenstephan Forstwirtschaft TUM Garching Wassergütewirtschaft FH Weihenstephan Landpflege, Kustermannhalle TUM Iffeldorf Limnologische Station FH Weihenstephan Löwentorgebäude TUM Katholische Hochschulgemeinde FH Weihenstephan Pappelallee TUM Klinikum rechts der Isar FH Weihenstephan Triesdorf TUM Klinikum rechts der Isar Hörsäle FH Weihenstephan Geb. 176 TUM Klin. r. d. Isar Lern- und Trainingszentrum Internat. Begegnungszentrum, Amalienstr. 38 TUM Lothstraße 17 LRZ Garching TUM Mensa LMU Akademiestr. 1 TUM Nordgelände N1 LMU Amalienstr. 17 TUM Nordgelände N4 LMU Amalienstr. 54 TUM Nordgelände N5 LMU Amalienstr. 83 TUM Nordgelände N8 LMU Edmund Rumpler Str. 9 TUM Nymphenburger Str. 39 LMU Edmund-Rumpler-Str. 13 TUM Obernach Versuchsanstalt für Wasserbau LMU Frauenlobstr. 7a TUM Pasing Grundbau und Bodenmechanik LMU Garching, Beschleuniger-Laboratorium TUM Richard-Wagner Str. 18 LMU Garching, Physik-Dep. Coulombwall TUM Schellingstraße 33 LMU Georgenstr. 7 TUM Stammgelände Präsidialbereich LMU Georgenstr. 11 TUM Stammgelände LMU Geschwister-Scholl-Platz 1 TUM Stammgelände Audimax LMU Geschwister-Scholl-Platz 1, Adalberttrakt TUM Stammgelände Cafeteria LMU Geschwister-Scholl-Platz 1, Bücherturm TUM Stammgelände Architekturfakultät LMU Geschwister-Scholl-Platz 1, Hauptgebäude TUM Stammgelände Architekturmuseum

113 Jahresbericht 2009 des Leibniz-Rechenzentrums 107 LMU Geschwister-Scholl-Platz 1, Philosophie TUM Stammgelände Bauinformatik LMU Geschwister-Scholl-Platz 1, Segafredocafe TUM Stammgelände Fak. Bauingenieurwesen LMU Giselastraße 10 TUM Stammgelände Bauklimatik und Haustechnik LMU Großhadern, Chemie/Pharmazie TUM Stammgelände Betriebswirtschaft LMU Großhadern, Genzentrum TUM Stammgelände Bibliothek LMU Hohenstaufenstr. 1 TUM Stammgelände Bildnerisches Gestalten LMU Kaulbachstr. 37 TUM Stammgelände Datenverarbeitung LMU Kaulbachstr. 45 TUM Stammgel. Datenverarbeitung Eikon-Turm LMU Kaulbachstr. 51a TUM Stammgelände Entwurfsautomatisierung LMU Königinstraße 12 TUM Stammgelände Fachschaft Architektur LMU Königinstraße 16 TUM Stammgelände Geodäsie LMU Konradstraße 6 TUM Stammgel. Hydraulik und Gewässerkunde LMU Leopoldstraße 3 TUM Stammgelände Kommunikationsnetze LMU Leopoldstraße 13, Haus 1, Geb TUM Stammgelände LMU Geographie LMU Leopoldstraße 13, Haus 2, Geb TUM Stammgelände STARTmunich e.v. LMU Leopoldstraße 13, Haus 3, Geb TUM Stammgelände Theresianum LMU Ludwigstr. 14 TUM Stammgel. Wasserbau + Wasserwirtschaft LMU Ludwigstr. 25 TUM Stammgel. Wirtschaftswissenschaften LMU Ludwigstr. 27 TUM Versuchsgut Grünschwaige LMU Ludwigstr. 28 TUM Weihenstephan Altes Bauamt LMU Ludwigstr. 29 TUM Weihenstephan Altes Molkereigebäude LMU Ludwigstr. 31 TUM Weihenstephan Bibliotheksgebäude LMU Ludwigstr. 33 TUM Weihenstephan Biologie der Lebensmittel LMU Luisenstr. 37 TUM Weihenstephan Biowissenschaften LMU Martinsried, Biozentrum TUM Weihenst. Bodenkunde, Gebäude 4217 LMU Martinsried Mensa TUM Weihenstephan Botanik LMU Martiusstr. 4 TUM Weihenst. Braufakultät, Gebäude 4112 LMU Meiserstr. 10, Archäologie TUM Weih. Chemie + Biochemie, Geb LMU Menzinger Straße 67 TUM Weihenstephan Dürnast, Geb LMU Oberschleißheim, Klauentierklinik TUM Weihenst. Ernährungslehre Geb LMU Oberschleißheim, Schleicherbau TUM Weihenstephan Fischbiologie LMU Oberschleißh., Versuchsgut St. Hubertus TUM Weihenstephan FML Geb LMU Oberschleißheim, Vogelklinik TUM Weihenstephan Forstbau Geb LMU Oettingenstr. 67 TUM Weihenstephan Geb LMU Oettingenstraße 67 Baracke TUM Weihenstephan Geb LMU Prof. Huber Platz 2, Geb. 420 TUM Weihenstephan Freigelände zu 4214 LMU Vestibülbau (Prof. Huber Platz), Geb. 421 TUM Weihenstephan Geb LMU Vestibülbau Turm (Außenber.), Geb. 421 TUM Weihenstephan Gemüsebau Geb LMU Richard-Wagner Str. 10 TUM Weihenstephan Genetik Geb LMU Schackstr. 4 TUM Weihenstephan Grünlandlehre LMU Schellingstraße 3 Rückgebäude TUM Weihenst. Hörsaalgebäude, Geb LMU Schellingstraße 3 Vordergebäude TUM Weihenst. Lebensmittelchemie Geb LMU Schellingstraße 4 TUM Weih. Lebensmitteltechnikum Geb LMU Schellingstraße 5 TUM Weih. Lebensm. Verfahrens.. Geb LMU Schellingstraße 7 TUM Weihenstephan Mensa, Geb LMU Schellingstraße 9 TUM Weihenstephan Physik, Geb LMU Schellingstraße 10 TUM Weihenstephan Tierernährung Geb LMU Schellingstraße 12 TUM Weihenstephan Tierwissenschaften LMU Seestr. 13 TUM Weihenstephan Geb LMU Sternwarte Laplacestr. 16 TUM Weihenstephan Geb 4113

114 108 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes LMU Sternwarte Scheinerstr. 1 TUM Weihenst. Hörsaalgebäude, Geb LMU Theresienstraße 37 TUM Winzerer Str. 45 LMU Theresienstraße 39 TUM ZHS BFTS LMU Theresienstraße 41 TUM ZHS Geb LMU Veterinärstraße 1 TUM ZHS Geb LMU Veterinärstraße 5 TUM ZHS Geb LMU Veterinärstraße 13 TUM ZHS Geb LMU ZAAR Infanteriestr. 8 Hochschule für Fernsehen und Film LMU Zentnerstr. 31 Hochschule für Philosophie Musikhochschule Arcisstr. 12 Bayerische Staatsbibliothek Musikhochschule Barer Str. 34 Walther-Meißner Institut Musikhochschule Gasteig TUM Wissenschaftszentrum Straubing Wesentliche Netzänderungen im Jahr 2009 Im Jahr 2009 gab es folgende in chronologischer Reihenfolge aufgeführte wesentliche Netzveränderungen Anschluss des Studentenwohnheims Moosacherstr. 81 per Laserlink zum Olympiadorf Anschluss des Studentenwohnheims der katholischen Hochschulgemeinde Preysingstr. 83d mittels VPN-Tunnels (50 Mbit/s) Anbindung des Netzes des Deutschen Wetterdienstes per VPN ans Schneefernerhaus (100 Mbit/s) Anschluss der Kindervilla in Freising per LWL (100 Mbit/s) Anschluss einer Container-Burg mit acht Hörsälen für die Hochschule München per LWL (1 Gbit/s) Erhöhung der Übertragungsgeschwindigkeit zum Visualsierungslabor im LRZ auf 10 Gbit/s Erhöhung der Bandbreite für die interne Vernetzung des Linux-Clusters, Aufbau eines Switches mit 256 Ports mit je 10 Gbit/s Anschluss des Wissenschaftszentrums Straubing per WiN-Anschluss und VPN (30 Mbit/s) Erhöhung der Übertragungsgeschwindigkeit der SDSL-Strecke zum Studentenwohnheim Geschwister-Scholl; Steinickeweg 7 (4.6 Mbit/s) Aufbau eines redundanten WiN Zugangs über privat verlegte LWL zwischen Maschinenwesen und IPP in Garching (10 Gbit/s) Erhöhung der Anschlussgeschwindigkeit zum Serverraum des Genzentrums in Großhadern (10 Gbit/s) Anschluss des Studentenwohnheims Josef-Wirth-Weg über Mikrowellen- Funkstrecke (1 Gbit/s) Integration des Gebäudeleittechniknetzes im Stammgelände der LMU ins MWN Aufbau eines Gebäudeleittechniknetzes in Weihenstephan und Integration ins MWN (100 Mbit/s) Erhöhung der Übertragungsgeschwindigkeit der SDSL-Strecke zur Zoologischen Staatssammlung (6,8 Mbit/s) Inbetriebnahme einer zweiten, redundanten LWL-Anbindung (dark fibre von M-

115 Jahresbericht 2009 des Leibniz-Rechenzentrums 109 net) für den Campus Großhadern (10 Gbit/s) Anschluss des Hans-Eisenmann-Zentrums (TUM) in Weihenstephan mit 1 Gbit/s Außerbetriebnahme von Komponenten wegen Aufgabe des Standorts Schwere Reiterstrasse Nord (Tiermedizin) Anschluss der Bauleitung an der Hochschule München an das Netz des Bauamts Anschluss des Erweiterungsbaus der FH Weihenstephan/Triesdorf in Triesdorf (1 Gbit/s) Erhöhung der Anschlussgeschwindigkeit für das Institut für Nordische Philologie (Amalienstr. 83) über eine Funkbrücke (802.11n) auf 300 Mbit/s Abschaltung des Anschlusses für das Bauhaus Luftfahrt e.v. wegen Umzugs Anschluss des Gästeappartements der Musikhochschule (Barer Str. 34) über ADSL Anbindung eines neuen Gebäudes der FH Weihenstephan/Triesdorf in Triesdorf über eine Funkbrücke (802.11n, 300 Mbit/s) Anschluss der Staatsbrauerei Weihenstephan (TUM) mit 100 Mbit/s Anschluss der Mensa in Martinsried (1 Gbit/s) Anschluss des Oskar von Miller Forums (Boarding-Haus der Bayerischen Bauwirtschaft) mit 1 Gbit/s Erhöhung der Übertragungsgeschwindigkeit TUM Verwaltung, Augustenstr. 44, auf 100 Mbit/s Anbindung und Kopplung der Personenrufanlage der LMU über das MWN Erhöhung der Übertragungsgeschwindigkeit für einen Schulungsraum des Zentrums für Sprach- und Literaturwissenschaften, Schellingstr. 3 (1 Gbit/s) Erhöhung der Übertragungsgeschwindigkeit für das Studentenwohnheim im Olympiadorf auf 1 Gbit/s Anschluss des Studentenwohnheims Heinrich-Groh-Str. 17 mit 1 Gbit/s Erhöhung der Übertragungsgeschwindigkeit des Studentenwohnheims Biederstein über eine gemietete Ethernet-Strecke (1 Gbit/s) Aufbau einer direkten LWL-Verbindung zwischen IPP und Lehrstuhl Leichtbau im Maschinenwesen zur Übertragung von Laser-Signalen Erhöhung der Übertragungsgeschwindigkeit des Studentenwohnheims Giggenhauser Str. 29 in Freising auf 1 Gbit/s Anschluss der TUM School of Education, Schellingstr. 33, über bestehende LWL (dark fibre der Telekom) 1 Gbit/s Netzausbau (Verkabelung) Mit NIP (Netzinvestitionsprogramm in Bayern) wurde zwar eine flächendeckende Vernetzung erreicht, diese ist jedoch an der TUM in München und Garching noch zu einem geringen Teil in Koax ausgeführt. Bis Ende 2008 sollte diese Koax-Verkabelung durch eine strukturierte Verkabelung (Kupfer oder Glasfaser) ersetzt werden. Das Ziel wurde aber nicht erreicht, da einige Gebäude noch auf eine endgültige Generalsanierung warten, bzw. es unklar ist, welche spätere Nutzung dort vorgesehen ist.

116 110 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes TU-München Im Bereich der TU-München (ohne Weihenstephan) konnten die im Folgenden aufgeführten Gebäude im Jahr 2009 mit einer strukturierten Verkabelung versehen werden. Innenstadt 0509 Wienandsbau Iffeldorf 4401 Limnologische Station, Gebäude Limnologische Station, Gebäude 2 Garching 5402 Laborgebäude CH6, Garching Es wird versucht, auch die Schragenhofstr. 31 mit diesem Programm (NIP II) zu realisieren. Koax verbleibt noch in den Gebäuden 0503, 0106 (N6) auf dem Stammgelände der TUM und 5402 (CH2) am Standort Garching; hier soll aber das Koax im Rahmen anderer Maßnahmen ersetzt werden. LMU München Im Bereich der LMU München sind alle Gebäude mit einer strukturierten Verkabelung versehen. Es gibt jedoch teilweise Defizite in der Verwendung der installierten Medien (nur 4-drahtiger Anschluss [Cablesharing] oder Installation von Kategorie 5 - Kabeln bzw. Anschlusskomponenten). Dies betrifft 28 Gebäude (NIP V). Die Kosten in Höhe von 18,4 Mio. wurden vom Landtag genehmigt. Im Rahmen des Konjunkturprogramms sollen im 1. Bauabschnitt 4 Standorte bis 2011 nachgerüstet werden: M-Bogenhausen 7000 Universitäts-Sternwarte (Neuverkabelung bereits abgeschlossen) M-Lehel Oettingenstraße 67 (Informatik, Kommunikationswissenschaft, ) M-Schwabing Leopoldstraße 13 Haus 1 3 (Psychologie + Pädagogik) M-Maxvorstadt 1003 Theresienstraße 37 (Physik, Meteorologie) Die verbleibenden 24 Gebäude werden voraussichtlich ab 2012 im Rahmen des 2.Bauabschnittes der NIP V-Maßnahme mit einer Verkabelung der Kategorie 6a modernisiert. Weihenstephan (TU-München) Auf dem Campus Weihenstephan der TU-München sind alle Gebäude mit einer strukturierten Verkabelung versehen, entweder Kupfer (Kategorie 6-Kabel) oder Glasfaser (multimode). LWL-Netze auf den Campus-Geländen Auf den Campusgeländen TUM-Stamm/Nordgelände, LMU-Stammgelände, TUM-Garching, TUM- Weihenstephan und LMU Großhadern/Martinsried sind privat verlegte Glasfaserstrecken installiert, die teilweise schon über 15 Jahre existieren. Hier muss in den nächsten Jahren nachgerüstet werden, da bei einem Teil der Strecken die heute benötigten Glasfasertypen (OM3, Monomode) nicht vorhanden sind, diese aber aufgrund der gestiegenen Übertragungsraten (10 Gigabit/s) notwendig sind Anbindung Studentenwohnheime Das LRZ ermöglicht Wohnheimen eine feste Anbindung über Standleitung, DSL-Technik oder WLAN (Funk-LAN) an das MWN und damit an das Internet. Die Kosten der Anbindung hat der Heimträger zu übernehmen, für die Netznutzung werden aber keine Gebühren verlangt. Zum Jahresende 2009 sind Wohnheimplätze in 56 Heimen an das MWN angeschlossen, davon 20 über eine Glasfaserleitung (LWL) mit 100 Mbit/s, 15 über Funkstrecken, 10 über DSL und 11 über 100 Mbit/s Laserlinks. Die nachfolgende Tabelle zeigt die Wohnheime, die Ende 2009 am MWN angeschlossen sind:

117 Jahresbericht 2009 des Leibniz-Rechenzentrums 111 Name Adresse Träger Plätze Anschluss Studentenstadt Freimann Christoph-Probst- Straße 10 Studentenwerk 2440 LWL zu MPI Freimann Studentenviertel auf dem Oberwiesenfeld Helene-Mayer-Ring 9 Studentenwerk 1801 LWL zu ZHS Kreittmayrstraße Kreittmayrstraße 14 Studentenwerk 45 Funk zu FH (Erzgießereistr. 14) Adelheidstraße (mit Deutschkurse für Ausländer) Adelheidstraße 13 Studentenwerk 374 Laser zu FH Dachauerstraße John-Mott-Haus Theo-Prosel-Weg 16 CVJM München e.v. 60 Funk zu Winzererstr. Oberschleißheim Oberschleißheim Am Schäferanger 9-15 Studentenwerk 171 LWL zu Rinderklinik Georg-Lanzenstiel-Haus Kieferngartenstraße 12 Verein evangelischer Studentenwohnheime 135 VPN-Tunnel über DSL Ökumenisches Studentenheim Steinickeweg 4 Verein evangelischer Studentenwohnheime 70 Funk zu TUM-Uhrenturm Hugo-Maser-Haus Arcisstr. 31 Verein evangelischer Studentenwohnheime 70 Funk zu TUM-Uhrenturm Studentenwohnheim Geschwister Scholl Steinickeweg 7 Studentenwohnheim Geschwister Scholl e.v. 227 SDSL M-net 2 Mbit, Linux-Router St. Albertus Magnus Haus Avenariusstraße 15 (Pasing) St. Albertus Magnus-Stiftung (Kath.) 108 SDSL M-net Wohnheimsiedlung Maßmannplatz Hess-Straße 77 Wohnheimsiedlung Maßmannplatz e.v. 124 Funk zu HM Dachauerstraße Jakob Balde Haus Theresienstraße 100 Studienseminar Neuburg- Donau 110 LWL zu TUM Internationales Haus Adelheidstraße 17 Studentenwerk 93 über Adelheidstr. 13 angeschlossen Hedwig Dransfeld Allee Hedwig Dransfeld Allee 7 Studentenwerk Mbit/s Laserlink Stettenkaserne Schwere Reiter Str. 35 Studentenwerk 186 SDSL M-net für Uniradio 100 Mbit/s Laserlink zur FH in der Dachauerstraße Heidemannstraße Paul-Hindemith-Allee 4 Studentenwerk Mbit/s Laserlink Felsennelkenanger Felsennelkenanger 7-21 Studentenwerk 545 Heiglhofstraße Heiglhofstraße 64/66 Studentenwerk 415 Sauerbruchstraße Sauerbruchstraße Studentenwerk Mbit/s Richtfunk zur Studentenstadt, von dort per LWL zu MPI 100 Mbit/s Laserlink mit integriertem 2 Mbit-Funk-Backup 100 Mbit-Laserlink mit integriertem 2 Mbit-Funk-Backup Garching I Garching Jochbergweg 1-7 Studentenwerk Mbit-Laserlink zu TU-Feuerwehr Garching II Garching Enzianstraße 1, 3 Studentenwerk Mbit-Laserlink zu TU- Heizkraftwerk Dominohaus Garching Unterer Strassäcker 21 Dominobau 81 LWL zu TU-Heizkraftwerk Maschinenwesen Ehemalige Hausmeisterwohnung Garching Studentenwerk 4 SpeedVDSL Türkenstraße Türkenstraße 58 Studentenwerk 97 Intern mit Funk vernetzt Internet-Anbindung über 2 T-DSL- Anschlüsse Weihenstephan II Giggenhauser Str Freising Studentenwerk 226 LWL über Weihenstephan IV Lange Point Lange Point 1-35 Studentenwerk 382 LWL zu FH Heizhaus

118 112 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes (Weihenstephan III) Freising Weihenstephan IV Giggenhauserstraße Studentenwerk 239 LWL zur Telefonzentrale Vöttinger Straße (Weihenstephan I) Vöttinger Straße Freising Studentenwerk 122 LWL zu alter DVS Roncallicolleg (+ KHG) Nymphenburger Str. 99 Roncalli-Colleg Prof. Fuchtmann 125 Funk zur FH Schachenmeierstraße BLLV-Wohnheim Cimbernstraße 68 Bayerischer Lehrer- und Lehrerinnenverband (BLLV) 160 SDSL M-net Stiftung Maximilianeum Max-Planck-Str. 1 Stiftung Maximilianeum 26 Funk zu KH Rechts der Isar Kardinal-Wendel-Kolleg Kaulbachstr. 29a Jesuiten 68 Funk zu Monumenta Auch intern Funk-AP Studentenheim "Paulinum" Rambergstraße München Studentenwohnheim Paulinum e.v. (Kath.) 58 Funk zu TUM-Uhrenturm Studentenheim "Willi Graf" Hiltenspergerstr. 77 Kath. Siedlungswerk 120 M-net 4,6 Mbit/s SDSL Albertia, Ottonia, Erwinia Gabelsbergerstr. 24 Stud.-Verbindungen Albertia, Ottonia, Erwinia 25 Funk zu Richard Wagner Str. 18 Wohnheim Richard Wagner- Str. 16 Richard-Wagner-Str. 16 Ingeborg van-calker Stiftung 40 LWL zu Richard Wagner Str. 18 Hochschulhaus Garching Enzianstr. 5 Evangelische Studentenwohnheime 65 Funk zu TU-Feuerwehr Spanisches Kolleg Dachauerstraße 145 Katholische Kirche 35 Funk a zur HM Chiemgaustraße Traunsteiner Straße 1-13 Studentenwerk 348 Telekom-LWL zu TUM Am Anger I Unterer Anger 2 Am Anger II Unterer Anger 17 Orden der Armen Schulschwestern Orden der Armen Schulschwestern 50 M-net SDSL 82 M-net SDSL Wohnheim Stiftsbogen Schröfelhofstraße 4 Studentenwerk 580 LWL zu Campus Großhadern Priesterseminar St. Johannes der Täufer Georgenstraße 14 Katholisches Ordinariat 73 Funk zu Georgenstraße 11 Magdalena-Lindt-Heim Kaulbachstr. 25 Ev. Waisenhausverein 93 LWL zu Staatsbibliothek Marie-Antonie-Haus Kaulbachstr. 49 Studentenwerk 94 LWL zu Ludwigstr. 28 Student Living Center Freisinger Landstraße 47 Garching Fa. Melampus 78 LWL zu TUM Heizhaus Studentenwohnanlage Biederstein Biedersteiner Str a Studentenwerk 163 LWL zu Amalienstr. 17 Newman-Haus Kaulbachstr. 29 Newman-Verein 68 Funk über Kaulbachstr. 29 Sophie-Barat-Haus Franz-Josef-Str. 4 Katholisches Ordinariat 100 LWL zu Ordinariat Johann-Michael-Sailer-Haus Preysingstr. 83d Katholisches Ordinariat 26 LWL zu Ordinariat Heinrich-Groh-Str. Heinrich-Groh-Str. 17 Studentenwerk 59 LML über Amalienstr. 17 Moosacher Straße Moosacher Str. 81 Studentenwerk Mbit/s Laserlink Josef-Wirth-Weg 19 Josef-Wirth-Weg 19 Studentenwerk Mbit/s Laserlink Gästeappartment Musikhochschule Barer Str. 34 Hochschule für Musik und Theater ADSL mit VPN-Tunnel Oskar von Miller Forum Oskar von Miller Ring 25 Oskar von Miller Forum 80 LWL über Amalienstr. 17 Summe insgesamt

119 Jahresbericht 2009 des Leibniz-Rechenzentrums Dienste Internet-Zugang Der Zugang zum weltweiten Internet wird über das Deutsche Wissenschaftsnetz (WiN) realisiert. Im Jahr 2009 war das MWN technisch mit einer 10 Gbit/s-Schnittstelle am WiN angeschlossen, deren Kapazität aus Kostengründen auf die Übertragungsrate von 8,16 Gbit/s begrenzt ist. Derzeit ist ein zweistufiges Ausfallkonzept mit Backups für den Internetzugang umgesetzt (s. u.). Die monatliche Nutzung (übertragene Datenmenge) des WiN-Anschlusses seit Juni 1996 zeigt Abbildung 56. Abbildung 56 Entwicklung der Nutzung des WiN-Anschlusses des Münchner Wissenschaftsnetzes 2,5 2 1,5 1,3 2 1,6 1,6 1,3 1,2 1,4 1,3 1,6 1,8 1,7 1,8 1,5 1 0, Abbildung 57 Steigerungsraten des übertragenen Datenvolumens pro Jahr

120 114 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Die Steigerungsraten - bezogen auf die jeweils im Vorjahr transportierte Datenmenge - sind in Abbildung 57 graphisch dargestellt. Bezogen auf das Jahr 1998 wurde im Jahr 2009 knapp die 200-fache Datenmenge transportiert. Seit September 2003 ist der WiN-Anschluss vertragstechnisch ein so genannter Clusteranschluss, bei dem die vom MWN versorgten teilnehmenden Institutionen als eigenständige Partner mit eigenem Tarif bezogen auf den eingehenden Datenverkehr aufgefasst werden. Zu diesem Zweck wurden die laufenden Messungen kumuliert, um eine Verteilung des Datenverkehrs zu bekommen. Die prozentuale Verteilung des Datenvolumens am WiN-Zugang (Messzeitraum November 2009) zeigt Tabelle 22. Institution Total Bytes % LRZ und BAdW 71,1 TUM 16,3 LMU 7,4 Hochschule München 1,5 Sonstige 3,2 Hochschule Weihenstephan 0,2 GATE 0,3 Tabelle 22: Prozentuale Verteilung des Datenverkehrs am WiN-Zugang Die prozentuale Verteilung des gesamten Verkehrs gegenüber Werten des Vorjahres hat sich beim LRZ um 6 % verringert. Der Verkehr der TUM hat um 6 % zugenommen. Die technische Realisierung der Anbindung des MWN an das Internet zeigt Abbildung 58: Abbildung 58 Anbindung des MWN an das Internet Der Standardzugang zum Internet ist über das vom DFN betriebene Wissenschaftsnetz (WiN) realisiert. Der WiN-Anschluss des LRZ erfolgt über das IPP (Max-Planck-Institut für Plasmaphysik) in Garching mit einer Anschlussbandbreite von 10 Gbit/s. Dort wurde vom DFN der zugehörige WiN-Kernnetz- Router installiert. Derzeit ist ein zweistufiges Ausfallkonzept für den Internetzugang umgesetzt. 1. Im Jahr 2009 wurde eine redundante LWL-Strecke zwischen dem Maschinenwesen und dem IPP realisiert. Falls die Hauptleitung zwischen LRZ und IPP oder eines der entsprechenden Interfaces an den beiden Routern ausfallen sollte, wird automatisch auf den Backup-Link zwischen Maschi-

121 Jahresbericht 2009 des Leibniz-Rechenzentrums 115 nenwesen und IPP umgeschaltet. Durch diese Backup-Verbindung entstehen keine zusätzlichen Kosten. 2. Sollten beide Leitungen oder aber der Kernnetzrouter des DFN in Garching ausfallen, wird ohne merkliche Unterbrechungen für den Benutzer auf eine über M-net realisierte Backup-Verbindung umgeschaltet. Die Backup-Verbindung zum Internet wird über eine LWL-Strecke mit 1 Gbit/s zum nächsten Anschlusspunkt von M-net geführt. Die LWL-Strecke kostet einen monatlichen Grundbetrag, das Datenvolumen wird nach Bedarf berechnet. Die Backup-Konzepte funktionieren für alle Systeme mit Provider-unabhängigen IP-Adressen (Standardfall im MWN). Das LRZ-Netz kann nämlich mit einem Großteil seiner IP-Adressen als autonomes System im Internet agieren. Einige Standorte (Rechts der Isar, Hochschule München, Beschleunigerlabor, Zoologische Staatssammlung, kath. Stiftungsfachhochschule) bzw. Systeme (Bibliotheksverbund Bayern), die aus historischen Gründen noch providerabhängige IP-Adressen (i.d.r. vom DFN vergeben) verwenden, können die Backup-Stecke über M-net nicht nutzen. Im Jahr 2009 wurde die Backup-Strecke bei der Einführung der DFN-Backup-Strecke benötigt. Bei den Arbeiten zur Umkonfiguration musste für ca. 30 Minuten auf den M-net Backup umgeschaltet werden Domain Name System Die Konfiguration der DNS-Systeme hat sich gegenüber 2008 dahingehend geändert, dass nun die Funktion des bisherigen Servers dns3.lrz-muenchen.de auf eine virtuelle Maschine im portugiesischen Forschungsnetz FCCN (Fundação para a Computação Científica Nacional) ausgelagert wurde. Da dieser Nameserver dns-fccn.lrz-muenchen.de außerhalb des Deutschen Wissenschaftsnetzes (X-WiN) liegt, können DNS-Abfragen auch bei einem Ausfall des X-WiN oder einer Großstörung des MWN noch beantwortet werden. Damit wird z.b. verhindert, dass in einem solchen Fall s fremder Nutzer bei ihren MTAs verzögert oder abgewiesen werden. Abbildung 59 Statistik für alle DNS-Server (Autoritativ) Abbildung 60 Statistik für alle DNS-Resolver

122 116 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Neben IPv4- werden auch IPv6-Einträge unterstützt. Der WebDNS-Dienst wird inzwischen von 198 Nutzern zur Pflege der DNS-Einträge verwendet. Die Anzahl der über WebDNS verwalteten DNS-Zonen stieg (von 1200) auf Es wurden 38 neue Domains unter verschiedenen Toplevel-Domains (z.b. de, org, eu) für Institute und Organisationen registriert, 25 wurden von anderen Providern transferiert. Abbildung 59 und Abbildung 60 zeigen die Frequenz der Anfragen für den autoritativen und Resolving- Dienst über 7 Tage ( ). Eine Übersicht aufgeteilt nach Domains im MWN zeigt die folgende Tabelle. Die reale Anzahl der Zonen und Einträge ist um einiges höher, kann aber nicht ermittelt werden, da manche der von den Instituten selbst betriebenen DNS-Server keine Auflistungs-Abfragen beantworten. Anzahl Anzahl Anzahl Anzahl Anzahl Anzahl A- AAAA- Domain Zonen Sub-Domains Records Records Aliase MX-Records uni-muenchen.de lmu.de tu-muenchen.de tum.de fh-muenchen.de hm.edu fhweihenstephan.de badwmuenchen.de badw.de lrz-muenchen.de lrz.de mhn.de mwn.de Sonstige Gesamt Wählzugänge (Modem/ISDN) Tabelle 23 zeigt die im Dezember 2009 angebotenen Modem/ISDN-Zugänge mit den jeweiligen Anbietern und Rufnummern im Überblick. Anbieter Rufnummer Anzahl Kanäle Telekom M-net TUM und Behörden (LCR) 30 LMU und Behörden (LCR) 30 Tabelle 23: Anbieter und Rufnummern der Wählanschlüsse

123 Jahresbericht 2009 des Leibniz-Rechenzentrums 117 Die Anschlüsse der Firma M-net stehen nur M-net-Kunden zur Verfügung. Für diese sind Verbindungen in der Nebenzeit (18-8 Uhr und Sa/So) kostenfrei. Die Nutzung des Modem/ISDN-Zugangs ging 2009 weiter zurück. Die Anzahl der Telekom-Kunden sank auf ca. 160, die der M-net-Kunden auf ca. 70. Abbildung 61 zeigt für 2009 die maximale Anzahl gleichzeitig aktiver Verbindungen pro Woche, aufgeschlüsselt nach den jeweiligen Rufnummern. Abbildung 61 Maximale Anzahl von Verbindungen pro Rufnummer Über Radiuszonen können einzelne Institutionen für ihre Beschäftigten bzw. Studierenden die Berechtigung für den Wählzugang am MWN selbst verwalten. Zum Jahresende 2009 waren 46 Radiuszonen eingerichtet. Die Reduktion gegenüber 61 Zonen im Jahr 2008 ergab sich durch die Entfernung inaktiver Server aus der Konfiguration. Neu hinzu gekommen sind 2009 ads.mwn.de und lmupsychologie. Eine Auflistung der Radiuszonen zeigt folgende Tabelle: Zonenbezeichnung aci.ch.tum ads.mwn.de binfo.wzw.tum.de bl.lmu campus.lmu.de cicum.lmu cip.informatik.lmu cipmath.lmu edv.agrar.tum fh-weihenstephan.de forst.tum frm2.tum fsei.tum fsmpi.tum hm.edu ibe.lmu ikom.tum info.tum lkn.tum lmu.de lmupsychologie lrz.de lrz-muenchen.de math.lmu math.lmu.de math.tum med.lmu Institut Lehrstuhl für Anorganische Chemie TUM Kennungen im MWN ADS Genome oriented Bioinformatics, TUM Beschleuniger Labor der TU und der LMU München Internet und virtuelle Hochschule (LMU) Department Chemie LMU Institut für Informatik der LMU Mathematisches Institut der LMU Datenverarbeitungsstelle der TU in Weihenstephan Hochschule Weihenstephan Forstwissenschaftliche Fakultät der TUM Forschungsreaktor Fachschaft Elektro- & Informationstechnik Fachschaft MPI Hochschule München Institut für med. Informationsverarbeitung Fachschaft Elektro- & Informationstechnik Informatik der TUM Lehrstuhl für Kommunikationsnetze Verwaltung der LMU MAC-Authentisierung an Switches der LMU Psychologie LRZ LRZ Mathematisches Institut der LMU Mathematisches Institut der LMU Zentrum für Mathematik der TUM Medizin der LMU, Großhadern

124 118 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes med.lmu.de meteo.lmu mytum.de org.chemie.tum physik.lmu.de radius.wzw.tum rcs.tum rz.fhm staff.fhm studext studlmu studtum tphys.lmu tum.de usm usm.lmu vm08.fhm wzw.tum ZV.TUM Medizin der LMU, Großhadern Meteorologisches Institut LMU Mitarbeiter und Studenten der TUM Institut für Organische Chemie und Biochemie Fakultät für Physik der LMU Informationstechnologie Weihenstephan (ITW) Lehrstuhl für Realzeit-Computersysteme Rechenzentrum der Hochschule München (Studenten) Rechenzentrum der Hochschule München (Mitarbeiter) Studentenrechner LRZ (Externe) Studentenrechner LRZ (LMU) Studentenrechner LRZ (TUM) Institut für Theoretische Physik der LMU Mitarbeiter und Studenten der TUM Sternwarte der LMU Sternwarte der LMU Fachbereich 08, Hochschule München Informationstechnologie Weihenstephan (ITW) Zentrale Verwaltung der TUM VPN (IPsec) Im MWN werden VPN-Server für folgende Anwendungsbereiche eingesetzt: Zugang über vom LRZ betreute WLANs. Zugang über öffentliche Anschlussdosen für mobile Rechner. Zugang zu internen MWN-Diensten (z.b. Online-Zeitschriften) für Bewohner von Studentenwohnheimen. Zugang zu internen MWN-Diensten über fremde Internet-Anbieter (z.b. T-DSL / T-Online). Zugang für Heimarbeitsplätze des LRZ Mitarbeiter müssen die Ressourcen im LRZ während ihrer Arbeit zu Hause nutzen können. Dazu erhalten sie einen VPN-Router, an den sie Rechner und IP-Telefon am Heimarbeitsplatz anschließen können. Der VPN-Router ist so konfiguriert, dass er automatisch eine Verbindung zum VPN-Server im LRZ aufbaut. Über diese Verbindung, einen IPsec LAN-to-LAN Tunnel mit 3DES-Verschlüsselung, wird ein Subnetz mit der Subnetzmaske geroutet. Damit stehen sechs IP-Adressen für Router, Rechner, ggf. Laptop und IP-Telefon zur Verfügung. Bei dem VPN-Router handelt es sich um das Modell WRV54G von Linksys. Das IP-Telefon ist an der VoIP-Telefonanlage des LRZ angeschlossen und so konfiguriert, dass der Mitarbeiter am Heimarbeitsplatz mit der gleichen Telefonnummer wie an seinem Arbeitsplatz am LRZ erreichbar ist. Technik Der VPN-Dienst basiert auf einer Appliance vom Typ VPN-Concentrator 3030 und vier Appliances vom Typ Adaptive Security Appliances ASA5540 der Firma Cisco. Der VPN-Concentrator 3030 dient in erster Linie für die Anbindung von externen Instituten über IPsec LAN-to-LAN Tunnel. Die vier ASA- Appliances sind zu einem VPN-Cluster zusammengefasst. Dieser VPN-Cluster wird von IPsec-Clients unter der Adresse ipsec.lrz.de, von SSL-VPN-Clients unter der Adresse asa-cluster.lrz.de angesprochen. Die Nutzer werden beim Anmelden mit der am geringsten ausgelasteten Appliance verbunden. Der VPN- Concentrator 3030 ist über zwei 100 Mbit/s Anschlüsse (öffentlich und privat) mit dem MWN verbunden und dient für LAN-to-LAN VPN-Tunnel. Die vier ASA5540 sind jeweils mit 1GBit/s angeschlossen. Die verfügbare Bandbreite der verschlüsselten Verbindungen (3DES/AES) beträgt 50MBit/s beim VPN- Concentrator 3030 und 350MBit/s pro ASA5540. Authentifizierung, Autorisierung der Nutzer sowie Accounting werden über das RADIUS-Protokoll abgehandelt. Berechtigte Nutzer können die aktuellen Versionen der VPN-Software vom Web- oder VPN-Server des LRZ herunter laden. Für Linux stehen neben den Cisco-IPsec und AnyConnect-Clients der Open Sour-

125 Jahresbericht 2009 des Leibniz-Rechenzentrums 119 ce VPN-Client vpnc (IPsec) und openconnect (SSL-VPN) zur Verfügung, der erfahrenen Nutzern erweiterte Möglichkeiten bietet. Diese Clients sind inzwischen in den Standarddistributionen wie z.b. SuSE, Debian und Ubuntu enthalten. Arbeitsschwerpunkte 2009 Im Jahr 2009 gibt es noch keinen Cisco IPSec-Client für 64-Bit Windows Betriebssysteme. Die bereitgestellten Anleitungen für Software von Drittherstellern, wie z.b. NCP oder Shrew Soft erfordern einen erhöhten Beratungsaufwand. Im Rahmen des Programms Open Beta for Cisco ASA 8.2 Software Release konnte der AnyConnect Client erfolgreich getestet werden. Dieser SSL-VPN Client funktioniert nun auch mit 64-Bit Windows Betriebssystemen. Zudem zeigt er deutlich weniger Probleme bei der Installation auf Windows Vista und Windows 7 sowie auf Linux. Der Betrieb wurde Mitte Oktober aufgenommen. Entwicklung des Datenverkehrs über die VPN-Server Im Monat November (dem Monat mit dem höchsten Datenaufkommen im Jahr) waren es 20,7 TB eingehender Verkehr (Nov 2008: 12,7 TB, Nov 2007: 11,4 TB, Nov 2006: 6,2 TB, Nov 2005: 3,2 TB) und 4,6 TB ausgehender Verkehr (Nov 2008: 3,8 TB, Nov 2007: 3,1 TB, Nov 2006: 1,7 TB, Nov 2005: 0,7 TB). In Spitzenzeiten sind bis zu 2500 Nutzer gleichzeitig angemeldet, täglich werden bis zu Verbindungen aufgebaut. Nach der Einführung des AnyConnect Clients am 16. Oktober 2009 erreichte dieser bis Jahresende einen Anteil von 13% aller Verbindungen mit steigender Tendenz. Das Apple iphone konnte seinen Anteil an den VPN-Verbindungen im Vergleich zum Vorjahr (Referenzmonat Dezember) von 4% auf 9% mehr als verdoppeln, der Anteil von Mac OS X Clients stieg um ein Drittel. Leicht rückläufig waren die Anteile der Windows- und Linux-Clients Ausgehend in GB Eingehend in GB Summe in GB Dez Jan Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Abbildung 62 Monatliches Datenvolumen in Gigabyte der VPN-Server im Jahr 2009

126 120 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Ausgehend in TB Eingehend in TB Summe in TB Abbildung 63 Entwicklung des Verkehrsaufkommens über die VPN-Server im Referenzmonat November Abbildung 64 Anzahl der gleichzeitig an den VPN-Servern angemeldeten Nutzer. Das Maximum wurde am 4. Dezember 2009 erreicht. Von liegen keine Daten vor DFN-Roaming Das LRZ nimmt seit Anfang 2005 am DFN-Roaming-Dienst des DFN (Deutsches Forschungsnetz) Vereins teil. Damit ist es den Wissenschaftlern möglich, mittels einer vorhandenen Kennung ihrer Heimat- Hochschule einen einfachen Zugang ins Internet zu erhalten, wenn sie sich im Bereich des MWN aufhalten. Als Zugangspunkte dienen die vorhandenen WLAN-Accesspoints (an praktisch allen Standorten). Das LRZ bietet nur noch die Zugangsmethode über 802.1X an, VPN/WEB wurde eingestellt. Schon bei der Anmeldung am Accesspoint wird hier die Kennung und das Passwort auf Gültigkeit überprüft. Voraussetzung ist ein Betriebssystem, das 802.1X unterstützt, bzw. ein entsprechender Client. Der Nachteil dieses Verfahrens ist eine noch immer nicht ausreichende Verbreitung der Client-Software, bzw. ihre Integration in das Betriebssystem. Der Vorteil liegt in der sicheren Verbindung (Verschlüsselung) zwischen Rechner und Accesspoint, einem verbesserten automatischen Ablauf und der Möglichkeit, sofort s zu versenden und zu empfangen, ohne vorher einen Webbrowser benutzen zu müssen.

127 Jahresbericht 2009 des Leibniz-Rechenzentrums % 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Verbindungen AnyConnect Abbildung 65 Einführung des Cisco AnyConnect Essential Clients am Dargestellt sind die Verbindungen pro Kalenderwoche (KW 2009) und der Anteil der Verbindungen über den AnyConnect Client. Die Zahlen in den grünen Balken stellen die Verbindungen in der jeweiligen Kalenderwoche dar. KW 42 und KW 53 haben kleinere Werte, da beide nur 3 Tage umfassen. In der erweiterten Form mit der SSID 'eduroam' statt '802.1X' ist nicht nur das Roaming innerhalb Deutschlands, sondern auch in vielen Ländern Europas und in Australien möglich. Die SSIDs 'eduroam' und '802.1X' werden auf fast allen Accesspoints im MWN zur Verfügung gestellt. Nur an 2 Standorten mit je einem Accesspoint, die über DSL-Leitungen angeschlossen sind, war es aus technischen Gründen nicht möglich, das DFN-Roaming anzubieten. Abbildung 66 zeigt die Benutzungs-Statistik für das 802.1X/eduroam. Abbildung 66 Anzahl der Eduroam-Nutzer im Jahr Unterstützung von Veranstaltungen Das LRZ richtet für Veranstaltungen im Münchner Wissenschaftsnetz (MWN) auf Anforderung ein spezielles Netz ein, damit die Tagungsteilnehmer das Netz ohne besondere Authentifizierung nutzen können. Hierbei wird davon ausgegangen, dass die Nutzer dieses Netzes nicht unbedingt aus dem Kreis der Münchner Hochschulen stammen, sondern auch Firmen und sonstige Gäste das Internet und das MWN ohne spezielle Vorkehrungen (ohne VPN-Client-Installation, ohne Validierung) nutzen sollen. Eine Anmeldung und die bei frei zugänglichen Netzanschlüssen ansonsten obligatorische Verwendung eines VPN-Zugangs werden hier nicht gefordert.

128 122 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Diese "offene" Konfiguration bleibt auf den Zeitraum und den Ort der Veranstaltung begrenzt. Der Zugang ist drahtlos (WLAN nach IEEE b/g/n) möglich. Nur in Ausnahmefällen werden feste Netzanschlussdosen (100 Mbit/s LAN) zur Verfügung gestellt. Für Geräte, die keine eingebaute Funkschnittstelle haben, werden vom LRZ Wireless-Client-Bridges (WCB) bereitgestellt. Die Realisierbarkeit des Dienstes hängt aber von der vorhandenen Infrastruktur ab, nicht in allen Gebäuden und Räumen ist eine solche Möglichkeit gegeben. Allerdings ist dies nur noch selten der Fall. Der Zugang wird seit 2006 bevorzugt per WLAN zur Verfügung gestellt. Es wird keine WEP-Verschlüsselung verwendet, um Probleme mit der Weitergabe und Einstellung der Schlüssel zu vermeiden. Allerdings wurde 2009 auch damit begonnen, verschlüsselte Verbindungen, insbesondere für länger dauernde Kurse, zur Verfügung zu stellen wurden 177 (+23 gegenüber dem Vorjahr) Veranstaltungen unterstützt. Datum Veranstaltung Datum Veranstaltung 100GET-E3-Projektworkshop Mai IKS IKOM ILL-Steering-Committee Jahre-Numerische-Mathematik IMAPS AGNP-Kongress ISAR-Projekt-Kickoff AK-Grid-März ITER-C-Professur AK-Visualisierung-März Ideenbörse-LFB ASC-Advisory-Board Intel-Chien ASC-Workshop-Sept IsarMUN ASC_Summerschool Isotopeschool ASC_Workshop-Nov Iterative_Gleichungslöser Abschlussworkshop-IntegraTUM JAST-Juni Alumni_and_Career KMOS Application Scalability KanzlertagungHM Ascen Kick_Off_GIDS BAPSYCHHagen Kognimobil BAPSYCHHagen Kognitive-Automobile-Febr2009 Kolloquium_Nanoelektronik BHN-Sitzung-Juli BSB-EMedientage Kunstpädagogischer-Tag BacAbs LMU-Alummni-2009 Bayerischer_Waldbesitzertag LMU-Harvard-YS-Forum Besprechung_KrdI Lenkungsausschuss-April Besuch_LMU_Präsident- Sept_ Live_Hacking_Demo BetrieblicheMobilitätspolitik MACOSPOL Bio-Imaging MAP-Juli CEA-Treffen-Okt MDMI CISCO-WEBEX MMK CLUVA MUT CPW Marketing-Symposium-2009 Mathematik-Workshop-TUM Campus-Meeting Chassis_tech Medien_ Cigre-Fachtagung Microsoft-Promotion-2009 Nachwuchsforschertreffen Cisco-April Juni Cotesys-Apr Opera-Software-2009

129 Jahresbericht 2009 des Leibniz-Rechenzentrums DEISA-AllHands-Maerz PDF-Format_und_Geodaten DEISA2_WP8-Nov PENeLOPE-Mai DELL-Juli PRACE-Juli DFG-SPP PROSPECT-April DFN-Forum Physik-Workshop-April DGI2-Suko Promovieren-in-DK DORII_AHM Quality- Management_for_Trainers DPG_Fruehjahrstagung_Muenche n_ Quovadis DT-Meeting Recht_ E18-PWA-Workshop Reflect_Annual_Meeting ECATA-Kurs Restructur- ing_political_conflicts_in_we ECESS-Workshop Roboticswettbewerb EGI_Editorial_Board Roboticswettbewerb-Herbst EGU-Council-Meeting SEIS-Projektmeeting-2009 EMBO-Kurs-Biomacromolecules SENSORIA-Treffen ESF SFB-Transregio ESVOT-Tagung_ SFB_WSI EU-Projektbesprechung STRATOS-Steering-Board EWS_ Scalasca_Workshop Entwicklerforum-Febr School-of-Education Ernährungs-Kongress Schwerpunktprogramm Euro-AFM-Forum SeminarNetApp Eurographics Simulating_Complex_Organizatio ns Euromech Steuerungs-und- Regelungstechnik ExMar Strahlenschutz FUN OCT Meeting Symplectic-Field-Theory FernUni-Psych Synthesefest Fichtenwaelder_im_Klimawandel Synthetic_Evolution Firmenkontaktgespräch-LMU TUM_Mechanical_Engineering Forschungsprojekt_Anna_tanzt Tanz_in_Schulen Forstlicher_Unternehmertag TdoT-LMU Forum-Life-Science Teilchenphysik-Grid Fundamental-Symmetries Tierschutz_und_Ethologie-2009 Trace_AM_Summer_School GAMIT-Feb GLAB-Mai Unternehmertag-2009 Genes_in_Health_and_Disease VDI-Kolloquium-April Geoinformationssysteme VDOE-Jahrestagung Gesunde-Hochschule Vorkurs-Physik-Herbst GfKT-Juni WLAN-Präsentation Bögle Global_Health WPMSIIP HLRB-Review Water-Workshop HP-Colubris-Treffen Workshop Petascalerechner HPC-Roundtable ZAPF-2009

130 124 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes HPDC-2009-Meeting ZIEL-Maerz HPDC-2009-Workshop ZIEL-Okt Hard-Exclusive-Processes Zope-User-2009 Historische-Kommission-März Zukunftsstudie HoKo edeisa-workshop-febr Huber fupsych Hydrometeorologen ifo-jahresversammlung Hygienic-Design itsmf IAS_English_Course itmf IBM mfk IGE-All-Hands-Meeting qpcr IKOM-Bau sci.tum IKOM_Lifescience_2009 Tabelle 24: Liste der unterstützten Veranstaltungen im Jahr 2009 Auch im Jahr 2009 wurden für die Unterstützung der Konferenzen teilweise schon vorhandene Access Points gegen neuere ausgetauscht, um den Bedarf abdecken zu können. Damit können Konferenz- Teilnehmer mit neueren Laptops Transfer-Raten bis zu 300Mbit/s erreichen und geben dadurch den Funkkanal schneller wieder für andere Teilnehmer frei. Außerdem wurden öfters Access Points anlässlich einer Veranstaltung neu aufgebaut, die ansonsten erst zu einem späteren Zeitpunkt eingerichtet worden wären. Eine Verteilung der Konferenzen auf die einzelnen Monate zeigt Abbildung 67. Erwartungsgemäß werden die Hörsäle vor allem in vorlesungsfreien Zeiten für Konferenzen genutzt. Abbildung 67 Anzahl der mit WLAN unterstützten Veranstaltungen Service Load Balancer (SLB) Die beiden Big-IP-3400 Server Load Balancer von F5 Networks sind schon seit 2006 produktiv mit großem Erfolg im LRZ im Einsatz. Über sie laufen Dienste wie Webserver, Radiusproxies, Zeitschriftenproxies und SSH-Logins für das Linux-Cluster.

131 Jahresbericht 2009 des Leibniz-Rechenzentrums 125 Abbildung 68 Schematische Darstellung des Load Balancer Netzes Proxies und Zeitschriftenzugang Das Angebot der elektronischen Zeitschriften und Datenbanken wird von den Universitätsbibliotheken weiter ausgebaut. In vielen Fakultäten ist es eine wichtige Informationsquelle für Mitarbeiter und Studenten. Viele Studenten recherchieren auch von zu Hause, da sie inzwischen über einen DSL-Anschluss mit Flatrate verfügen. Auch externe Lehrkrankenhäuser nutzen verstärkt die DocWeb-Webplattform. Webplattform für den Zeitschriftenzugriff Mit der viel genutzten Webplattform DocWeb (http://docweb.lrz.de) können elektronische Zeitschriften auch ohne den Einsatz von VPN genutzt werden. Diese (und damit auch die Zeitschriftenproxies) werden längerfristig durch Einführung des Shibboleth-Authentifizierungssystems abgelöst werden. Da das aber erst schrittweise wegen größerer technischer Umstellungen bei den Verlagen erfolgt, wird der vollständige Umstieg erst in einigen Jahren abgeschlossen sein. Bis dahin werden beide Systeme parallel betrieben. Die Open-Source-Software DocWeb wird seit Ende 2008 vom Entwickler nicht mehr weiter betreut. Es tauchen seitdem vermehrt Probleme mit Webseiten auf, die Java-Script nutzen. Deshalb soll 2010 das System modernisiert werden. Geplant ist, dann die Software EZ-Proxy einzusetzen DHCP-Server Seit ca. 7 Jahren betreibt das LRZ einen DHCP-Dienst, der von allen Münchener Hochschulen für die automatische IP-Konfiguration von institutsinternen Rechnern genutzt werden kann. Außerdem wird dieser Dienst für einige zentrale Anwendungen verwendet, wie z.b. für die WLAN-Zugänge im MWN oder die Netzanschlüsse in Hörsälen und Seminarräumen. Insgesamt wird der DHCP-Dienst von ca. 150 Instituten genutzt und verwaltet dabei 330 Subnetze mit ca IP-Adressen. Falls gewünscht, tragen die DHCP-Server die Namen der Clients auch automatisch in den zuständigen DNS-Server ein (Dynamic DNS).

132 126 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Physikalisch betrachtet besteht der DHCP-Dienst aus drei Servern, von denen sich z.zt. zwei im LRZ- Gebäude und einer im LMU-Stammgelände befinden. Die drei Server bilden zwei Paare, wobei einer der beiden Server im LRZ der primäre Server ist und der zweite Server im LRZ bzw. der im LMU- Stammgelände als sekundärer Server fungiert. Zur Ausfallsicherheit arbeiten die Server redundant, d.h. bei einem Ausfall eines Servers übernimmt der jeweils zweite automatisch die Funktion des anderen. Außerdem findet zwischen den Servern eine Lastteilung statt. Bzgl. DHCPv6 (DHCP für IPv6) fanden im Jahr 2009 erste Tests statt. Im Laufe des Jahres 2010 ist geplant, für diesen Dienst den Produktionsbetrieb aufzunehmen und damit dann auch die automatische Konfiguration von IPv6-Rechnern zu ermöglichen VoIP im Jahr 2009 Insgesamt wurden durch die VoIP-Telefonanlage vom Typ Asterisk ca Gespräche mit einer durchschnittlichen Länge von 2:57 Minuten oder insgesamt ca Gesprächsminuten vermittelt. Dies entspricht einem Gesprächsvolumenzuwachs von ca. 2% im Vergleich zum Vorjahr, wobei die durchschnittliche Dauer der Gespräche um 7 Sekunden anstieg. Es konnten ca Gesprächsminuten direkt über SIP zu externen Teilnehmern abgewickelt werden, was in etwa einer Verdoppelung im Vergleich zum Vorjahr entspricht. Zu den über SIP erreichbaren Zielen gehören die Universitäten Eichstätt, Jena, Regensburg, Wien, Mainz, Mannheim, Würzburg, Innsbruck, Stockholm und der DFN. Weitere Informationen zur VoIP-Telefonanlage, wie z.b. Aufbau und Vermittlungsstatistik, können den Jahresberichten ab 2006 entnommen werden Zugang über UMTS: Vodafone Sponsoring der Exzellenz Universitäten TU München und der Ludwig-Maximilians-Universität München Im Rahmen des Sponsorings mit einem Gesamtvolumen von 5 Mio. Euro in der Laufzeit von 5 Jahren wurden die beiden Münchner Hochschulen Ende 2007 (LMU) bzw. Anfang 2008 (TU) mit UMTSfähigen Geräten für die mobile Sprach- und Datenkommunikation ausgestattet. Damit ist es für mobile Nutzer möglich geworden, sich über einen zentralen VPN-Zugangspunkt mit dem MWN und dem Internet zu verbinden. Eine detaillierte Beschreibung der Technik findet sich im Jahresbericht Im Jahr 2009 waren die ersten zwei Jahre des Vertrages der LMU abgelaufen und so werden die Endgeräte durch die nächste Generation ersetzt. Die PCMCIA / ExpressCard UMTS Modems werden durch USB-Sticks ersetzt. Als Austausch für die anderen Geräte standen folgende Modelle zur Auswahl: HTC Touch Pro (wie VPA, mit ausziehbarer Tastatur für hohe Schreibnutzung) HTC Touch Diamond (wie VPA, mit virtueller Tastatur) Nokia 6300 (nur Telefon-Funktion) Eine Darstellung des übertragenen Datenvolumens ist leider nicht möglich, da die Daten von Vodafone nicht bereitgestellt werden konnten IPv6 im MWN Zum Jahresende waren für 60 (weitere zehn mehr im Zeitraum eines Jahres) MWN-Institutionen IPv6- Subnetze reserviert (darunter neun Studentenwohnheime (zwei mehr in 2009)). Ein Großteil dieser Subnetze ist bereits konfiguriert und in Benutzung. Insbesondere ist hierbei das Wohnheim Studentenstadt zu nennen, welches in Kooperation mit dem Studentenwerk einen eigenen internen ISATAP-Dienst betreibt. Im Laufe des Jahres 2009 erhöhte sich der IPv6-Verkehr auf dem DFN-Übergang erneut um den Faktor 3. Die bereits seit 2007 bestehenden Protokollumsetzer für 6to4 und Teredo, die auch Verkehr für die Benutzer von DFN und Gèant2 bedienen, hatte erneut einen großen Anteil an dieser Steigerung. Im September 2009 wurde der 6to4-Dienst an den DFN ausgegliedert und im Gegenzug der Teredo-Dienst auf eine offizielle Basis gestellt. Insbesondere wird der Datentransfer dieses Dienstes nun über den zweiten X- WiN-Zugang geleitet, um eine Überlastung des primären Links zu vermeiden.

133 Jahresbericht 2009 des Leibniz-Rechenzentrums 127 Abbildung 69 IPv6 Traffic im MWN im Jahre 2009 Die bereits Ende 2008 begonnenen Tests für eine Teilnahme am IPv6 Trusted Tester Program der Firma Google wurden Mitte Januar 2009 erfolgreich beendet und der Dienst in den Produktivbetrieb übernommen. Dieses und weitere IPv6-fähige Ziele im Internet führten zu einer explosionsartigen Steigerung der gleichzeitig aktiven Clients von 250 auf über 1100 Hosts. Davon nutzen etwa 60% den im März MWNweit aktivierten automatischen Tunneldienst ISATAP zum Zugriff auf das IPv6-Netz, während die restlichen 40% bereits über natives IPv6 angebunden sind. Die Anzahl der Endsysteme mit nativem IPv6 stieg laut dem Tool Nyx von 1500 auf Da auch weiterhin aus technischen Gründen nicht alle Geräte erfasst werden können, ist die reale Zahl noch etwas höher anzusetzen. Seit September 2009 steht mit dem neu eingeführten SSLVPN-Client AnyConnect auch ein IPv6-Zugang über VPN zur Verfügung. Aufgrund von noch zu lösenden Inkompatibilitäten mit bestimmten Windows- Versionen ist diese Option noch nicht standardmäßig eingeschaltet, kann jedoch von jedem Nutzer selbst beim Verbindungsaufbau ausgewählt werden. Viele weitere Dienste wurden im Laufe des Jahres aktualisiert und dabei IPv6-fähig gemacht. Exemplarisch sei der redundante NTP-Dienst ntp2.lrz-muenchen.de genannt. Die Planungen für das Jahr 2010 sehen wie bisher das Angebot weiterer Dienste über IPv6 vor. Die bereits in den vergangenen Jahren verfolgte Strategie, IPv6 zum Standarddienst werden zu lassen, wird weitergeführt. So sollen so schnell wie möglich Tests mit dem NAT64-Standard durchgeführt werden, um Systemen in IPv6-only Netzen einen transparenten Zugang zu IPv4-Diensten bereitzustellen. Ebenfalls angedacht ist, die Bereitstellung von IPv6 für bestehende Netze zu forcieren und bei Neukonfigurationen standardmäßig aufzuschalten. 3.3 Management Für das effiziente Management der Netzkomponenten und dienste setzt das LRZ seit vielen Jahren erfolgreich auf eine Kombination aus Standardsoftwarepaketen und gezielt ergänzenden Eigenentwicklungen. Nachfolgend werden die aktuellen Weiterentwicklungen der LRZ-Netzdokumentation sowie der Einsatz kommerzieller Netz- und Dienstmanagementwerkzeuge insbesondere auch die mandantenfähige Überwachung der Dienstqualität im MWN vorgestellt. Anschließend werden aktuelle Weiterentwick-

134 128 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes lungen und Statistiken in den Bereichen Incident, Configuration und Change Management, die bislang durch Remedy ARS unterstützt werden, vorgestellt. Schließlich wird auf die Ausrichtung der LRZ IT Service Management Prozesse nach ISO/IEC und die damit verbundene Toolunterstützung über die iet Solutions ITSM Suite eingegangen Weiterentwicklung und Betrieb der Netzdokumentation In der LRZ Netzdokumentation werden für den Betrieb des MWN relevante Informationen (Netzkomponenten, Subnetze, Ansprechpartner, Räume,...) gespeichert beschränkten sich die Arbeiten an der Netzdokumentation im Wesentlichen auf Pflege und Wartung sowie einige Verbesserungen an der Benutzerschnittstelle Verbesserungen der Netzdokumentation bzw. der WWW-Schnittstelle Folgende Verbesserungen wurden 2009 realisiert: Das Eintragen von doppelten Personen (Personen bei den Nachname, Vorname und - Adresse gleich ist) wird verhindert. Die Bereichsunterteilung von IPv4 Netzen, die bisher nur für /24 Netze möglich war, ist jetzt auch für /25, /26, /27 und /28 Netze möglich. Die VLAN IST Daten Darstellung bei Komponenten wurde verbessert. Es sind jetzt zwei Ansichten verfügbar, VLAN -> Port und Port -> VLAN. In Abbildung 70 ist die Darstellung Port -> VLAN zu sehen, bei der zu jedem Port alle VLANs angezeigt werden. Die Darstellung VLAN -> Port (alle Ports zu jedem VLAN) wurde bereits 2008 realisiert. Bei Änderungen von Subnetzen bzw. Subnetzbereichen bzgl. der ARS Adressvergabe werden die ARS-Administratoren jetzt per über die Änderung benachrichtigt. Abbildung 70 Kompakte Darstellung der VLAN-IST-Daten vom Switch swz6-2wr

135 Jahresbericht 2009 des Leibniz-Rechenzentrums Inhaltliche Aktualisierung der Netzdokumentation Um die Aktualität der Informationen zu den Netzverantwortlichen zu sichern, wurde 2009 wieder eine Benachrichtigung und Überprüfung der Kontaktinformationen durchgeführt. Jeder der 787 Netzverantwortlichen erhielt per die Liste der Subnetze und Subnetzbereiche, für die er zuständig ist und die in der Netzdokumentation gespeicherten persönlichen Daten. Diese Daten sollten entweder bestätigt oder eventuelle Fehler korrigiert werden. An die Netzverantwortlichen, die auch nach einem Monat noch nicht geantwortet hatten, wurde per Skript automatisiert eine zur Erinnerung geschickt. Bei rund 350 Einträgen zu Netzverantwortlichen waren kleinere oder größere Änderungen während der Aktualisierung notwendig. Bei allen anderen Netzverantwortlichen blieben die Einträge unverändert. Neben dieser jährlichen Aktualisierung werden aktuelle Änderungen im MWN laufend in die Netzdokumentation übernommen Netz- und Dienstmanagement Das Netz- und Dienstmanagement bildet die Basis für die Qualität der Netzdienstleistungen des LRZ im MWN. Wesentliche Komponenten des Netz- und Dienstmanagements sind das Konfigurations-, das Fehler und das Performance-Management. Die Aufgaben des Konfigurations- und Fehler-Managements werden im MWN durch den Netzmanagement-Server und der auf dem Server eingesetzten Netzmanagement- Software erfüllt. Die Aufgaben des Performance-Managements werden im Service Level Management Werkzeug InfoVista umgesetzt (siehe nächster Abschnitt) Netzmanagement Software und Netzmanagement Server Im Jahr 2008 wurde der IBM Tivoli Network Manager (ITNM) als neue Netzmanagement-Software ausgewählt. ITNM löst den HP OpenView Network Node Manager 6.4 ab. Der Auswahlprozess und die Gründe für die Wahl von ITNM sind im Jahresbericht 2008 zusammengefasst. Die neueste Version 3.8 des IBM Tivoli Network Manager war Anfang 2009 verfügbar, so dass auf dem ebenfalls neu aufgesetztem Netzmanagement Server (nm2.lrz-muenchen.de) mit einer ersten Test- Installation begonnen werden konnte. Parallel zur Test-Installation wurde mit IBM ein Vertrag bzgl. eines Installations- und Customizing- Supports ausgehandelt. Eine Unterstützung für die Produktivführung von ITNM wurde schon 2008 während der Evaluation aufgrund der mit der Flexibilität der Software einhergehenden Komplexität als notwendig erachtet. Mit IBM wurde deshalb ein Dienstleistungsvertrag über maximal 40 Tage Support für ein Einführungsprojekt vereinbart. In der Installations- und Customizing-Phase traten jedoch mehrere Probleme auf, die die Einführung des Produkts verzögert haben. Die wichtigsten Probleme dabei waren: Als Teil einer Software-Aktualisierung wurde Mitte des Jahres 2009 ein Problem in ITNM induziert, das während der Evaluation noch nicht vorhanden war. Dieses Problem bewirkte, dass die Unterstützung der im MWN eingesetzten HP-Switche nicht mehr funktionierte und damit deren Erkennung fehlerhaft war. Speziell die Behebung dieses Problems durch den IBM Support hat mehr als 3 Monate gedauert. Die Layer 2 Topologie-Erkennung mit ITNM ist abhängig von der korrekten Konfiguration des CDP (Cisco Discovery Protokoll) Protokolls auf den Routern und Switchen. Während der Installation ist im Zusammenhang mit der VLAN Konfiguration auf manchen Switchen ein Problem aufgetaucht, das eine korrekte Erkennung der Topologie verhindert hat. Dieses Problem wurde während der Evaluation 2008 nicht erkannt, weil nur ein Teil der HP-Switche mit einer bestimmten VLAN-Konfiguration davon betroffen sind. Um dieses Problem zu beheben, musste erst die Menge der davon betroffenen Switche erkannt werden und dann auf jedem einzelnen Switch die VLAN-Konfiguration angepasst werden. Die SNMP-MIB-Implementierung der WLAN-Accesspoints ist fehlerhaft. Ein Teil dieser Fehler war zwar schon aus der Evaluation 2008 bekannt, mit einer neueren Firmware-Version der WLAN-APs traten allerdings wieder andere Fehler auf. ITNM musste deshalb so angepasst werden, dass sowohl die alten als auch die neuen Fehler keine größeren Probleme verursachen. Es ist bisher leider nicht gelungen, vom Hersteller der WLAN-APs eine bzgl. der SNMP- Implementierung fehlerfreie Firmware-Version zu bekommen.

136 130 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes ITNM sollte auch die VLAN-Informationen der Netzkomponenten im MWN auslesen. Während der Evaluation hat das mit einer Teilmenge der Netzkomponenten im MWN gut funktioniert. Wird die Erkennung von VLANs aber für das ganze MWN aktiviert, treten Performance- und Stabilitäts-Probleme auf. Ursache ist wahrscheinlich die sehr große Anzahl von mehr als 1300 VLANs im MWN. Aufgrund dieser Probleme kann dieses Feature im MWN vorerst nicht aktiviert werden. Dieser Mangel kann aber zumindest teilweise durch den weiterhin möglichen Zugriff auf die VLAN-IST-Daten in der Netzdokumentation ausgeglichen werden. Aufgrund der oben beschriebenen Probleme (und einiger kleinerer darüber hinaus) konnte mit einem Testbetrieb des IBM Network Managers erst im Dezember 2009 begonnen werden. Bis Ende 2009 konnten folgende Punkte weitgehend erfolgreich abgeschlossen werden: die Layer 2 Topologie-Erkennung des MWN, die Konfiguration der Erreichbarkeits-Abfrage (Polling) der Netzkomponenten, die Konfiguration der Benachrichtigung der Geräte-Administratoren über und SMS über Erreichbarkeitsprobleme, die beim Polling festgestellt wurden. In den Abbildungen sind Screenshots der Anwendung zu sehen. In Abbildung 71 ist die Layer 2 Topologie des gesamten MWN (inklusive des Auswahl-Fensters mit allen konfigurierten Layer 2 Sichten) zu sehen. In Abbildung 72 wird die Layer 2 Topologie des MWN-Backbone dargestellt. Zusätzlich zu den Backbone-Routern sind noch einige Switche von wichtigen Standorten und die Anbindungen an das X- WiN (das deutsche Forschungsnetz) und an das Netz von M-net zu sehen. In Abbildung 73 ist die Event- Konsole des IBM Network Manager dargestellt. Abbildung 71 Layer 2 Topologie des gesamten MWN im IBM Tivoli Network Manager

137 Jahresbericht 2009 des Leibniz-Rechenzentrums 131 Abbildung 72 MWN Backbone im IBM Tivoli Network Manager Abbildung 73 Event-Konsole des IBM Tivoli Network Manager

138 132 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Ein Problem bzgl. der Root Cause Analyse im ITNM (RCA; Korrelation der Erreichbarkeits-Abfrage mit der Layer 2 Topologie) konnte 2009 nicht mehr gelöst werden. Es bewirkt, dass Ausfallmeldungen von Geräten, die hinter dem ursächlich ausgefallenen Gerät liegen, meistens nicht wie erwünscht unterdrückt werden. Die Behebung dieses Problems musste auf 2010 verschoben werden. Daneben sind noch folgende Punkte zur Bearbeitung in 2010 offen: Verarbeitung der SNMP-Traps der Geräte und Benachrichtigung der Geräteadministratoren bei bestimmten (wichtigen) SNMP-Traps der Geräte über und SMS Automatisierung der Layer 2 Topologie-Erkennung (wird derzeit noch manuell angestoßen) Automatisierung des Backups der Anwendung (manuelle Backups sind bereits getestet und funktionieren zufriedenstellend) Automatisches und schnelles Entfernen von abgebauten Geräten aus der Layer 2 Topologie (wird derzeit noch manuell durchgeführt bzw. abgebaute Geräte werden nach mehreren Topologie- Erkennungen durch die Software selbst entfernt) Vervollständigung der Dokumentation der Installation und der Anpassungen von ITNM für das MWN Korrektur einiger verbleibender kleinerer Probleme bzgl. der Layer 2 Topologie-Erkennung Erstellung und Umsetzung eines Benutzerkonzepts (Sichten für Geräte-Administratoren, Sichten für Operateure,...) Behebung verschiedener weiterer kleinerer Probleme Der HP OpenView Network Node Manager wird auch 2010 noch solange im Parallelbetrieb laufen, bis der IBM Tivoli Network Manager die Aufgaben komplett übernehmen kann. Zurzeit werden vom HPOV NNM ca Netzkomponenten und Server (mit netzrelevanten Diensten) überwacht. Vom IBM Network Manager werden derzeit ca Netzkomponenten und Server überwacht. Der Unterschied von ca. 400 erklärt sich daher, dass entschieden wurde, die Mini-Switche der Hochschule München im ITNM nicht mehr zu überwachen. Die Gründe dafür sind die fehlerhafte und unvollständige SNMP-Implementierung dieser Mini-Switche und das an der Komponenten- und Interface-Anzahl orientierte Lizenz-Modell des ITNM. Als Ersatz für den seit 2003 bestehenden alten Netzmanagement Server (nm1.lrz-muenchen.de) und als Hardware Plattform für den Betrieb des IBM Tivoli Network Manager wurde 2009 auch der neue Netzmanagement-Server (nm2.lrz-muenchen.de) in Betrieb genommen. Weitere Funktionen des Netzmanagement Servers sind außerdem: Arbeitsserver für die Geräteadministratoren Zentrales Repository für die Gerätekonfigurationen Notfallzugriff auf Geräte über serielle Verbindungen und analoge Modems Server für diverse Skripte, die für den Betrieb und das Management des MWN benötigt werden WWW-Server zum Netzmanagement Auf einem separaten Webserver sind seit 2002 aktuelle Informationen über die Topologie für die Nutzer des Münchner Wissenschaftsnetzes und die Performance des MWN-Backbone abrufbar. Unter werden Performance-Daten zu den wichtigsten Elementen des MWN (Backbone, X-WiN Anbindung, IPv6 Verkehr, NAT-o-Mat, Demilitarisierte Zone (DMZ) des LRZ, Modem- und ISDN-Zugang, usw.) dargestellt. Die Performance-Daten werden dazu jeweils in Form von MRTG-Statistiken bereitgestellt. MRTG (siehe ist ein Werkzeug zur Überwachung des Verkehrs auf Netzwerkverbindungen, kann aber auch zur Überwachung anderer Kennzahlen eingesetzt werden. Der WWW-Server zum Netzmanagement dient als Schnittstelle zu den Kunden im MWN, um die Netz- Dienstleistung MWN des LRZ transparenter zu machen wurde der Backbone des MWN teilweise umstrukturiert. Deshalb wurde auch eine Anpassung der entsprechenden Übersicht auf dem WWW-Server zum Netzmanagement nötig. Die überarbeitete Grafik ist in Abbildung 74 zu sehen. Sie stellt den aktuellen Stand des MWN-Backbones dar.

139 Jahresbericht 2009 des Leibniz-Rechenzentrums 133 Abbildung 74 MWN-Backbone auf dem Netzmanagement WWW-Server Überwachung der Dienstqualität des MWN mit InfoVista Das Service Level Management Werkzeug InfoVista dient dazu, die Qualität von IT-Diensten zu überwachen und in Form von graphischen Reports darzustellen. Es wird seit dem Jahr 2000 zur Überwachung der Dienstqualität im Münchner Wissenschaftsnetz (MWN) eingesetzt. Das InfoVista System wird ständig an die Entwicklungen im MWN angepasst bzw. Veränderungen im Netz werden in InfoVista übernommen. In 2009 wurden außerdem zwei Reports neu entwickelt; diese werden im Folgenden kurz beschrieben Interface-Durchsatz und -Fehler eines Dienstes Ziel dieses Reports ist es, alle Interfaces, die an der Erbringung eines Dienstes beteiligt sind, kompakt in einem Report darzustellen. Zu jedem Interface wird ein Diagramm des Durchsatzes und von Fehlern auf dem Interface angezeigt. Als Beispiel ist in Abbildung 75 ein Report zur Interface-Anbindung der NAS- Filer dargestellt.

140 134 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Abbildung 75 Report zu Durchsatz und Fehlern an den Interfaces der NAS-Filers Report für AKCP Sensoren In diesem Report werden Temperatursensoren von AKCP abgefragt und ausgewertet. In Abbildung 76 sind als Beispiel die Temperaturwerte von zwei Sensoren im Cisco Nexus Switch zu sehen. Abbildung 76 Report zu den Temperatursensoren am Cisco Nexus Switch Switch-Reports für Netzverantwortliche Die Institute haben mit den Switch-Reports für Netzverantwortliche über die WWW-Schnittstelle Vista- Portal (http://vistaportal.lrz.de) zu InfoVista eine Übersicht über das Gerät und auch über die Port- Auslastung der Switche, an denen sie angeschlossen sind. Durch die Reports wird die Diensterbringung des LRZ transparenter, außerdem kann die Fehlersuche im Institut dadurch erleichtert werden. Die Reports können in HTML-, GIF-, PNG-, PDF-, Text- oder Excel-Format abgerufen werden. Zu den bereits in den Jahren instanziierten Reports für Netzverantwortliche kamen 2009 noch Reports für das Genzentrum der Ludwig-Maximilians-Universität München hinzu VistaPortal Die Version 4.0 SP2 von VistaPortal wurde 2009 getestet und in den Produktionsbetrieb überführt. Im Vergleich zur vorherigen Version 2.2 gab es mehrere kleine Verbesserungen und Fehlerkorrekturen. Insbesondere wurde der Export von Reports in das PDF-Format verbessert.

141 Jahresbericht 2009 des Leibniz-Rechenzentrums 135 Gleichzeitig mit dem Einsatz der neuen Version wurde auch der Server virtualisiert, d.h. der bisherige physische Server wurde durch eine virtuelle Maschine ersetzt Action Request System (ARS) Das Action Request System (ARS) von BMC wird am LRZ seit 15 Jahren für Incident Management, Change Management, Beschaffungswesen, Asset-Management und IP-Adressverwaltung eingesetzt. Da die ARS-Nutzung wegen steigender Mitarbeiterzahl im LRZ zugenommen hat, wurden noch 5 zusätzliche Zugriffslizenzen beschafft. Insgesamt können nun 20 Mitarbeiter parallel ARS verwenden. Die Arbeiten im Jahr 2009 haben sich vorwiegend auf Wartung und Pflege konzentriert. Zahlreiche Schulungen wurden für die Hotline-Mitarbeiter, studentischen Operateure und LRZ-Mitarbeiter zur Benutzung des ARS-Tools und der Formulare durchgeführt. Das Formular KOM-Change-Record (KCR) unterstützt den Change-Management-Prozess in der Abteilung Kommunikationsnetze. Hier werden die Netz-Anschlusswünsche und Wartungsarbeiten erfasst. Am KOM-Change-Record Formular (KCR) wurden folgenden Änderungen vorgenommen: - Automatischer Eintrag des aktuellen Datums beim Schließen eines Tickets. - Automatische Benachrichtigung der Bearbeiter bei Änderungen an Tickets. - Die LRZ-Control Menüleiste wurde um zwei Menüpunkte erweitert: Meine offenen KCRs und Meine inkonsistenten KCRs. - Automatische Benachrichtigung der Bearbeiter per beim Schließen eines KCR. - In der Bearbeitungs-Historie wird jetzt protokolliert, von wem und wann ein KCR geschlossen wurde. - Ein neuer Button Kunden-Informationen in neues KCR kopieren ermöglicht bei gleichen Kunden-Informationen das einfachere Neuerstellen eines KCRs. Es werden Anrede, Vorname, Nachname, Telefon, , Unterbezirk und Institut in das neue KCR kopiert wurden insgesamt 924 (2008: 678) KCR-Tickets abgeschlossen. Am Trouble-Ticket Formular (TT) wurden folgende Änderungen vorgenommen: - Es wurden neue Teams eingetragen: Konfmaster, swadmin, hostmaster, abuse und das BVB- Team. Das Ticket wird beim Erfassen an das jeweilige Team weitergeleitet. Einer der Team- Mitarbeiter kann sich danach das Ticket selbst zuweisen. - Die Bayerische Akademie der Wissenschaften ist an das LRZ Trouble-Ticket-System angebunden worden. Mitarbeiter der Akademie können nun ihre PC-Probleme mittels eines Web- Formulars eingeben. Diese Info wird direkt als Ticket erfasst und die PC-Gruppe im LRZ per Mail benachrichtigt. - Die studentischen Nachtoperateure wurden in die Gruppe Hotline aufgenommen. So ist eine Erfassung und Bearbeitung von Supportanfragen auch in den Abend- und Nachtstunden möglich. - Die Kompetenz der Hotline wurde erweitert. In ihrer neuen Rolle als First-Level-Support darf sie nun Tickets selbständig bearbeiten, mit den Kunden Kontakt aufnehmen, s aus dem System verschicken und die Tickets schließen. Früher war das nur LRZ-Mitarbeitern vorbehalten. Auch in den Masken zum Einzelteil- und IP-Adress-Ticket wurden zahlreiche Detailverbesserungen vorgenommen Übersicht über die Nutzung des Trouble-Ticket Systems Ein Trouble-Ticket dient der Erfassung eines Problems und der Ablaufdokumentation seiner Bearbeitung. Es ist immer einem Verantwortlichen (oder eine Gruppe) zugeordnet. Im Jahr 2009 wurden insgesamt 2966 (Vorjahr: 2620) Trouble-Tickets eingetragen, davon waren: 39 (56) Tickets mit der Dringlichkeit kritisch 2914 (2532) Tickets mit der Dringlichkeit mittel 13 (32) Tickets mit der Dringlichkeit gering Abbildung 77 gibt einen Überblick über die Gesamtanzahl der monatlich erstellten Tickets und verdeutlicht den im Jahre 2009 stark angewachsenen Anteil an Problemmeldungen, die über die Hotline-

142 136 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Webschnittstelle (ARWeb, 1638 Tickets) eingegangen sind. Die Meldungen von Benutzeranfragen per Webschnittstelle werden neben den Nutzern von Standarddiensten ebenfalls von HLRB- und Linux- Cluster-Nutzern intensiv verwendet. Im Jahr 2009 sind 213 HLRB-Tickets und 259 Linux-Tickets per Webschnittstelle im ARS eingetragen worden wurden insgesamt 2110 von 2966 Tickets per Web- Formular erfasst und somit bearbeitet. Abbildung 77 Trouble-Tickets pro Monat Die Diagramme in Abbildung 78 zeigen die Entwicklung der Bearbeitungszeiten von Trouble-Tickets über die letzten drei Jahre hinweg. Abbildung 78 Bearbeitungszeiten von Trouble-Tickets Die Ursache für die extrem lange Bearbeitungszeit von Tickets mit der Priorität niedrig in dem Monat Januar waren Tickets, die länger im Status erfasst waren (anstelle von ausgesetzt) und die erst später

143 Jahresbericht 2009 des Leibniz-Rechenzentrums 137 geschlossen wurden. Aufgrund der geringen Anzahl von Tickets mit niedriger Priorität (13) haben diese Tickets mit langer Bearbeitungszeit auch eine große Auswirkung auf die Jahresübersicht. Abbildung 79 zeigt die Verteilung der Tickets auf Dienstklassen. Der Großteil der Tickets betrifft Netzund Systemdienste. Abbildung 79 Trouble-Tickets, klassifiziert nach Dienstklassen Zu folgenden 10 Diensten wurden die meisten Tickets geöffnet ( Top Ten ): Dienst VPN 383 Linux-Cluster 272 Mail->Anwenderproblem 243 HLRB 208 Verbindungsproblem 155 Benutzerzugang, Verwaltung -> Studentenkennungen Benutzerzugang, Verwaltung -> Mitarbeiterkennungen Mail-> Zentrale Mailserver 70 Directories->MWN Active Directory 68 Dateisysteme -> NAS 59 Anzahl Tickets Übersicht über die Nutzung des Quick-Ticket-Systems (QT) Mit einem Quick-Ticket werden alle Anfragen erfasst, die nicht über ein Formular eintreffen. Bei Bedarf wird zusätzlich ein Trouble-Ticket erzeugt. Die Auswertung dieser Quick-Tickets dient der Ermittlung der Beratungsschwerpunkte und damit der möglichen Verbesserung der Dokumentation oder sonstiger Maßnahmen zur Steigerung der Beratungsqualität und -quantität.

144 138 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Im Jahr 2009 wurden insgesamt 1480 Quick-Tickets (2008: 3015) eingetragen, davon entfielen auf: Dienst Anzahl Tickets telefonische Beratung 1072 (2031) LRZ-Post 247 (642) Präsenzberatung 161 (342) Zu folgenden Diensten bzw. Dienstleistungen wurden die meisten Quick-Tickets erzeugt (in Klammern sind jeweils die Zahlen aus dem Jahr 2008 angegeben): Dienst Anzahl Tickets VPN 69 (186) Verbindungsproblem 28 (23) Mitarbeiterkennungen 20 (18) Studentenkennungen 18 (17) Gastkennungen 15 (68) Ausdruck 7 (17) Benutzeranfragen der Technischen Universität München An der Technischen Universität München (TUM) wurde im Jahr 2008 ein Service Desk eingeführt, der Benutzeranfragen der TUM entgegen nimmt. Diese Benutzeranfragen werden in einem TUM-eigenen Trouble-Ticket-System (OTRS) erfasst. Der TUM-Service-Desk koordiniert diese Benutzeranfragen ggf. mit nachgelagerten Dienstanbietern, wozu auch das LRZ als IT-Dienstleister der TUM gehört. Abbildung 80 Anzahl der von der TUM weitergeleiteten Anfragen in 2009

145 Jahresbericht 2009 des Leibniz-Rechenzentrums 139 Anfragen von TUM-Benutzern für das LRZ werden per an das LRZ weitergegeben. Das führt allerdings dazu, dass die Bearbeitung dieser Benutzeranfragen sowohl auf TUM-Seite als auch auf LRZ- Seite komplexer wird. In Abbildung 80 ist die Anzahl der vom TUM-Service-Desk an das LRZ weitergeleiteten Anfragen (497 Tickets) ersichtlich. Deutlich erkennbar ist auch der Anstieg der Anfragen zu Semesterbeginn ab Oktober IT-Service Management Die Zuverlässigkeit und Verfügbarkeit von IT-Services ist in erheblichem Maß auch von der effektiven Kommunikation, Kooperation und Koordination zwischen den Mitarbeitern des IT-Service-Providers abhängig. Ein optimales Management von IT-Diensten muss folglich über die Überwachung und Steuerung der technischen Komponenten hinaus gehen und auch die betrieblichen Abläufe bzw. die Prozesse des IT-Service-Providers kontrollieren und lenken. Die Ausgestaltung eines solchen prozessorientierten IT-Service-Managements (ITSM) ist Gegenstand sowohl verschiedener so genannter ITSM-Rahmenwerke wie der IT Infrastructure Library (ITIL), als auch des vergleichsweise neuen internationalen Standards ISO/IEC Wie bereits im letzten Jahresbericht dargelegt, arbeitet das LRZ daran, seine ITSM-Prozesse an den Vorgaben von ISO/IEC auszurichten Aktivitäten im Bereich IT-Service-Management am LRZ Der Arbeitskreis IT-Service-Management (AK ITSM) hat zur Aufgabe, ein organisatorisches und technisches Konzept für das ITSM am LRZ zu entwickeln. Er koordiniert die ITSM-Aktivitäten am LRZ, welche jedoch nicht auf Arbeiten innerhalb des Arbeitskreises selbst beschränkt sind. Um prozessspezifische Planungen voranzutreiben, wurden vom AK ITSM im Juli 2009 zwei Prozess-Teams gegründet. Das sogenannte Control Team soll die Koordination zur Implementierung eines LRZ-weiten, d.h. abteilungsübergreifenden Change- und Configuration-Managements übernehmen. Um die Einführung eines ISO/IEC konformen Incident- und Problem-Managements hingegen kümmert sich nun das Resolution Team. Beide Teams bestehen wie der AK ITSM ebenfalls aus Vertretern aller Abteilungen und sind daher auch dafür verantwortlich, den Status der Entwicklungen in den Prozessen dorthin zu berichten. Die wichtigsten ITSM-Aktivitäten im Jahr 2009 sind analog zur Gliederung der ITSM-Planungen im letzten Jahresbericht im Folgenden anhand der drei Hauptaspekte People, Process, Technology (Menschen, Prozesse, Technologie) strukturiert. People Für LRZ-Mitarbeiter fanden 2009 zwei weitere Schulungen zu Grundlagen von ISO/IEC statt. Insgesamt haben sich so mittlerweile über 100 LRZ-Mitarbeiter mit dem erfolgreichen Absolvieren einer durch die TÜV SÜD Akademie durchgeführten Prüfung für das Foundation Certificate in IT Service Management according to ISO/IEC qualifiziert. Schulungen der höheren Ausbildungsstufe, dem Professional Level, im neuen Zertifizierungs- und Lehrgangskonzept für IT-Service-Management nach ISO/IEC haben auch bereits über 10 LRZ-Mitarbeiter besucht und ein entsprechendes Zertifikat erworben. Process Die 2008 eingeführten KOM Change Records (KCRs) zur Koordination von Neuanschlüssen, Installationen und Wartungsarbeiten haben sich erfolgreich etabliert und wurden daher konsequent weiterentwickelt. Die Erfahrungen, die durch die KCRs gewonnen werden, sollen nun bei der Planung und Einführung eines abteilungsübergreifenden Change-Managements mit einfließen. Da das ITSM-Projekt als nahes Ziel die Einführung der Control- und Resolution-Prozesse als Schwerpunkt hat, wurden 2009 zunächst die entsprechenden Prozessmanager (Process Managers) und Prozessverantwortlichen (Process Owners) benannt. Die Rollen der Prozessmanager werden aus Mitgliedern der entsprechenden Prozess-Teams belegt, wohingegen sich die Prozessverantwortlichen aus dem Kreis der LRZ-Leitung rekrutieren wurde am LRZ erstmals auch ein Verfahren definiert, das eine geeignete und kontrollierte Reaktion auf Störungen größerer Auswirkung, den sogenannten Major Incidents, beschreibt. Als Major Incident

146 140 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes wurden Störungen definiert, welche sich auf kritische Dienste auswirken oder einen sehr großen Nutzerkreis betreffen. Ein dafür ins Leben gerufener Arbeitskreis (AK Continuity) hat erarbeitet, wie derartige Störungen behandelt und in kontrollierter Weise behoben werden können. Nach erfolgreicher initialer Definition dieses Verfahrens ist die Verantwortung über die kontinuierliche Verbesserung Ende 2009 an das Resolution-Team und den Prozessmanager Incident-Management übergegangen. Als konsequente Weiterentwicklung hiervon wurde Ende 2009 auch ein Verfahren eingeführt, welches proaktiv das Auftreten von Major Incidents nach Infrastrukturänderungen verhindern und die unerwünschten Auswirkungen auf die Kunden verringern soll. Dieses Verfahren für Major Changes legt fest, wie bei anstehenden größeren Änderungen an der IT-Infrastruktur vorgegangen werden soll. Dabei sollen im Sinne einer Risikoanalyse die möglichen Auswirkungen von Änderungen auf die Dienste abgeschätzt und die Kunden gezielt über möglicherweise anstehende Dienstausfälle informiert werden. Auch schreibt das Verfahren vor, einen Change-Koordinator zu ernennen, welcher die Abstimmung des Changes überwacht und zu jedem Zeitpunkt über den Status und die vorausichtliche Dauer der Wartungsarbeit informiert ist. Dadurch können die Administratoren, die den Change technisch durchführen, entlastet werden und sich komplett auf die Implementierung des Changes konzentrieren. Technology: Einführung der ITSM-Suite Nachdem 2008 vor allem die Evaluation und Auswahl einer entsprechenden ITSM-Suite zur Unterstützung eines an ISO/IEC ausgerichteten, prozessorientierten IT-Dienstmanagements im Fokus stand (siehe Jahresbericht 2008), wurde 2009 in erster Linie die Einführung dieser Suite geplant und vorbereitet. Wie 2008 schon angedeutet, hat sich die Auswahl des entsprechenden Produktes noch bis Ende des ersten Quartals 2009 hingezogen. Anfang April wurde dann die Entscheidung für ein Produkt getroffen und die ITSM-Suite von iet Solutions beschafft. Für Administration und Anpassung wurden zwei Teams gebildet. Das Administrator-Team ist verantwortlich für den technischen Betrieb der Suite. Das zweite Team kümmert sich um Entwicklungen, so dass das Tool auf die Anforderungen und die Prozesse des LRZ angepasst wird. Entsprechende Schulungen der Teams wurden in Zusammenarbeit mit iet Solutions durchgeführt. Das Entwickler-Team ist darüber hinaus in beiden Prozess-Teams vertreten und kann somit die Anforderungen an die Prozesse gezielt umsetzen. Auch kann dadurch Feedback in die Prozess-Teams einfließen, so dass ein effektives Zusammenspiel zwischen Prozessen und Tool erreicht werden kann. Technology: Schritte hin zu einem übergreifenden IT-Management-Werkzeugkonzept Wie im Jahresbericht 2008 bereits beschrieben setzt das LRZ historisch bedingt viele Werkzeuge für die verschiedenen klassischen Aspekte des IT-Managements (Netzmanagement, Systemmanagement usw.) ein. Basierend auf den Vorarbeiten von 2008 wurden 2009 nun konkrete Aktivitäten geplant, um ein LRZ-übergreifendes Konzept für eine konsolidierte Tool-Landschaft zu entwickeln. Als wichtiger Erfolgsfaktor für ein effektives und effizientes Werkzeugkonzept wurde die Realisierung von LRZ-weit gültigen Prozessen für Informationsmanagement und Configuration-Management identifiziert. Nur durch optimale Integration von Information und Bereitstellung konsistenter Dokumentation lassen sich Konsolidierungen von Tools und Optimierungen erreichen. Um diesen Anforderungen Rechnung zu tragen, wurde zusätzlich zum bereits existierenden Control-Team der Arbeitskreis Informationsmanagement gegründet. Im ersten Schritt wurden durch den Arbeitskreis Interviews mit einer Vielzahl von LRZ-Mitarbeitern durchgeführt, um ein möglichst exaktes Bild von der Dokumentations- und Informationsstruktur am LRZ zu gewinnen. Als Ergebnis wurden 38 Informationsquellen identifiziert, welche Daten für Verfahren oder Prozesse bereitstellen und somit den Scope des Arbeitskreises definieren. Im nächsten Schritt soll nun eine Struktur definiert und eine Richtlinie veröffentlicht werden, welche es ermöglicht, die Anzahl der Informationsquellen zu reduzieren und klare Angaben zu machen, wo und wie Informationen abgelegt werden sollen Weitere Aktivitäten im Bereich IT-Service-Management Auch 2009 wurden für Studenten der LMU und der TU München in Zusammenarbeit mit dem Lehrstuhl Prof. Hegering / Prof. Kranzlmüller zwei Seminare zum Thema prozessorientiertes IT-Service Management angeboten. Wie bei den Schulungen für die Mitarbeiter des LRZ, gab es auch für die Studenten die

147 Jahresbericht 2009 des Leibniz-Rechenzentrums 141 Möglichkeit, im Anschluss an das Seminar die Prüfung Foundation in IT Service Management according to ISO/IEC abzulegen und das entsprechende Zertifikat zu erwerben. Getrieben durch die aktuellen Reformen im tertiären Bildungsbereich (Bologna, Bachelor- und Master, Studiengebühren etc.) sowie den zunehmenden Wettbewerb sind die Geschäftsprozesse an Hochschulen einem starken Veränderungsdruck ausgesetzt. Aus diesem Grund hat sich das itsmf (IT Service Management Forum Deutschland e.v.) entschieden, einen entsprechenden Arbeitskreis zu gründen und den Erfahrungsaustausch zum Thema ITSM unter den Hochschulen zu forcieren. Das LRZ ist seit der Gründung dieses Arbeitskreises aktiv an dessen Gestaltung beteiligt. Auch ist das LRZ mit Herrn Prof. Dr. Heinz-Gerd Hegering und Herrn Dr. Michael Brenner im Komitee für die IT-Personenzertifizierung nach ISO/IEC vertreten. Im Rahmen dieses Komitees wurde das Rahmenkonzept für Schulungen, Prüfungen und IT-Personenzertifizierung nach ISO/IEC festgelegt und wird kontinuierlich weiterentwickelt. 3.4 Sicherheit Durch die gezielte Kombination aus der Bereitstellung von Werkzeugen zur Prophylaxe und der kontinuierlichen Überwachung des Netzbetriebs konnten die Auswirkungen IT-sicherheitsrelevanter Vorfälle auch in diesem Jahr erfreulich gering gehalten werden. Im Folgenden werden zunächst das am LRZ entwickelte Intrusion Detection und Prevention System Nat-o-Mat und sein derzeit im Aufbau befindliches Nachfolgesystem Secomat beschrieben. Daran anschließend wird auf das neu in Betrieb genommene Security Information und Event Management System OSSIM sowie die zentralen Logserver und Sperrlisten eingegangen. Ferner werden die Mechanismen zum Monitoring am WiN-Zugang und das ebenfalls am LRZ entwickelte Sicherheitswerkzeug Nyx vorgestellt. Abrundend wird ein Überblick über die auf großes Kundeninteresse stoßende Dienstleistung virtuelle Firewalls gegeben NAT-o-MAT/Secomat Im Münchner Wissenschaftsnetz (MWN) werden mehr als IP-Endsysteme betrieben. Neben Servern sind hauptsächlich Arbeitsplatzrechner oder Notebooks angebunden. Dabei werden nicht alle Systeme von Firewalls und Antiviren-Programmen geschützt, wodurch sich Schadprogramme oft schnell und ungehindert verbreiten können. Ein Anteil von nur einem Prozent an infizierten Rechnern bedeutet rund 680 potentielle Verursacher von Sicherheitsproblemen. Die Bearbeitung dieser Fälle stellt einen erheblichen personellen Aufwand dar. Um dieser Problematik zu begegnen, wurde am LRZ ein dynamisches, proaktives und generisches Intrusion Prevention System (IPS) mit einer Komponente zur dynamischen Beschränkung der Datenübertragungsrate entwickelt. Dieses System befindet sich - unter der Bezeichnung NAT-o-MAT - seit Mitte 2005 erfolgreich im produktiven Einsatz (technische Details siehe Jahresbericht 2007) begann die Weiterentwicklung des NAT-o-MAT unter dem Projektnamen Secomat. Bewährte Komponenten des Systems werden beibehalten oder aktualisiert und in die Jahre gekommene oder unhandliche Komponenten werden ersetzt. So wurde z.b. jetzt ein Standard-Linux-Kernel verwendet, um die Wartbarkeit zu verbessern, auf die proprietäre Botnet-Erkennung verzichtet oder die nicht mehr weiterentwickelte Klassifzierung von Peer-to-peer-Protokollen entfernt. In diesem Zusammenhang wurde auch VMware als alternative Plattform getestet. Die Tests zeigten jedoch deutlich, dass VMware für netzintensive Dienste mit der Vermittlung sehr vieler IP-Pakete keine geeignete Plattform ist. Deshalb setzt auch der neue Secomat-Cluster wie sein Vorgänger auf dedizierte Server-Hardware auf. Das Lastverteilungssystem wurde komplett erneuert und ist nun nicht mehr von Policy Based Routing (PBR) auf den Core-Routern abhängig. Damit wird die Flexibilität bei der Disposition von Cluster-Nodes stark erhöht. Der Secomat-Cluster besteht gegenwärtig aus 3 Nodes, die parallel zum alten NAT-o-MAT-Cluster arbeiten und diesen durch Übernahme von ca. 25% des Verkehrs entlasten. Nach Abschluss der Secomat- Entwicklung wird der NAT-o-MAT-Cluster abgeschaltet. Die Abbildungen zeigen eingehende Datenübertragungsrate, ausgehende Datenübertragungsrate und gesperrte Benutzer der 3 Knoten des Secomat-Clusters und des NAT-o-MAT-Clusters im Zeitraum von einer Woche.

148 142 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Abbildung 81 secomat1 Abbildung 82 secomat3 Abbildung 83 secomat4 Abbildung 84 natomat1 Abbildung 85 natomat2 Abbildung 86 natomat3 Weitere Informationen zum NAT-o-MAT sind zu finden unter Security Information und Event Management (SIEM) Neu am Leibniz-Rechenzentrum ist eine Security Information und Event Management (SIEM) -Lösung auf Basis von AlienVault OSSIM (Open Source Security Information Management). OSSIM bietet eine Zusammenstellung verschiedener Open-Source Security-Sensor- (z.b. Snort IDS) und Security- Monitoring-Werkzeuge (z.b. NTOP, Arpwatch). In einer webbasierten Oberfläche werden sicherheitsrelevante Ereignisse grafisch dargestellt. Der Administrator kann sich einerseits schnell und einfach einen Überblick über die aktuelle Sicherheitslage verschaffen, andererseits aber auch Detailinformationen zu allen Events abfragen.

149 Jahresbericht 2009 des Leibniz-Rechenzentrums 143 Abbildung 87 Dashboard Alienvault Ossim Besonders herauszustellen ist die Möglichkeit zur Korrelation von Security-Events, selbst von verschiedenen Sensorquellen. Beispielsweise können Angriffe, welche das Intrusion Detection System meldet, automatisiert korreliert werden mit Schwachstellen, die auf dem Zielsystem des Angriffs vorhanden sind. Dies erlaubt, Security-Events entsprechend zu priorisieren. Neben Eventkorrelation bietet OSSIM die Möglichkeit, Aktionen bzw. Reaktionen bei Auftreten von sicherheitskritischen Ereignissen zu definieren. So können dem jeweils zuständigen Netzverantwortlichen automatisiert Auffälligkeiten, verursacht durch ein z.b. vireninfiziertes System, entweder gemeldet oder bei wiederholter Auffälligkeit bzw. sehr kritischen Ereignissen die IP-Adresse des Systems automatisch gesperrt werden. In diesem Zusammenhang ist die aktive und erfolgreiche Bekämpfung des Conficker-Wurms im Münchner Wissenschaftsnetz zu nennen. Infizierte Systeme wurden dem LRZ täglich per automatischer Warnmeldung, einem Service des DFN-CERT, mitgeteilt. Durch flexibles Monitoring am X-WIN-Übergang in Kombination mit der neuen SIEM-Lösung war das LRZ in der Lage, infizierte Systeme in Echtzeit zu melden. Diese sehr zeitnahe Reaktion erlaubte auch die Identifikation infizierter Systeme, die nur kurze Zeit per WLAN oder VPN verbunden waren. Eine entsprechende Hinweismeldung erfolgte in diesem Fall direkt an den betroffenen Nutzer Zentraler Log-Server Analyse von Missbrauchsfällen und Trouble-Shooting von Netzstörungen gestalten sich wesentlich einfacher, wenn Log-Daten der beteiligten Netzkomponenten zentral vorliegen. Sowohl die manuelle als auch die automatische Auswertung der Log-Daten profitieren davon, dass kein Spezialwissen über Ablageort oder Zugangsmöglichkeit nötig ist. Darüber hinaus schützt eine zentrale Kopie der Log-Daten vor nachträglicher Manipulation auf den jeweiligen Netzkomponenten im Fall einer Kompromittierung. Als Plattform wird ein virtueller Linux-Server unter VMware genutzt. Ein standardkonformer Syslog- Dienst nimmt die Syslog-Meldungen der verschiedenen Netzkomponenten entgegen und verteilt sie auf die zugehörigen lokalen Dateien. Syslog ist ein weit verbreiteter Standard für Log-Meldungen. Für Netzkomponenten, deren Log-Meldungen nicht dem Syslog-Standard entsprechen, wird ein Transformationsmechanismus vorgeschaltet. Ein automatischer Rotationsmechanismus sorgt dafür, dass entweder stündlich oder täglich eine neue Log-Datei angelegt wird. Die stündliche Rotation ist dann erforderlich, wenn von einer Netzkomponente sehr viele Syslog-Meldungen generiert werden. Derselbe Mechanismus gewährleistet auch, dass Log- Dateien aus Datenschutzgründen nicht länger als 7 Tage vorgehalten werden. Dieser Zeitraum entspricht einer Empfehlung des Deutschen Forschungsnetzes (DFN), die auf der aktuellen Rechtsprechung basiert. Von dem jeweils aktuellen 7-Tage-Ausschnitt wird zudem ein Backup gemacht (TSM). Auch hier wird dafür gesorgt, dass keine älteren Backups existieren.

150 144 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Zentrale Sperrliste Durch verschiedene verteilte Sensoren wird versucht, kompromittierte Rechner im Münchner Wissenschaftsnetz (MWN) zu detektieren. Abhängig von der IP-Adresse wird derzeit an 2 Stellen im Netz mit unterschiedlichen Mechanismen der Verkehr zu diesen Rechnern unterbunden. Ziel ist es, die Anzahl der Sensoren zu erhöhen und so nah wie möglich an die Rechner im MWN heranzurücken, damit eine Kompromittierung frühzeitig bemerkt wird. Um den Verkehr zu einem so entdeckten kompromittierten Rechner möglichst effizient zu unterbrechen, muss sich die Sperrkomponente ebenfalls nah beim Delinquenten befinden. Diese Bedingung führt dazu, dass die Anzahl der Sperrkomponenten ebenfalls steigt. Für die Verwaltung der IP-Adressen aktuell kompromittierter Rechner im MWN wurde eine zentrale, datenbankgestützte (MySQL) Sperrliste entwickelt. In diese Sperrliste tragen die Sensoren IP-Adressen entdeckter Rechner ein und Sperrkomponenten lesen die für sie relevanten Informationen aus, um automatisch und zeitnah entsprechende Sperrfilter zu aktivieren. Wenn ein Rechner wieder in Ordnung ist, wird dies entsprechend in der Sperrliste vermerkt und in der Folge die zugehörigen Sperrfilter wieder entfernt. Derzeit ist die Schnittstelle zur Sperrliste skript-basiert (Perl), d.h. durch die Verwendung einer Programmbibliothek stehen Funktionen für den Zugriff auf die Sperrliste zur Verfügung. Zukünftig wird der Zugriff zentral über eine XML-Schnittstelle eines Application-Servers realisiert werden. Die Sperrliste ist so konstruiert, dass sie nicht nur Sperr- und Entsperrinformationen enthalten kann, sondern auch eine Falldokumentation ermöglicht. So können Zwischenschritte von der Sperrung bis zur Entsperrung, z.b. eine Bestätigung von erfolgreichen Gegenmaßnahmen durch den zuständigen Verwalter des betroffenen Rechners, eingebaut und dokumentiert werden Monitoring am X-WIN-Übergang Am WiN-Übergang wird ausgehender und eingehender Verkehr des MWN analysiert. Der Schwerpunkt liegt dabei auf dem ausgehenden Verkehr. Zur Analyse des Netzverkehrs werden zwei Verfahren verwendet: Vergleich mit Angriffssignaturen Statistische Verfahren Erkennen von Auffälligkeiten in outbound Traffic: Automatische Sperrung von auffälligen FTP-Servern SSH-Portscans (d.h. Verbindungsversuche zu externen Rechnern auf TCP-Port 22 mit einer Rate von mindestens 60 Verbindungsversuchen/Minute) Viren-infizierte Systeme (Conficker, Torpig, Bredolab) Erkennung von allgemeinen Portscans und Denial-of-Service-Angriffen Erkennung von ungewöhnlich hohen ausgehenden Datenvolumina Erkennen von Auffälligkeiten in inbound Traffic: Auf externe Ziele gerichtete SSH-Portscans weisen meist auf eine Infektion mit Schadsoftware hin. Demgegenüber werden am X-WiN-Übergang auch die meist in der Breite durchgeführten SSH-Scans auf MWN-interne Ziele erkannt. Das Monitoring am X-WiN-Übergang war 2009 überwiegend geprägt von der Kommunikation MWNinterner, Conficker-infizierter Systeme. Insgesamt 391 betroffene Rechner konnten detektiert werden. In nur einem Fall handelte es sich um einen False-Positive, d.h. einen Fehlalarm. In Kombination mit der neu eingeführten Security Information und Event Management Lösung konnten diese Systeme dem jeweils zuständigen Administrator automatisch gemeldet und bei erneuter Auffälligkeit gesperrt werden, bis das System bereinigt war.

151 Jahresbericht 2009 des Leibniz-Rechenzentrums Sicherheitswerkzeug "Nyx" Nyx ist ein Sicherheits- und Netzwerkmanagementwerkzeug, mit dem einzelne Rechner im MWN lokalisiert werden können, d.h., man bekommt nach Eingabe einer bestimmten MAC- oder IP-Adresse eines Rechners den Switch und den Port gemeldet, an dem der Rechner angeschlossen ist. Dafür müssen ca. 900 Switche im MWN und 11 Router alle 5 Minuten abgefragt werden, um keine Daten zu verlieren. Deshalb ist Nyx massiv parallel aufgebaut. Um irrelevante Daten auszufiltern ist die Kenntnis der Topologie notwendig. Die Erkennungen erfolgt mit einem maschinellen Lernalgorithmus, dessen Genauigkeit im Schnitt bei über 95% liegt. Seit 2007 läuft das Projekt produktiv und wird vor allem im Abuse-Bereich, aber auch zur Fehlersuche im Netzbereich verwendet. Das Projekt steht als Open-Source-Software (http://www.nyx.lrz.de ) allen zur Verfügung. Nyx wurde Ende Mai 2007 auf der 21. DFN-Arbeitstagung (http://dfn2007.uni-kl.de/) in Kaiserslautern vorgestellt. Der Vortrag und das wissenschaftliche Papier ( Die Suche nach der Nadel im Heuhaufen ) können unter eingesehen werden. Nyx wird bisher aus Datenschutzgründen nur LRZ-intern verwendet. Immer mehr Netzverantwortliche aus dem MWN fragen aber nach, ob sie diesen Dienst nicht auch selbstständig z.b. zur Fehlersuche nutzen könnten. Deshalb wurde 2009 mit der Entwicklung einer mandantenfähigen Plattform für Netzverantwortliche begonnen, die ins LRZ-ID-Portal integriert wird. NeSSI (Network Admin Self Service Interface) soll Netzverantwortlichen Werkzeuge zur eigenständigen Nutzung für ihre Bereiche zur Verfügung stellen. Das Erste wird Nyx sein. Als weitere Werkzeuge sind Einsehen der per DHCP vergebenen IP- Adressen und das Freigeben von gesperrten IP-Adressen am X-WiN-Anschluss geplant. Der produktive Betrieb soll 2010 aufgenommen werden. Seit Herbst 2009 läuft ein Pilotbetrieb mit ausgewählten Netzverantwortlichen Virtuelle Firewalls Das LRZ betreibt 5 Cisco Firewall Service Module (FWSM), die sich auf verschiedene Backbone-Router im Münchner Wissenschaftsnetz (MWN) verteilen. Derzeit werden damit rund 60 Kunden mit virtuellen Firewalls (VFW) bedient. Das FWSM im LRZ-Haus-Router beherbergte auch die VFWs für LRZ-IP- Netze. Durch die maximale Datenübertragungsrate von ca. 6 Gbit/s der FWSMs konnten bisher bestimmte Netzbereiche (z.b. Backup-Server oder Linux-Cluster) nicht durch VFWs geschützt werden. Deshalb wurde dieses FWSM durch eine Cisco Appliance, eine ASA ersetzt. Die ASA verfügt über 4 10GE-Interfaces und schafft im Normalfall eine maximale Datenübertragungsrate von 10 Gbit/s. Mit sehr großen Datenpaketen (Jumbo Frames) sind sogar 20 Gbit/s möglich. Die Funktionalität entspricht größtenteils der des FWSMs, so dass die Umstellung keinen wesentlichen Zusatzbedarf an Personalresourcen erzeugte. Auch die Benutzerschnittstelle per Web-Interface kennt man bereits vom FWSM. Abbildung 88 Web-Schnittstelle Adaptive Security Device Manager (ASDM)

152 146 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Hier gibt es sogar IPv6-Konfigurationsmöglichkeiten, die beim FWSM noch vermisst wurden. Durch das erweiterte Einsatzgebiet für VFWs ist nun eine weitere Homogenisierung der Firewall-Landschaft im LRZ möglich. 3.5 Projektarbeiten im Netzbereich D-GRID Unter Grid-Computing versteht man die kollektive und kollaborative Nutzung weltweit verteilter heterogener Ressourcen wie z. B. Rechner, Software, Daten, Speicher aber auch wissenschaftliche Instrumente oder Großgeräte (z. B. Beschleunigerring am CERN, astronomische Teleskope) u.ä. Das Grid-Computing wird seit September 2005 im D-Grid-Projekt vom Bundesministerium für Bildung und Forschung gefördert. Die Förderung des BMBF verteilt sich auf wissenschaftliche Verbundprojekte, die Grids nutzen, die so genannten Community-Projekte (CPs), und ein Verbundprojekt von Partnern, die Grid Infrastrukturen entwickeln und betreiben und den Community-Projekten zur Verfügung stellen. Das letztgenannte Projekt wird als D-Grid-Integrationsprojekt (DGI-I) bezeichnet. Das DGI-I hat eine Kern- Grid Infrastruktur geschaffen, auf der die existierenden Community-Projekte basieren. Ziel war der Aufbau einer nachhaltigen Grid-Basisinfrastruktur, die den Anforderungen der Communities gerecht wird. Nachdem das Projekt 2007 endete, wurde Mitte des Jahres 2007 ein Nachfolgeprojekt DGI-II beantragt und bewilligt. Das DGI-II Projekt startete zum Das LRZ wird mit knapp 3 Mitarbeitern über die Laufzeit von 36 Monaten gefördert. Das primäre Ziel von DGI-II ist die Überführung der bisher entwickelten Technologien in ein nachhaltig zu betreibendes Grid. Neben diesem Projekt wurden auch zwei weitere Projekte aus dem 2. Call im Jahr 2009 bearbeitet, bzw. abgeschlossen. Die Tätigkeiten in den Projekten D-MON und GIDS werden im Folgenden dargestellt. Die Koordination und Leitung dieser Teilprojekte liegt bei der Gruppe Netzplanung. Die Arbeiten im DGI-II Projekt FG 1-2, FG 2-3 und FG 2-4 werden fachlich und inhaltlich in der Abteilung HLS bearbeitet. Die anderen Teilprojekte werden in enger Zusammenarbeit mit der Ludwig-Maximilians- Universität München (Lehrstuhl Prof. Hegering und Prof. Kranzlmüller) durchgeführt D-MON Das Projekt horizontale und vertikale Integration des Ressourcen- und Dienstmonitorings (D-MON) beschäftigte sich mit der Entwicklung eines Middleware-übergreifenden Monitoringsystems. Im D-Grid werden die Middleware-Technologien Globus GT4, UNICORE und glite unterstützt. Dies ist ein Alleinstellungsmerkmal und für andere Grid-Projekte weltweit nicht üblich. Allerdings bringt dies für das Monitoring auch Probleme mit sich. Im Grunde wird ein Monitoringsystem benötigt, das alle drei Middleware-Varianten unterstützten kann und in der Lage ist, eine einheitliche Sicht auf Systeme und Ressourcen zu bieten, unabhängig davon, welche Middleware benutzt wird. Die Entwicklung eines derartigen middleware-übergreifenden Systems (horizontale Integration) ist ein Ziel von D-MON. Das zweite Ziel, das sich unter dem Begriff der vertikalen Integration subsumieren lässt, ist die durchgehende Unterstützung von VO (Virtuelle Organisationen)-Informationen. Das D-Grid unterstützt viele sogenannte Virtuelle Organisationen. Für eine VO ist es wichtig, im Hinblick auf das Monitoring nur die Daten zu sehen, die auch die entsprechende VO betreffen. Im Jahr 2009 wurde das D-MON Projekt erfolgreich abgeschlossen, nachdem ein Architekturkonzept (siehe Abbildung 89) für die Realisierung des D-MON Systems entwickelt und ein umfassendes Testbed aufgesetzt wurde, das verteilt bei den beteiligten Projektpartnern betrieben wird und das Architekturkonzept prototypisch umsetzt. Um eine für alle Grid Nutzer und Dienste verwendbare middlewareübergreifende Monitoring-Plattform zu realisieren, setzt D-MON auf eine zentrale Datenbank zur Speicherung der Monitoringdaten, welche von Adaptoren und Transformatoren prinzipiell aus jedem vorhandenen Informationssystem der verschiedenen Middlewares extrahiert und in die Datenbank eingefügt werden. Der Zugriff auf die gesammelten Monitoring-Daten ist über eine Grid-konforme Schnittstelle für Datenbanken (OGSA-DAI) vorgesehen.

153 Jahresbericht 2009 des Leibniz-Rechenzentrums 147 Abbildung 89 D-MON Architektur D-MON stellt den Communities und Virtuellen Organisationen eine VO-spezifische Sicht auf ihre Ressourcen und nur ihre Ressourcen bereit. Dies ist wegen der großen Anzahl an Communities im D- Grid, die dieselben Ressourcen verwenden, absolut notwendig. Die vertikale Integration in D-MON erzielt die Integration von VO-spezifischen Informationen in die Monitoring-Architektur sowie mit der Bereitstellung dieser Informationen. Diese vertikale Integration beinhaltet auch die Entwicklung von Gridsphere-Portlets für die Darstellung in Nutzerportalen. Das resultierende System bietet dynamische, VO-basierte und Nutzer-spezifische Sichten auf die bereitgestellten Ressourcen und Dienste. Dies kann dadurch erreicht werden, dass VO-Management- Informationen mit den Monitoring-Informationen, die von den Informationssystemen (CIS, MDS 4 und BDII) der Middlewares bereitgestellt werden, verknüpft werden. De facto wirkt diese Zusammenführung der Daten als eine Art Filter, der es ermöglicht, relativ einfach Sichten auf virtuelle Organisationen zu erstellen. Adapter, die verschiedenen Informationssysteme und Architekturen verbinden, ermöglichen einen Grid-weiten und Middleware-übergreifenden Einsatz. Diese Komponenten - ein Filter auf der einen Seite und Adapter auf der anderen - werden im D-MON Projekt realisiert. Einen Eindruck von den im D- MON-Portal zur Verfügung stehenden Informationen gibt Abbildung 90. Mit dem erfolgreichen Abschluss des Projekts wurde wie geplant im Rahmen von DGI-II FG 2-3 (siehe unten) damit begonnen, die produktive D-MON-Infrastruktur am LRZ in den Regelbetrieb zu überführen.

154 148 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Abbildung 90 D-MON Portal GIDS Zur Sicherung der Nachhaltigkeit einer deutschlandweiten Grid-Infrastruktur ist insbesondere der Bereich des Sicherheitsmanagements zu berücksichtigen. Das GIDS-Projekt hat die Entwicklung, Projektierung und Inbetriebnahme eines Grid-basierten, föderierten Intrusion Detection Systems (GIDS) sowie die Überführung des GIDS in den D-Grid Produktionsbetrieb zum Ziel. Die Vision von GIDS ist es, einzelne Sicherheitssysteme, die von Ressourcenanbietern betrieben werden, zu kombinieren, um eine globale Sicht auf Sicherheitsvorfälle im Grid zu erhalten. Das Projekt, das zum begonnen wurde, wird als GAP-Projekt im Rahmen des D-Grids vom Bundesministerium für Bildung und Forschung gefördert. Die Projektlaufzeit beträgt 36 Monate und wird neben dem LRZ vom Regionales Rechenzentrum für Niedersachsen (RRZN) und der DFN-CERT Services GmbH durchgeführt, mit den assoziierten Partnern Stonesoft GmbH und Fujitsu Technology Solutions GmbH, wobei die Konsortialführung beim LRZ liegt Problemstellung Im D-Grid bieten Firewalls derzeit keinen umfassenden Schutz für die Grid-Infrastruktur. Aufgrund fehlender Mechanismen zur dynamischen Erkennung und Freischaltung von Kommunikationsanforderungen müssen große Portbereiche zum Teil sogar ohne einschränkende Angabe von IP-Adressen permanent freigegeben werden. Um die Computersysteme nicht ganz ohne Schutz den Bedrohungsszenarien auszusetzen, müssen andere Mechanismen, wie Intrusion Detection Systeme, verwendet werden. Bei den momentan existierenden Produkten und Implementierungen von Intrusion Detection Systemen werden jedoch viele Besonderheiten, die im D-Grid vorhanden sind, nicht beachtet. Die hohe Dynamik an verfügbaren Ressourcen, sowie hoch dynamische Nutzergruppen und Virtuelle Organisationen (VO) machen den globalen Einsatz bestehender Produkte unmöglich. Ein weiteres Problem ist, dass die zum Teil bereits von den beteiligten Organisationen eingesetzten Sicherheitskomponenten und -werkzeuge zur Erkennung von Angriffen unterschiedlichster Art sind. Daher muss von weitestgehend inkompatiblen Schnittstellen, uneinheitlichen Software-Architekturen, Informationsmodellen und Datenaustauschformaten ausgegangen werden. Somit ist häufig keine einfache Koppelung bestehender Komponenten möglich und der Grid-weite Austausch von Informationen bezüg-

155 Jahresbericht 2009 des Leibniz-Rechenzentrums 149 lich sicherheitsrelevanter Ereignisse wird nicht umgesetzt. Dies ist jedoch nicht nur auf die Heterogenität in diesem Umfeld zurückzuführen, sondern auch auf Randbedingungen wie zum Beispiel unterschiedliche Sicherheits- und Informationsverbreitungsrichtlinien ( security and information sharing policies ) der beteiligten Organisationen. Abbildung 91 skizziert die momentane Bedrohungslage für die Strukturen im D-Grid ausgehend von einigen von uns untersuchten Bedrohungsszenarien. Dabei stellen Szenarien in der Mitte das größte Risiko dar und am Rand liegende entsprechend das kleinste. Das Risiko eines Szenarios wächst hierbei mit Zunahme der Wahrscheinlichkeit des Eintretens, Aufwand der Abwehr und des potentiellen Schadens. Die hierbei entstandenen vier Kategorien von Bedrohungsszenarien sind nicht als unabhängig zu betrachten. Sie entsprechen einer im Rahmen der Bedrohungsanalyse vorgenommenen Einteilung für die direkten Ziele einer Bedrohung. Die betrachteten Bedrohungsszenarien erheben keinen Anspruch auf Vollständigkeit, stellen aber die wesentlichen Bedrohungen für die im D-Grid verfügbaren Ressourcen dar. Abbildung 91 Risikobetrachtung für ausgewählte Angriffsszenarien Projektziel GIDS Ziel dieses Projekts ist die Bereitstellung eines GIDS-Dienstes für das D-Grid. Hierbei gilt es, soweit wie möglich bestehende Ansätze zu integrieren und ein domänen- und organisationsübergreifendes Gesamtsystem zu entwickeln. Insbesondere die Fähigkeit, Virtuelle Organisationen (VO) zu unterstützen und diese als Kunden für das GIDS in Betracht zu ziehen, ist dabei von entscheidender Bedeutung. Die Grundidee ist es, Angriffe durch die kooperative Nutzung und Auswertung von lokalen Sicherheitssystemen zu erkennen. Dazu ist der Austausch von sensiblen Angriffsdaten notwendig. Diese Daten enthalten oftmals datenschutzkritische Informationen. Daher ist die datenschutzkonforme Aufarbeitung der Angriffsdaten ein erstes Zwischenziel im Projekt. Ebenso sollen durch die Aufarbeitung individuelle Sicherheits- und Informationsverbreitungsrichtlinien gewahrt bleiben. Weiterhin müssen ein geeignetes Datenaustauschformat und einheitliche Schnittstellen geschaffen werden. Um die Autonomie der einzelnen Ressourcenanbieter zu wahren, hat jeder Provider, wie in Abbildung 92 angedeutet, die Möglichkeit, eine lokale Instanz der GIDS-Datenbank zu betreiben. Auf diese Weise ist er nicht abhängig von einem noch nicht näher spezifizierten GIDS-Betreiber. Weiterhin sind in der Abbildung GIDS-Agenten vorgesehen. Diese sammeln bei den einzelnen Providern sicherheitsrelevante Infor-

156 150 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes mationen, bearbeiten sie datenschutzkonform und senden sie zu einer globalen Analyse zum GIDS- Betreiber. Weiterhin empfangen sie sicherheitsrelevante Daten, um sie in der lokalen Datenbank abzuspeichern. Über den GIDS-Betreiber lassen sich dann globale oder nutzerspezifische Berichte abrufen. In einem kooperativen IDS besteht die Möglichkeit, Angriffe schneller zu erkennen als dies mit unabhängigen und nur die lokale Sicht berücksichtigenden Sicherheitssystemen möglich ist. Somit kann eine Verkürzung der Reaktionszeit der beteiligten Parteien erzielt werden. Weiterhin können Vorwarnungen an Parteien herausgegeben werden, die zum Zeitpunkt der Erkennung eines Angriffs noch nicht betroffenen waren. Infolge einer solchen Vorwarnung können gegebenenfalls präventive Gegenmaßnahmen ergriffen werden. Nach der Entwicklung einer geeigneten Architektur für ein kooperatives und föderiertes IDS in Grid- Umgebungen steht die Implementierung und Produktivführung des Systems. Es soll nach Abschluss der Projektlaufzeit ein produktives Intrusion Detection System als Grid-Dienst im D-Grid zur Verfügung stehen, das sowohl von Ressourcenanbietern als auch von Kunden (VOs, Communities etc.) genutzt werden kann. Abbildung 92 Grobgranulare Übersicht der Architektur des GIDS Aktueller Stand Im Projekt wurden bisher folgende Arbeitspakete bearbeitet: Bestandsaufnahme bestehender Sicherheitssysteme und -dienste im D-Grid Anwendungsfall-getriebene Anforderungsanalyse anhand des D-Grid Szenarios Bedrohungsanalyse Abgleich des Anforderungs- und Kriterienkatalogs mit existierenden Lösungen Bestandsaufnahme bestehender Sicherheitssysteme und -dienste im D-Grid Um die momentane Lage im D-Grid besser einschätzen zu können, hat das LRZ eine Bestandsaufnahme im D-Grid mit Hilfe einer webbasierten Umfrage durchgeführt. Dabei ist erwartungsgemäß ein sehr heterogenes Bild der D-Grid-Landschaft zu Tage getreten, das sich vor allem in der großen Vielfalt an Diensten, Betriebssystemen und Middlewares äußert. Gerade im Bereich Sicherheit gibt es jedoch auch eine große Differenz zwischen den einzelnen Ressourcenanbietern. Auf der einen Seite bieten einige an ihren Grid-Knoten eine vollständige Werkzeugumgebung mit Virenscanner, Firewall, IDS und Log-Analyse-Tools auf, um Angriffe abzuwehren oder zu er-

157 Jahresbericht 2009 des Leibniz-Rechenzentrums 151 kennen. Auf der anderen Seite gibt es Anbieter, die von den genannten Sicherheits-Tools keine im Grid- Cluster laufen haben und sich einzig und allein auf eine Firewall verlassen, die am Zugang vom X-WiN zum Cluster installiert ist. Eine sehr wichtige Erkenntnis ist, dass bei einem Drittel der Ressourcenanbieter in der Vergangenheit ein oder mehrere gridspezifische Sicherheitsvorfälle aufgetreten sind. Jedoch ist die Dunkelziffer unbekannt Anwendungsfall-getriebene Anforderungsanalyse anhand des D-Grid Szenarios Um ein Grid-basiertes IDS bewerten zu können, wurde eine Reihe von Anforderungen definiert. Diese wurden zum einen gefunden, indem am LRZ verschiedene Use Cases betrachtet wurden und aus diesen Anforderungen extrahiert wurden. Für diesen Zweck wurden verschiedene Anwendungsfälle untersucht und dabei herausgestellt, welche Akteure beteiligt sind und welche Anforderungen diese an ein GIDS stellen. Dabei wurde zwischen Nutzergruppen- und Kundensicht auf ein GIDS und informationsanbieter-spezifische Sicht auf ein GIDS unterschieden, da je nach Betrachtung unterschiedliche Anforderungen abgeleitet werden können. So ist zum Beispiel der Ressourcenanbieter einmal Kunde und einmal Informationsanbieter und in beiden Fällen unterscheiden sich die Anforderungen erheblich. Zum anderen wurden generische Anforderungen spezifiziert, die nicht speziell für ein Grid-basiertes IDS, sondern für Grid-Anwendungen allgemein gelten müssen. Bei dieser Auflistung sind zwar einige Anforderungen auch schon in der obigen anwendungsfall-getriebenen Anforderungsanalyse enthalten, jedoch wurden diese hier noch einmal aus einem anderen Blickwinkel betrachtet und gegebenenfalls ergänzt. Weiterhin wurden verschiedene Abstufungen von Kooperationsmustern und Vertrauensbeziehungen erläutert Bedrohungsanalyse Bei der Bedrohungsanalyse haben die beteiligten Partner auf der einen Seite verschiedene Methoden vorgestellt, mit denen man sowohl technisch als auch analytisch Angriffserkennung betreiben kann. Auf der anderen Seite wurde eine Analyse der aktuellen Bedrohungslage im Internet und bei Grid-Ressourcen durchgeführt. Anschließend sind Angriffe verschiedener Kategorien analysiert worden. Zu jeder Bedrohung wurden neben einer einführenden Erklärung potentielle Abwehr- oder Erkennungsmechanismen aufgezeigt und eine erste Bewertung gegeben. Da für Grids selbst dem beteiligten DFN-CERT keinerlei Statistiken über Angriffe vorliegen und sich im Allgemeinen der Schaden nur sehr schwer bemessen lässt, hat sich das Konsortium entschieden, in diesem Rahmen bewusst auf eine quantitative Risikoabschätzung zu verzichten Abgleich des Anforderungs- und Kriterienkatalogs mit existierenden Lösungen Bei den themenverwandten wissenschaftlichen Arbeiten sind viele Ideen und Grundbausteine vorhanden, auf denen das föderierte Grid-IDS aufbauen kann. Am LRZ wurden viele frei zugängliche Arbeiten ausgiebig untersucht. Keine dieser Arbeiten hat aber eine vollständige Lösung, die alle Anforderungen an das föderierte Grid-IDS berücksichtigt. Schwächen finden sich entweder bei der organisatorischen Einbindung des IDS in die D-Grid-Strukturen oder dem Datenschutzkonzept. In vielen der existierenden Produkte werden vereinzelt Anforderungen an ein GIDS umgesetzt. Eine Untersuchung wurde von den beteiligten Partnern durchgeführt. Bislang existiert allerdings noch kein Produkt, welches alle in Kapitel 3.3 im Meilensteinbericht Anforderungs- und Kritierienkatalog (MS 6) (http://www.grid-ids.de/documents/gids_ms6.pdf) erarbeiteten Anforderungen erfüllt. Die meisten eingesetzten Produkte bieten keine gridspezifische Unterstützung und können daher nicht ohne Erweiterungen die durch das Projekt geforderte föderierte Angriffserkennung in einem solch heterogenen Umfeld bieten DGI-II Im Folgenden wird die Projektstruktur von DGI-II sowie die Beteiligung des LRZ kurz erläutert. DGI-II besteht aus den sechs Fachgebieten (FG): FG 1: Support FG 2: Betrieb der D-Grid Infastruktur FG 3: Sicherheit FG 4: Daten- und Informationsmanagement

158 152 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes FG 5: Entwicklungsprojekte FG 6: Nachhaltigkeit und Koordination Das LRZ ist als geförderter Partner in den Fachgebieten 1, 2 und 3 beteiligt. Im FG 5 ist das LRZ assoziierter Partner. Das LRZ bringt als Kompetenzzentrum für Globus sein Wissen in das FG 1-2 Verteiltes Kompetenzzentrum Middleware ein. Das Ziel dieses FG ist die Unterstützung sowohl der Nutzer als auch der Ressourcen-Betreiber im D-Grid. Dabei sollen alle vom D-Grid unterstützten Middleware-Technologien durch Kompetenzzentren vertreten sein, die in der Lage sind, hochwertigen Support zu liefern. Dies umfasst neben Schulungsangeboten, dem Aufbau und der Dokumentation von Referenzinstallationen, Hilfe bei der Installation der Middleware auch die Unterstützung der Service Support Prozesse: Incident-, Problem-, Change- und Release-Management sowie die Unterstützung des Service-Level Managements. In FG 1-2 kooperiert das LRZ mit dem Forschungszentrum Jülich (FZJ), dem Forschungszentrum Karlsruhe (FZK), dem Albert Einstein Institut (AEI), Sun Microsystems und der T-Systems Solutions for Research (TS-SfR). Im zweiten Projektjahr (2009) wurde die Tätigkeit des LRZ mit einer halben Stelle gefördert. Die Gelder, um die Stelle auf eine volle aufzustocken, wurden unter Mittelvorbehalt gestellt. Vor jedem Projektjahr entscheidet die DGI-Leitung, ob die Mittel für Globus (und damit das LRZ) oder für den Support einer der anderen beiden Middlewares freigegeben wird. Das FG 2-3 Betrieb der Ressourcen im D-Grid befasst sich mit dem Betrieb von Basisdiensten für das gesamte D-Grid. Das LRZ kann in diesem Projekt seine Vorarbeiten zum Monitoring aus DGI-I verstetigen. Es ist für den Betrieb der am LRZ entwickelten Monitoring-Infrastruktur zuständig. Außerdem sollen neue Provider und neuere Entwicklungen integriert werden. Das LRZ kooperiert in diesem Teilprojekt mit dem Forschungszentrum Jülich (FZJ), dem Forschungszentrum Karlsruhe (FZK), dem Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik Berlin (FhG/FIRST) und den beiden assoziierten Partnern Regionales Rechenzentrum für Niedersachsen (RRZN) sowie der Universität Dortmund. Im Fachgebiet 2-4 einheitliche Betriebsumgebung für Produktions-Jobs sollen einheitliche Zugangsmöglichkeiten zum D-Grid erarbeitet werden. Dazu wird ein Konzept für ein so genanntes Common Production Environment (CPE) entwickelt. Das Konzept wird prototypisch umgesetzt, mit ausgewählten Nutzergruppen getestet und verbessert, um es dann in die Produktion zu übernehmen. Als Basis für eine einheitliche Software-Umgebung wird ein Modul-Konzept entwickelt und umgesetzt. Damit ist es möglich, Software unabhängig von spezifischen lokalen Umgebungsvariablen oder Installationsverzeichnissen global einheitlich zu nutzen. In DEISA findet ein Modul-Konzept bereits Anwendung. Das LRZ ist für die Konzeption und Umsetzung des Modul-Konzeptes voll verantwortlich. In der Prototyp-Phase wird das Konzept ebenso wie das CPE einem Praxistest bei ausgewählten Nutzergruppen unterzogen, um es dann in den Produktivbetrieb zu übernehmen. Im FG 2-4 kooperiert das LRZ mit dem Fraunhofer Institut für Techno- und Wirtschaftsmathematik (ITWM), dem Forschungszentrum Jülich (FZJ), dem Forschungszentrum Karlsruhe (FZK). Das Max-Planck Institut für Astrophysik sollte in dem Projekt in der Konzeptions- sowie in der Umsetzungs- und Erprobungsphase im Projekt mitarbeiten. Nachdem dies aus organisatorischen Gründen nicht möglich war, wurden die entsprechenden Arbeiten im Umfang von 18 Personenmonaten dem LRZ übertragen. Im Fachgebiet 3-2 AAI / VO wurden 2009 zunächst Werkzeugkonzepte zur Unterstützung des VO- Managements untersucht und verstärkt Beratungen und Schulungen durchgeführt, um die existierenden und geplanten Funktionen der Authentifizierungs- und Autorisierungsinfrastruktur (AAI) möglichst gut durch die Communities nutzen zu lassen. Auf Basis eines Konzepts zur attributbasierten Autorisierung im D-Grid wurde der VOMS-SAML-Service einer umfassenden Pilotierung und Analyse unterzogen. Hieraus resultierten einerseits ein Konzept zur D-Grid-weiten Einführung der neuen Autorisierungsmechanismen, andererseits ein Systementwurf samt prototypischer Implementierung von Kernfunktionen einer dedizierten Management-Suite für die D-Grid-VOs. Sowohl die Konzepte als auch die Umsetzung werden seither verfeinert, indem beispielsweise der genaue Attributsatz für Autorisierungsentscheidungen im D-Grid spezifiziert und ein prozessorientiertes Supportkonzept für das VO-Management erstellt wurden Steuerungsausschuss/Beirat Seit September 2007 ist das LRZ auch im Steuerungsausschuss des D-Grid vertreten wurde zudem die D-Grid Entwicklungs- und Betriebsgesellschaft mbh (kurz D-Grid Betriebsgesellschaft) mit Sitz in Heidelberg, mit der in Abbildung 93 dargestellten Struktur, gegründet. Zu den Aufgaben der Gesellschaft

159 Jahresbericht 2009 des Leibniz-Rechenzentrums 153 gehört der Betrieb der entwickelten Grid Infrastruktur sowie die Wahrnehmung der Gesamtprojektkoordinierung für die vom BMBF im Rahmen der D-Grid-Initiative geförderten Projektverbünde. Die Ressourcen des D-Grid stehen bei verschiedenen Ressource-Providern und wurden auch von diesen beschafft. Die Ressource-Provider bilden zusammen die D-Grid Service Einrichtung (DGSE). Abbildung 93 Struktur und Einbettung der D-Grid Betriebs GmbH Gesellschafter der GmbH ist die European Media Lab GmbH, die ihre Stimmrechte an das BMBF abgetreten hat. Zum Geschäftsführer wurde Prof. Dr. Uwe Schwiegelshohn ernannt. Der Steuerungsausschuss, der in der Vergangenheit die Zusammenarbeit zwischen den einzelnen D-Grid Projekten koordiniert und projektübergreifende Entscheidungen getroffen hatte, wurde durch den Beirat der D-Grid Betriebsgesellschaft ersetzt. Das LRZ ist durch Dr. Helmut Reiser oder Dr. Victor Apostolescu im Beirat vertreten Das CNM und die Géant-Visualisierungswerkzeuge für Performance Monitoring Das Customer Network Management (CNM) wurde ursprünglich für das MWN (Münchner Wissenschaftsnetz) entwickelt, dann innerhalb mehrerer DFN-Projekte für das B-WIN, G-WIN und schließlich das X-WIN erweitert. Das CNM wird seit 2004 im europäischen Forschungsumfeld als Visualisierungswerkzeug eingesetzt, im Géant2-Projekt von 2004 bis 2009 und in dessen Nachfolger Géant3 seit 04/2009. Das CNM wurde in den Jahresberichten der vorherigen Jahre ausführlich beschrieben, sodass hier nur die Erweiterungen, die im Jahre 2009 vorgenommen worden sind, aufgeführt werden Einsatz in X-WiN Wie schon in dem vorherigen Jahr beschrieben, lassen sich für die CNM-Anwendung für das X-WiN folgende Teilbereiche identifizieren: 1. CNM-Anwendung (Topologie): Visualisierung der Topologie und des Zustands der IP- Infrastruktur: Mit Hilfe dieser Funktionalität können DFN-Anwender sich einen Überblick über den aktuellen und historischen Zustand und Qualität der IP-Infrastruktur verschaffen (siehe Abbildung 94). 2. CNM-Anwendung (Datenvolumen): Bereitstellung von IP-Interfacestatistiken für die DFN- Anwender. Mit dieser Funktionalität können DFN-Anwender nachvollziehen, welches Verkehrsvolumen sie aus dem X-WiN empfangen bzw. gesendet haben. 3. CNM-Anwendung (XY-Datenvolumen): Bereitstellung von detailierten IP-Accounting-Daten. Mit Hilfe dieser Funktionalität können DFN-Anwender nachvollziehen, mit welchen anderen DFN- Anwendern sie innerhalb des X-WiN wie viel IP-Verkehr ausgetauscht haben. Die Implementierung dieser Funktionalität wurde begonnen. Das CNM-Team führte alle nötigen Administrationsaufgaben für die stetig aktualisierte Anzeige aller Topologie-, Dienst- und Metrikdaten aus. Weiterhin wurde experimentell damit begonnen, die bisherigen Topologie-/Metrikdaten umzustellen. Der zurzeit verwendete direkte SNMP-Zugriff auf die X-WiN Rou-

160 154 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes ter soll langfristig durch Zugriff auf perfsonar-datenquellen, die im Géant Projekt (siehe nächsten Abschnitt) entwickelt worden sind, umgestellt werden. Abbildung 94 Oberfläche der CNM-Anwendung Derzeit wird der Zugriff auf IP-Linkauslastungsdaten aus einer solchen perfsonar-datenquelle getestet. Abbildung 95 Übersichtskarte im Web-CNM für das MWN Alle oben genannten Anwendungen sind Java basiert. Darüberhinaus wird seit 2004 im MWN eine Webinterface-basierte Sicht der CNM-Anwendung Topologie angeboten (siehe Abbildung 95), das sogenannte Web-CNM. Diese zeigt ausschließlich hierarchische Netzkarten mit dem aktuellen Status der Routerinterfaces.

161 Jahresbericht 2009 des Leibniz-Rechenzentrums Einsatz in Géant Der über Géant realisierte europäische Verbund von 34 nationalen Forschungsnetzen (NRENs) stellt Netzdienste im paneuropäischen Maßstab zur Verfügung. Ein Beispiel für einen solchen Dienst sind Optical Private Networks (OPNs), die z.b. im Umfeld des LHC-Grid verwendet werden, um das CERN (Tier-0) mit den Tier-1- und Tier-2-Zentren zu verbinden. Die Dienste werden in einer multinationalen Kooperation unabhängiger nationaler Forschungsnetze (NRENs) und DANTE erbracht. Das LHCOPN (Large Hadron Collider Optical Private Network) ist ein weltweites Netz für die Verteilung der Daten der LHC Experimente. Die CNM-Anwendung Topologie für Géant wird für die Visualisierung eines Domänen- und Providerübergreifenden Performance Monitorings (perfsonar-system) eingesetzt. Weiterhin wird das Web- CNM in einer speziell angepassten Version für die Netzüberwachung des LHCOPN eingesetzt. Dabei werden Topologie und die aktuelle bzw. historische Metriken vom Géant-Kernnetz und einigen der 34 angeschlossenen nationalen Forschungsnetze in hierarchischen Netzkarten visualisiert. Derzeit enthält die CNM-Anwendung Topologie für Géant die Topologie von 12 nationalen Forschungsnetzen (SWITCH, GARR, ESnet, GRnet, SURFnet, PSNC, UNINETT, ISTF, SEEREN, Hungarnet, FCCN und CESNET) und des Géant-Netzes (siehe Abbildung 96). Diese Topologiedarstellung beinhaltet ebenfalls die Nutzungsinformationen von den Messarchiven (engl. MA - Measurement Archives) für die obengenannten Netze. Zusätzlich werden HADES-Messwerte angezeigt. Abbildung 96 Übersichtskarte des Layer-3 Géant-Kernnetzes mit entsprechender HADES IP-Jitter Metrik Das oben genannte, für das MWN entwickelte Web-CNM wurde erweitert und für den Spezialfall einer LHCOPN-Wetterkarte eingesetzt. Diese Wetter -Karte erlaubt den Web-Zugriff auf Status und Kennzahlen der LHCOPN-Infrastruktur (Tier-0- zu Tier-1-Verbindungen). Das LHCOPN Netz besteht aus einem Tier-0-Standort (CERN) und 11 Tier-1-Standorten, verteilt über die ganze Welt. Auf ihm werden voraussichtlich ca. 15 Petabytes jährlich übertragen werden. Die Implementierung der Wetterkarte verwendet HTML/CSS-, Java Script und kann über den Web- Browser angesprochen werden. Die LHCOPN-Wetterkarte ist ein Dienstzugriffspunkt für die Operateure des LHCOPNs. Abbildung 97 zeigt ihre Übersichtskarte. In dieser können die Operateure ein Paar von je zwei LHCOPN-Standorten (T0/T1 oder T1/T1) auswählen, um nähere Informationen und Metriken über den Link dazwischen zu erhalten.

162 156 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Abbildung 97 Hauptsicht der LHC-OPN Wetterkarte Für jeden Link werden dabei Ende-zu-Ende (E2E) Kennzahlgraphen von verschiedenen Netzschichten der letzten 24 Stunden angezeigt, nämlich: Hop-Anzahl, One-Way-Delay, Jitter, Paketverlust, verfügbarer TCP-Durchsatz, Verbindungsauslastung, IO-Errors (siehe Abbildung 98). Abbildung 98 Link Status Abschnittssicht (24-Stunden) Weiterhin wird für den ausgewählten Link eine detaillierte Ansicht der Schicht-2-Abschnitte in den verschiedenen beteiligten administrativen Domänen angezeigt (siehe Abbildung 99).

163 Jahresbericht 2009 des Leibniz-Rechenzentrums 157 Abbildung 99 End-to-End Domänen Abschnittssicht Weitere Einzelheiten zum CNM-Projekt und zum CNM für das X-WiN sind zu finden unter: sowie zum CNM für das MWN unter: Einzelheiten zum Géant-Projekt und dessen perfsonar-system sind erhältlich unter: Géant E2E Link Monitoring Géant ist eine Weiterentwicklung des europäischen Wissenschaftsnetzes, das ca. 30 nationale Wissenschaftsnetze verbindet. Neben klassischen IP-Verbindungen können im Rahmen des Géant-Verbundes auch End-to-End (E2E) Links eingerichtet werden. Das LRZ arbeitet seit Jahren aktiv in Projektteilen mit, die Konzepte, Verfahren und Tools zum Management dieser Ende-zu-Ende Links bereitstellen. Ein wesentlicher Bestandteil dieses Projekts ist das E2E Link Monitoring System (E2Emon), das unter Federführung des LRZ konzipiert und entwickelt wurde. Eine ausführliche Beschreibung des zugrunde liegenden Projekts und des Monitoring Systems kann dem Jahresbericht 2008 entnommen werden. In Géant wird das E2E Monitoring System von der E2E Coordination Unit (E2ECU) betrieben, die gezielt für den Betrieb von E2E Links ins Leben gerufen wurde. Sie überwacht derzeit (Stand Anfang 2010) 36 produktive Links. Weitere 15 Links sind aktuell in der Aufbauphase. Zu den größten Kunden dieses Dienstes zählen internationale Forschungsprojekte wie das LHC in Cern, sowie die europäische GRID- Initiative DEISA. Bereits seit Mitte 2008 erfüllt das E2Emon die von der E2ECU spezifizierten funktionalen Anforderungen. Deshalb lag 2009 der Fokus hauptsächlich auf der Analyse der nichtfunktionalen Anforderungen, deren Umsetzung die Nutzerfreundlichkeit des Systems noch weiter verbessern soll. So wurde beispielsweise eine benutzerfreundliche grafische Oberfläche für die Administration der E2Emon-Einstellungen entwickelt. Abbildung 100 zeigt eine benutzerfreundliche Möglichkeit, neue Measurement-Archives (MA) oder Measurement-Points (MP) hinzuzufügen oder Einstellungen der schon vorhandenen zu editieren.

164 158 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Abbildung 100 Verwalten von MP/MAs in AdminGUI Weiterhin werden alle gemeldeten E2E Links vom System erkannt. Diese werden in einer weiteren AdminGUI Oberfläche angezeigt, in der ihr Status als produktiv oder nicht produktiv markiert werden kann (siehe Abbildung 101). Diese Auswahl ist ausschlaggebend für die Erstellung der monatlichen Statistiken. Weiterhin werden anhand dieses Kriteriums unterschiedliche Views auf die existierenden Links im E2Emon gebildet. Abbildung 101 Übersicht über End-to-End-Links in Géant Derzeit werden die einzelnen spezifizierten Verbesserungswünsche implementiert, die dann in der nächsten Version Anfang/Mitte 2010 zur Verfügung stehen werden. Für das nächste Major Release ist eine Umstellung der Technologie angedacht, so dass die Auswertung und Weiterverarbeitung der erfassten Informationen beispielsweise anhand von Filterfunktionen erheblich erleichtert werden kann.

165 Jahresbericht 2009 des Leibniz-Rechenzentrums Géant I-SHARe Beim Betrieb von Netzdiensten, die die Zusammenarbeit mehrerer unabhängiger Provider erfordern, ergeben sich neuartige Herausforderungen, die von etablierten IT Service Management Frameworks nicht adressiert werden. Im Umfeld des von der EU geförderten GN-Projektes werden diese insbesondere im Zusammenhang mit sog. Ende-zu-Ende-Verbindungen deutlich, bei denen es sich um dedizierte optische Multi-Gigabit Verbindungen - i.a. jeweils über mehrere heterogene optische Netze - handelt. Die Arbeitsabläufe für die Einrichtung und den Betrieb dieser Verbindungen erfordern ein koordiniertes Vorgehen der beteiligten nationalen Wissenschaftsnetze. Das Ziel der GN-Aktivität I-SHARe ist die Tool-Unterstützung der Multi-Domain-Betriebsprozesse, die alle Phasen des Lebenszyklus von E2E Links abdecken. Der Fokus liegt dabei auf dem erforderlichen Informationsaustausch, der von der Planung einer neuen E2E Link Instanz über deren Betrieb bis hin zu ihrer Abbestellung notwendig ist. Die Aktivität wurde Mitte 2007 mit einer umfangreichen, fundierten Anforderungsanalyse gestartet. Details dazu können im Jahresbericht 2008 nachgelesen werden. Ergebnis dieser Analyse war die Spezifikation und Entwicklung eines Prototyps (siehe Abbildung 102), der Anfang 2009 im Rahmen eines Piloteinsatzes durch das Betriebspersonal evaluiert wurde. Die Anmerkungen und Wünsche wurden vom I-SHARe-Team erfasst und bildeten die Grundlage für eine Anpassung der Anforderungen. Mitte bis Ende 2009 floss die mit dem Prototyp gesammelte Erfahrung in die Erstellung einer Spezifikation für die Entwicklung einer ersten produktiven Version des I-SHARe Tools ein. Die zurzeit andauernde Entwicklung soll Mitte 2010 abgeschlossen werden. Nach deren Fertigstellung ist der Piloteinsatz in 5 National Research and Education Networks (NRENs) geplant. Abbildung 102 I-SHARe Prototyp (Screenshot) GET-E3 Im Rahmen des europäischen Dachprojektes 100 Gbit/s Carrier-Grade Ethernet Transport Technologies (100GET), das vom BMBF gefördert wird, werden Ultra-Hochgeschwindigkeitsnetze basierend auf Ethernet-Technologien für Übertragungsraten von 100 Gigabit pro Sekunde entwickelt. Durch den breiteren Einsatz von Ethernet-Technik auch in den Backbone-Netzen (sogenanntes Carrier-Grade Ethernet) erwartet man sich erhebliche Kosteneinsparungen. Das von Nokia Siemens Networks (NSN) geführte

166 160 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes Teilprojekt "End-to-End Ethernet (E3)" entwickelt in Zusammenarbeit mit dem Leibniz-Rechenzentrum solche Technologien und Protokolle. Das Projekt läuft bis 30. September Im Rahmen dieses Teilprojektes wird ein Konzept und eine Architektur für ein integriertes Inter-Domain Network Management System für Ultra-Hochgeschwindigkeitsnetze basierend auf Ethernet- und DWDM-Techniken spezifiziert. Um extrem breitbandige Verbindungen zwischen zwei Kunden zu schalten, sind häufig mehrere Provider beteiligt, die i.d.r. jeweils unterschiedliche eigene Systeme und Geräte verschiedener Hersteller verwenden (Heterogenität). Um einen solchen Dienst erbringen zu können, muss ein Managementsystem in der Lage sein, mit diesen Domänen-übergreifenden (Inter-Domain) Aspekten umgehen zu können. Das Themengebiet des IT-Managements lässt sich in die fünf Aufgabengebiete Fault (Fehlermanagement), Configuration, Accounting, Performance und Security Management aufteilen (FCAPS). Im Rahmen dieses Teilprojektes sind insbesondere das Fehler-, Konfigurations- sowie das Performance Management von Interesse. Außerdem werden die Fragen des Organisationsmodells für domänenübergreifende Zusammenarbeit untersucht. In 2009 wurden für das providerübergreifende Management Konzepte zur Organisation der Zusammenarbeit und für den Betrieb von providerübergreifenden Diensten erstellt. Abbildung 103 zeigt das Prinzip eines Ende-zu-Ende Dienstes, der aus einzelnen Teildiensten zusammengesetzt wird. Dabei wird jeweils ein Teildienst von einem anderen Provider erbracht. Die Provider tauschen Informationen über angebotene Dienste durch die Veröffentlichung von service templates in einem neutralen Austauschdienst aus. Dieser neutrale Austauschdienst kann als Börsenplatz für Teildienste betrachtet werden. Abbildung 103 Ende-zu-Ende Dienst über mehrere Provider hinweg In Zusammenarbeit mit NSN und der TU Braunschweig wurde an einem Konzept für Migrationsstrategien für den Betrieb von providerübergreifenden Diensten gearbeitet, insbesondere, wie die Interaktion zwischen Providern gestaltet werden kann, wenn ein Provider bereits eine Kontrollschicht einsetzt und ein anderer Provider eine reine Managementlösung einsetzt. Dazu wird eine einheitliche Schnittstelle benötigt, die zwischen den Informationsmodellen der beiden Schichten übersetzen kann. Zudem wurde ein Adressierungsschema für eine weltweit eindeutige Kennzeichnung von Zugangspunkten zu Ethernetdiensten erarbeitet. Dieses Schema orientiert sich am Aufbau des Domain Name Systems (DNS) um eine weltweite Hierarchie zu bilden und nutzt auch das Konzept von Aliasnamen, um interne Bezeichnungen, die Rückschlüsse auf die Netzstruktur geben könnten, verbergen zu können. In der restlichen Laufzeit des Projektes werden noch ein Konzept für Service Level Agreements (SLA) und entsprechende Quality of Service (QoS) Parameter, ein Konzept für ein Ende-zu-Ende Monitoring System und Incident und Problem Management Prozesse für providerübergreifende Dienste entwickelt.

Iden%ty & Access Management: Das Rückgrat der Hochschul- IuK- Infrastruktur

Iden%ty & Access Management: Das Rückgrat der Hochschul- IuK- Infrastruktur Iden%ty & Access Management: Das Rückgrat der Hochschul- IuK- Infrastruktur IntegraTUM Teilprojekt Verzeichnisdienst 24. September 2009 Dr. Wolfgang Hommel, Leibniz- Rechenzentrum IntegraTUM IdenJty &

Mehr

Jahresbericht 2010 Juni 2011 LRZ-Bericht 2011-01

Jahresbericht 2010 Juni 2011 LRZ-Bericht 2011-01 Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften Jahresbericht 2010 Juni 2011 LRZ-Bericht 2011-01 Direktorium: Prof. Dr. A. Bode (Vorsitzender) Prof. Dr. H.-J. Bungartz Prof. Dr. H.-G.

Mehr

6 Jahre Identity Management an der Julius-Maximilians-Universität Würzburg. Sylvia Wipfler Rechenzentrum, Universität Würzburg

6 Jahre Identity Management an der Julius-Maximilians-Universität Würzburg. Sylvia Wipfler Rechenzentrum, Universität Würzburg 6 Jahre Identity Management an der Julius-Maximilians-Universität Würzburg Sylvia Wipfler Rechenzentrum, Universität Würzburg Projektstart Projektstart: 1. Oktober 2006 Einführungsphase 3 Jahre Gründe:

Mehr

Identitätsmanagement für Hybrid-Cloud-Umgebungen an Hochschulen

Identitätsmanagement für Hybrid-Cloud-Umgebungen an Hochschulen Identitätsmanagement für Hybrid-Cloud-Umgebungen an Hochschulen Erfahrungen im Münchner Wissenschaftsnetz Silvia Knittl, Wolfgang Hommel {knittl,hommel}@mnm-team.org Agenda Hybrid Cloud im Münchner Wissenschaftsnetz

Mehr

Iden%ty Management im Münchner Wissenscha4snetz. Aktueller Stand und Ergebnisse des DFG- geförderten Projekts IntegraTUM

Iden%ty Management im Münchner Wissenscha4snetz. Aktueller Stand und Ergebnisse des DFG- geförderten Projekts IntegraTUM Iden%ty Management im Münchner Wissenscha4snetz Aktueller Stand und Ergebnisse des DFG- geförderten Projekts IntegraTUM ZKI Arbeitskreis Verzeichnisdienste HerbsLagung 2009 TU Dresden Dr. Wolfgang Hommel,

Mehr

Identity Management im Münchner Wissenschafts-Netz RBP-Begleitseminar, 05. November 2009

Identity Management im Münchner Wissenschafts-Netz RBP-Begleitseminar, 05. November 2009 Identity Management im Münchner Wissenschafts-Netz RBP-Begleitseminar, 05. November 2009 Dr. Wolfgang Hommel, Leibniz-Rechenzentrum hommel@lrz.de Übersicht Identity Management: Grundlagen und Architekturen

Mehr

Auf dem Weg zur Digitalen Fakultät

Auf dem Weg zur Digitalen Fakultät Auf dem Weg zur Digitalen Fakultät moderne IT Infrastruktur am Beispiel des Physik- Departments der TU München Dr. Josef Homolka Abschlussworkshop IntegraTUM 24.09.2009 www.ph.tum.de/personen/professoren

Mehr

Verzeichnisdienst: Firmenkonzepte. Universität Duisburg-Essen

Verzeichnisdienst: Firmenkonzepte. Universität Duisburg-Essen Verzeichnisdienst: Firmenkonzepte Universität Duisburg-Essen Übersicht 1. Problem 2. Produktvorstellungen von Sun, IBM und Siemens 3. Anforderungspapier 4. Konzepte von IBM und Sun für die Universität

Mehr

Identity-Management in den Hamburger Hochschulen... und ihren Bibliotheken!

Identity-Management in den Hamburger Hochschulen... und ihren Bibliotheken! Identity-Management in den Hamburger Hochschulen...... und ihren Bibliotheken! Dr. Stefan Gradmann Universität Hamburg / Regionales Rechenzentrum stefan.gradmann@rrz.uni-hamburg.de www.rrz.uni-hamburg.de/rrz/s.gradmann

Mehr

Motivation und aktuelle Lösungsansätze für organisationsübergreifendes Identity Management

Motivation und aktuelle Lösungsansätze für organisationsübergreifendes Identity Management Motivation und aktuelle Lösungsansätze für organisationsübergreifendes Identity Management 7. Treffen der IT-Betriebszentren im Hochschulbereich 26. September 2007 Wolfgang Hommel, Leibniz-Rechenzentrum

Mehr

Die Dienste der DFN-AAI. Ulrich Kähler, DFN-Verein kaehler@dfn.de

Die Dienste der DFN-AAI. Ulrich Kähler, DFN-Verein kaehler@dfn.de Die Dienste der DFN-AAI Ulrich Kähler, DFN-Verein kaehler@dfn.de Was ist DFN-AAI? AAI Authentifizierung Autorisierung Infrastruktur Seite 2 Was ist DFN-AAI? DFN-AAI ist ein regulärer Dienst des DFN-Vereins.

Mehr

Das Leibniz-Rechenzentrum

Das Leibniz-Rechenzentrum Andreas Heddergott, LRZ Das Leibniz-Rechenzentrum Das Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften ist der IT-Dienstleister der Münchner Universitäten und Hochschulen. Es bietet weit

Mehr

DFG-Projekt IntegraTUM. Identity Management an Technischer Universität und Leibniz-Rechenzentrum München. Wolfgang Hommel hommel@lrz.

DFG-Projekt IntegraTUM. Identity Management an Technischer Universität und Leibniz-Rechenzentrum München. Wolfgang Hommel hommel@lrz. DFG-Projekt IntegraTUM Identity Management an Technischer Universität und Leibniz-Rechenzentrum München Wolfgang Hommel hommel@lrz.de Agenda FFM, 04.10.2005 ZKI AK Verzeichnisdienste: Projekt IntegraTUM

Mehr

Pools des URZ und der Fakultäten, Virtualisierung, Identity Management, Servicedesk Peter Trommer

Pools des URZ und der Fakultäten, Virtualisierung, Identity Management, Servicedesk Peter Trommer Pools des URZ und der Fakultäten, Virtualisierung, Identity Management, Servicedesk Peter Trommer URZ Abteilung PC-Service 19.04.13 Schwerpunkte der Abteilung PC-Service Technische Absicherung des Lehrbetriebes

Mehr

Identity Web Services leicht gemacht

Identity Web Services leicht gemacht Identity Web Services leicht gemacht am Beispiel der TUMonline-IntegraTUM-Rückkopplung ZKI AK Verzeichnisdienste Dr. Ralf Ebner ebner@lrz.de Agenda IDM im Münchener Wissenschaftsnetz Identity-Services

Mehr

Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de

Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften Agenda Einleitung Vor- und Nachteile der Virtualisierung Virtualisierungssoftware

Mehr

Föderiertes Identity Management

Föderiertes Identity Management Föderiertes Identity Management 10. Tagung der DFN-Nutzergruppe Hochschulverwaltung Berlin, 09.05.-11.05.2011 Peter Gietz, CEO, DAASI International GmbH Peter.gietz@daasi.de 1 von 23 (c) Mai 2011 DAASI

Mehr

E-Mail Software AD-Account Domain Gruppen Stammdaten Organisation Dateiablagen Computer Location Effiziente und sichere Verwaltung von Identitäten, Rechten und IT-Diensten Der und für Einsteiger Identitäten,

Mehr

IKM-Dienstleistungen des ZIM

IKM-Dienstleistungen des ZIM IKM-Dienstleistungen des ZIM KIM 16.09.2009 Univ.-Prof. Dr.-Ing. Stephan Olbrich Zentrum für Informations- und Medientechnologie (ZIM) sowie Lehrstuhl für IT-Management / Institut für Informatik Heinrich-Heine-Universität

Mehr

Active Directory unter Linux

Active Directory unter Linux CeBIT 2015 Active Directory unter Linux Prof- Dr.-Ing. Kai-Oliver Detken DECOIT GmbH Fahrenheitstraße 9 D-28359 Bremen http://www.decoit.de detken@decoit.de DECOIT GmbH Kurzvorstellung der DECOIT GmbH

Mehr

Integriertes Learning Management: Moodle in der Systemlandschaft der TUM. Vortrag auf der MoodleMoot 2013 in München Dr.

Integriertes Learning Management: Moodle in der Systemlandschaft der TUM. Vortrag auf der MoodleMoot 2013 in München Dr. @ Integriertes Learning Management: Moodle in der Systemlandschaft der TUM Vortrag auf der MoodleMoot 2013 in München Dr. Matthias Baume 25.03.2013 ITSZ- 2013 1 Agenda 1. Integriertes elearning Management

Mehr

Gliederung. Konzeption und Umsetzung von Identity Management an der FH-Osnabrück und der Vergleich zu anderen Hochschulen

Gliederung. Konzeption und Umsetzung von Identity Management an der FH-Osnabrück und der Vergleich zu anderen Hochschulen ZKI Tagung e 08/09.02.10 Konzeption und Umsetzung von Identity Management an der FH-Osnabrück und der Vergleich zu anderen Hochschulen Dipl.-Ing IT (FH) Jürgen Kuper FH Osnabrück Management und Technik

Mehr

ISO 20000: Die CMDB im Betrieb und ihr Beitrag zu einem funktionierenden ITSM-System

ISO 20000: Die CMDB im Betrieb und ihr Beitrag zu einem funktionierenden ITSM-System ISO 20000: Die CMDB im Betrieb und ihr Beitrag zu einem funktionierenden ITSM-System 7. INFORMATION-SECURITY-SYMPOSIUM, WIEN 2011 DI Markus Hefler, BSc, Florian Hausleitner 1 Agenda 1. Kurze Vorstellung

Mehr

Anwendungsintegration an Hochschulen am Beispiel von Identity Management. Norbert Weinberger - Sun Summit Bonn 26.4.2006

Anwendungsintegration an Hochschulen am Beispiel von Identity Management. Norbert Weinberger - Sun Summit Bonn 26.4.2006 Anwendungsintegration an Hochschulen am Beispiel von Identity Management Norbert Weinberger - Sun Summit Bonn 26.4.2006 Ausgangslage: Anwendungsinseln Zugang zu IT- Ressourcen, z.b. Radius Rechenzentrum

Mehr

LDAP in der GWDG Einsatzspektrum

LDAP in der GWDG Einsatzspektrum LDAP in der GWDG Einsatzspektrum Konrad Heuer, Andreas Ißleiber Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen Einleitung In diesem Vortrag wird dargestellt, wie sich das Einsatzspektrum

Mehr

Projektbericht. Aufbau & Implementierung eines neuen Identity & Access- Management Systems basierend auf den Forefront Identity Manager 2010

Projektbericht. Aufbau & Implementierung eines neuen Identity & Access- Management Systems basierend auf den Forefront Identity Manager 2010 Projektbericht Aufbau & Implementierung eines neuen Identity & Access- Management Systems basierend auf den Forefront Identity Manager 2010 E-Mail: Daniel.Loeffler@FernUni-Hagen.de Telefon: +49 2331 987-2868

Mehr

Security Knowledge Management auf Basis einer Dokumentenvorlage für Sicherheitskonzepte. Felix von Eye Leibniz-Rechenzentrum, Garching bei München

Security Knowledge Management auf Basis einer Dokumentenvorlage für Sicherheitskonzepte. Felix von Eye Leibniz-Rechenzentrum, Garching bei München auf Basis einer Dokumentenvorlage für Sicherheitskonzepte Felix von Eye Leibniz-Rechenzentrum, Garching bei München 18.02.2014 Leibniz-Rechenzentrum (LRZ) Rechenzentrum für Münchner Universitäten und Hochschulen

Mehr

E-Mail Software AD-Account Domain Gruppen? Stammdaten Organisation Dateiablagen Computer Location Effiziente und sichere Verwaltung von Identitäten, Rechten und IT-Diensten cmatrix Identitäten, Rechte

Mehr

Identity Management an der Freien Universität Berlin

Identity Management an der Freien Universität Berlin Elektronische Administration und Services Identity Management an der Freien Universität Berlin Transparenz und Effizienz für Exzellenz Dr. Christoph Wall Leiter elektronische Administration und Services

Mehr

Felix von Eye, Wolfgang Hommel, Stefan Metzger DR. TOPSCAN. Ein Werkzeug für die automatisierte Portscanauswertung in komplexen Netzinfrastrukturen

Felix von Eye, Wolfgang Hommel, Stefan Metzger DR. TOPSCAN. Ein Werkzeug für die automatisierte Portscanauswertung in komplexen Netzinfrastrukturen Felix von Eye, Wolfgang Hommel, Stefan Metzger DR. TOPSCAN Ein Werkzeug für die automatisierte Portscanauswertung in komplexen Netzinfrastrukturen Felix von Eye, Wolfgang Hommel, Stefan Metzger DR. TOPSCAN

Mehr

CAD Virtualisierung. Celos CAD Virtualisierung

CAD Virtualisierung. Celos CAD Virtualisierung CAD Virtualisierung Celos Hosting Services Celos Netzwerk + Security Celos Server + Storage Virtualisierung Celos Desktop Virtualisierung Celos CAD Virtualisierung Celos Consulting Celos Managed Services

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Aufbau einer integrierten elearning- Infrastruktur und Vorlesungsübertragungen an der TU München. Dr. Sabine Rathmayer Technische Universität München

Aufbau einer integrierten elearning- Infrastruktur und Vorlesungsübertragungen an der TU München. Dr. Sabine Rathmayer Technische Universität München Aufbau einer integrierten elearning- Infrastruktur und Vorlesungsübertragungen an der TU München Dr. Sabine Rathmayer Technische Universität München Die TU München Rahmendaten Einzige technische Universität

Mehr

Vereinfachtes Identity Management bei der Henkel KGaA

Vereinfachtes Identity Management bei der Henkel KGaA Vereinfachtes Identity Management bei der Henkel KGaA Computacenter führt Projekt zur Einrichtung eines konsolidierten Directory-Datenbestandes durch Die Henkel KGaA ist als führender Anbieter von Klebstoffen

Mehr

Informationssicherheit und Compliance-Erfüllung econet Der Weg zum sicheren Umgang mit Informationen und Zugriffsrechten Wohl nirgends in der IT sind gewachsene Strukturen riskanter, als in Dateisystemen

Mehr

Der studentische Arbeitsplatz der Zukunft

Der studentische Arbeitsplatz der Zukunft Der studentische Arbeitsplatz der Zukunft Kerstin Bein Rechenzentrum, Universität Mannheim Agenda Projektziele Anforderungen an die Arbeitsplätze und den Service Herausforderungen an die Technik Serviceleistungen

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Einführungsvortrag REGIONALES RECHENZENTRUM ERLANGEN [RRZE]

Einführungsvortrag REGIONALES RECHENZENTRUM ERLANGEN [RRZE] REGIONALES RECHENZENTRUM ERLANGEN [RRZE] Einführungsvortrag Systemausbildung Grundlagen und Aspekte von Betriebssystemen und System-nahen Diensten, 22.04.2015 Referent: Marcel Ritter, RRZE AGENDA - Ausrichtung

Mehr

Projektbericht. Daniel Löffler E-Mail: daniel.loeffler@fernuni-hagen.de Tel.: +49 2331 987-2868

Projektbericht. Daniel Löffler E-Mail: daniel.loeffler@fernuni-hagen.de Tel.: +49 2331 987-2868 Projektbericht Aufbau & Implementierung eines neuen Identity & Access- Management Systems basierend auf den Forefront Identity Manager 2010 Technischer Teil Daniel Löffler E-Mail: daniel.loeffler@fernuni-hagen.de

Mehr

Technische Produktinformation: Active Directory- Management in bi-cube

Technische Produktinformation: Active Directory- Management in bi-cube Inhalt: 1 bi-cube -FEATURES ACTIVE DIRECTORY... 2 2 DAS SYSTEMKONZEPT... 3 3 WAS SIND ADOC UND ECDOC?... 3 4 DIE WICHTIGSTEN FUNKTIONEN IM ÜBERBLICK... 5 4.1 Verwaltung der Strukturdaten... 5 4.2 Verwaltung

Mehr

Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO an bi-cube IPM

Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO an bi-cube IPM Whitepaper bi-cube SSO Synergien durch die Anbindung eines externen SSO T e c h n o l o g i e n L ö s u n g e n T r e n d s E r f a h r u n g Inhalt 1 ZIEL...3 2 FUNKTIONS-KONZEPT...3 2.1 Struktur...3

Mehr

Identity Management im Münchner Wissenschaftsnetz

Identity Management im Münchner Wissenschaftsnetz Professioneller IT-Betrieb in mittleren und großen Umgebungen Identity Management im Münchner Wissenschaftsnetz 9.12.2010 Dr. Ralf Ebner ebner@lrz.de Leibniz-Rechenzentrum Überblick Identity Management:

Mehr

WENDIA ITSM EXPERT TALK

WENDIA ITSM EXPERT TALK WENDIA ITSM EXPERT TALK WENDIA ITSM WHITEPAPER IT SERVICE MANAGEMENT BASISWISSEN: IN EINFACHEN SCHRITTEN ZUR CMDB Wer, Wie, Was: Die CMDB als Herzstück eines funktionierenden IT Service Management Die

Mehr

IdM-Lösungen in Hochschulen - aktueller Stand, zukünftige Herausforderungen

IdM-Lösungen in Hochschulen - aktueller Stand, zukünftige Herausforderungen IdM-Lösungen in Hochschulen - aktueller Stand, zukünftige Herausforderungen H. Stenzel CampusSource & ITMC TU Dortmund 12.4.2011 IdM tut Not Benutzer eines Systems oder einer Anwendung sind zu identifizieren

Mehr

IT-Dienstleistungszentrum Berlin

IT-Dienstleistungszentrum Berlin IT-Dienstleistungszentrum Berlin»Private Cloud für das Land Berlin«25.11.2010, Kai Osterhage IT-Sicherheitsbeauftragter des ITDZ Berlin Moderne n für die Verwaltung. Private Cloud Computing Private Cloud

Mehr

IT-Symposium. 2E04 Synchronisation Active Directory und AD/AM. Heino Ruddat

IT-Symposium. 2E04 Synchronisation Active Directory und AD/AM. Heino Ruddat IT-Symposium 2006 2E04 Synchronisation Active Directory und AD/AM Heino Ruddat Agenda Active Directory AD/AM Möglichkeiten der Synchronisation Identity Integration Feature Pack Microsoft Identity Integration

Mehr

Der starke Partner für Ihre IT-Umgebung.

Der starke Partner für Ihre IT-Umgebung. Der starke Partner für Ihre IT-Umgebung. Leistungsfähig. Verlässlich. Mittelständisch. www.michael-wessel.de IT-Service für den Mittelstand Leidenschaft und Erfahrung für Ihren Erfolg. Von der Analyse

Mehr

Electures-Portal. Vorstellung und Empfehlungen. 2008-10-31 Christoph Hermann - Universität Freiburg - Institut für Informatik 1

Electures-Portal. Vorstellung und Empfehlungen. 2008-10-31 Christoph Hermann - Universität Freiburg - Institut für Informatik 1 Electures-Portal Vorstellung und Empfehlungen 1 Überblick Gründe für ein neues Electures-Portal Vorhandene Infrastruktur an der Universität Das neue Electures-Portal Rollen und Rechte Empfehlungen 2 Probleme

Mehr

Kaum irgendwo auf der Welt gibt es bessere Möglichkeiten hierzu als in Garching mit seinen exzellenten Hochschul- und Forschungseinrichtungen.

Kaum irgendwo auf der Welt gibt es bessere Möglichkeiten hierzu als in Garching mit seinen exzellenten Hochschul- und Forschungseinrichtungen. Sperrfrist: 29.06.2015, 13.00 Uhr Es gilt das gesprochene Wort. Grußwort des Bayer. Staatsministers für Bildung und Kultus, Wissenschaft und Kunst, Dr. Ludwig Spaenle, bei der Inbetriebnahme der Phase

Mehr

Hochschule Harz (FH) optimiert Benutzerverwaltung mit Comtarsia

Hochschule Harz (FH) optimiert Benutzerverwaltung mit Comtarsia Ressorts: Netzwerke, Sicherheit, Identity-Management, IT-Infrastruktur, Single Sign On, Open Source Text- und Bildmaterial: http://signon.comtarsia.com/main/de/presse PRESSEMITTEILUNG Hochschule Harz (FH)

Mehr

Aufbau einer AAI im DFN. Ulrich Kähler, DFN-Verein kaehler@dfn.de

Aufbau einer AAI im DFN. Ulrich Kähler, DFN-Verein kaehler@dfn.de Aufbau einer AAI im DFN Ulrich Kähler, DFN-Verein kaehler@dfn.de Motivation Physiker aus unterschiedlichen Hochschulen sollen auf einen gemeinsamen Datenbestand zugreifen. Mitarbeiter und Studierende einer

Mehr

FUDIS Freie Universität (Berlin) Directory und Identity Service

FUDIS Freie Universität (Berlin) Directory und Identity Service FUDIS Freie Universität (Berlin) Directory und Identity Service Zentraleinrichtung für Datenverarbeitung (ZEDAT) Compute- und Medien-Service (CMS) Jörg Bechlars und Steffen Hofmann Ausgangssituation Ausgangssituation

Mehr

Status IDMone. 20.02.2008 Sitzung BRZL AK MetaDir, Bamberg Dr. Peter Rygus

Status IDMone. 20.02.2008 Sitzung BRZL AK MetaDir, Bamberg Dr. Peter Rygus Status IDMone 20.02.2008 Sitzung BRZL AK MetaDir, Bamberg Dr. Peter Rygus IDMone: Stand der Arbeiten (1) Erstellt wurden Konzepte für DIT-Struktur User Application arbeitet auf einem Replikat des Meta-

Mehr

Kooperationsmodelle in der Wissenschaft - Beispiel Niedersachsen Storage Cloud

Kooperationsmodelle in der Wissenschaft - Beispiel Niedersachsen Storage Cloud Kooperationsmodelle in der Wissenschaft - Beispiel Niedersachsen Storage Cloud ZKI-Frühjahrstagung Ramin Yahyapour Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen Am Fassberg, 37077

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Configuration Management mit Verbosy 17.04.2013 OSDC 2013. Eric Lippmann www.netways.de

Configuration Management mit Verbosy 17.04.2013 OSDC 2013. Eric Lippmann www.netways.de Configuration Management mit Verbosy 17.04.2013 OSDC 2013 Eric Lippmann Kurzvorstellung NETWAYS Expertise OPEN SOURCE SYSTEMS MANAGEMENT OPEN SOURCE DATA CENTER Monitoring & Reporting Configuration Management

Mehr

securemsp CloudShare Encrypted File Transfer & Collaboration Platform Secure-MSP GmbH 2013

securemsp CloudShare Encrypted File Transfer & Collaboration Platform Secure-MSP GmbH 2013 securemsp CloudShare Encrypted File Transfer & Collaboration Platform Secure-MSP GmbH 2013 Häufig gestellte Fragen... Wie geben wir unseren Zweigstellen Zugang zu sensiblen Daten? Wie komme ich unterwegs

Mehr

12. Shibboleth-Workshop

12. Shibboleth-Workshop 12. Shibboleth-Workshop 23. Mai 2012 Universität Kaiserslautern Raoul Borenius, DFN-Verein Wolfgang Pempe,DFN-Verein Bernd Oberknapp, Universität Freiburg Ulrich Kähler, DFN-Verein Tagesordnung 12. Shibboleth-Workshop

Mehr

Objektkultur Software GmbH. Identity Management Lösungen

Objektkultur Software GmbH. Identity Management Lösungen Objektkultur Software GmbH Identity Management Lösungen Übersicht Lösungsangebot Identity Management Collaboration Process Management Integration Einführung Identity Management Identity Lifecycle Management

Mehr

Verarbeitung personenbezogener Daten bei Errichtung und Betrieb von Verzeichnisdiensten

Verarbeitung personenbezogener Daten bei Errichtung und Betrieb von Verzeichnisdiensten Verarbeitung personenbezogener Daten bei Errichtung und Betrieb von Verzeichnisdiensten Matthias Herber Datenschutzbeauftragter der TU Dresden Kontakt: datenschutz@tu-dresden.de AK Verzeichnisdienste Duisburg,

Mehr

HP User Society. Wir bewirken mehr. DECUS München e.v.

HP User Society. Wir bewirken mehr. DECUS München e.v. DECUS München e.v. Reden Sie mit. 2004 Hewlett-Packard Development Company, L.P. + 2005 DECUS München e.v. The information contained herein is subject to change without notice Wir bewirken mehr. Größte

Mehr

Einführung von. SAP Netweaver Identity Management. bei der. Öffentlichen Versicherung Braunschweig

Einführung von. SAP Netweaver Identity Management. bei der. Öffentlichen Versicherung Braunschweig Einführung von SAP Netweaver Identity Management bei der Öffentlichen Versicherung Braunschweig Axel Vetter (Braunschweig IT), Jörn Kaplan (Acando) Seite 1 Agenda Die Öffentliche Versicherung / Braunschweig

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

AMPUS Inventory. Sie haben die Ressourcen. Wir bieten Ihnen Transparenz. Unternehmensweite Inventarisierung und Diagnose Ihrer IT-Netzwerk-Ressourcen

AMPUS Inventory. Sie haben die Ressourcen. Wir bieten Ihnen Transparenz. Unternehmensweite Inventarisierung und Diagnose Ihrer IT-Netzwerk-Ressourcen Sie haben die Ressourcen. Wir bieten Ihnen Transparenz. Unternehmensweite Inventarisierung und Diagnose Ihrer IT-Netzwerk-Ressourcen Transparente IT-Infrastruktur bei Minimalem Administrationsaufwand Eine

Mehr

do you do it? i-doit OpenSource CMDB Dennis Stücken

do you do it? i-doit OpenSource CMDB Dennis Stücken do you do it? i-doit OpenSource CMDB Dennis Stücken synetics GmbH, 23.04.2009 Agenda Was ist i-doit Was kann i-doit Vorteile Schnittstellen i-doit in der Praxis Aussicht 2 Was ist i-doit? Dokumentationslösung

Mehr

Deckfolie. Überblick. Meta-Directory. Ronny John, HRZ Darmstadt

Deckfolie. Überblick. Meta-Directory. Ronny John, HRZ Darmstadt Deckfolie Überblick Meta-Directory Ronny John, HRZ Darmstadt 1 Übersicht 1. Historie 2. NDS 3. Anwendungen 4. Leitgedanken und Ziele 5. Verzeichnis-Struktur 6. Rechteregeln 7. Schluss: Fragen und Diskussion

Mehr

Neue Technologien. Belastung oder Entlastung im Vertrieb?

Neue Technologien. Belastung oder Entlastung im Vertrieb? Neue Technologien Belastung oder Entlastung im Vertrieb? Was sind neue Technologien? Mobile Systeme Smartphones / Tablets / Notebooks Kunden Apps (Makler oder Fintech ) Vertriebs Apps Cloud Systeme (Rechenzentrum)

Mehr

Centre of Excellence for High Performance Computing Erlangen Kompetenzgruppe für Supercomputer und Technisch-Wissenschaftliche Simulation

Centre of Excellence for High Performance Computing Erlangen Kompetenzgruppe für Supercomputer und Technisch-Wissenschaftliche Simulation 1 Centre of Excellence for High Performance Computing Erlangen Kompetenzgruppe für Supercomputer und Technisch-Wissenschaftliche Simulation Dr. G. Wellein, Regionales Rechenzentrum Erlangen Supercomputer

Mehr

Cloud Services für den Mittelstand

Cloud Services für den Mittelstand Cloud Services für den Mittelstand Unsere Interpretation des Begriffes Cloud Was verstehen Sie unter Cloud? Zugriff auf E-Mails und Dateien im Netz? Das ist uns zu wenig! Wie wäre es, Ihre komplette und

Mehr

How to IT. IT-services at TU München

How to IT. IT-services at TU München How to IT IT-services at TU München Schedule How to get access to the internet Moodle forum + free software TUM-Online Schedule How to get access to the internet Moodle forum + free software TUM-Online

Mehr

Evolution der Schnittstelle zwischen IdM & Campus Management

Evolution der Schnittstelle zwischen IdM & Campus Management Evolution der Schnittstelle zwischen IdM & Campus Management ZKI Arbeitskreis Verzeichnisdienste - Frankfurt, 10.März 2011 Datenlotsen Informationssysteme GmbH, Thomas Werner Agenda 2 Campus Integration

Mehr

Sicherheitsaspekte der Langzeitarchivierung am Leibniz- Rechenzentrum. 09. Juni 2011. Rosa Freund Rosa.Freund@lrz.de

Sicherheitsaspekte der Langzeitarchivierung am Leibniz- Rechenzentrum. 09. Juni 2011. Rosa Freund Rosa.Freund@lrz.de Sicherheitsaspekte der Langzeitarchivierung am Leibniz- Rechenzentrum 09. Juni 2011 Rosa Freund Rosa.Freund@lrz.de Das Leibniz-Rechenzentrum ist Gemeinsames Rechenzentrum für alle Münchner Hochschulen

Mehr

Identity-Management flexible und sichere Berechtigungsverwaltung

Identity-Management flexible und sichere Berechtigungsverwaltung Identity-Management flexible und sichere Berechtigungsverwaltung Neue Herausforderungen im nationalen und internationalen Einsatz erfordern dynamische IT- Prozesse Bonn, 06. November 2009 Herausforderungen

Mehr

Umstieg auf Microsoft Exchange in der Fakultät 02

Umstieg auf Microsoft Exchange in der Fakultät 02 Umstieg auf Microsoft Exchange in der Fakultät 02 Der IT-Steuerkreis der Hochschule München hat am am 26.07.12 einstimmig beschlossen an der Hochschule München ein neues Groupware-System auf der Basis

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

MSXFORUM - Exchange Server 2007 > Exchange 2007 - Architektur

MSXFORUM - Exchange Server 2007 > Exchange 2007 - Architektur Page 1 of 5 Exchange 2007 - Architektur Kategorie : Exchange Server 2007 Veröffentlicht von webmaster am 18.03.2007 Warum wurde die Architektur in der Exchange 2007 Version so überarbeitet? Der Grund liegt

Mehr

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor.

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor. Cloud Computing im Gesundheitswesen Cloud Computing ist derzeit das beherrschende Thema in der Informationstechnologie. Die Möglichkeit IT Ressourcen oder Applikationen aus einem Netz von Computern zu

Mehr

Sicherheit: Ergebnisse aus D-Grid 1 und Ausblick auf D-Grid 2

Sicherheit: Ergebnisse aus D-Grid 1 und Ausblick auf D-Grid 2 Sicherheit: Ergebnisse aus D-Grid 1 und Ausblick auf D-Grid 2 DGI-2 FG3 Sicherheit 3. Security Workshop Göttingen 1.-2. April 2008 Marcus Pattloch, DFN-Verein Sicherheit im D-Grid (1) Notwendiger Service

Mehr

Identity Management im Münchner Wissenschaftsnetz

Identity Management im Münchner Wissenschaftsnetz Professioneller IT-Betrieb in mittleren und großen Umgebungen Identity Management im Münchner Wissenschaftsnetz 7.12.2011 Dr. Ralf Ebner ebner@lrz.de Leibniz-Rechenzentrum Überblick Identity Management:

Mehr

Impressum. Schlusswort

Impressum. Schlusswort Schlusswort Neben den großen Projekten wie der Einführung der IP-Telefonie, dem Netzausbau, dem elektronischen Eignungsfeststellungs- und Hochschulauswahlverfahren und dem neuen Studierenden Ausweis (ecus)

Mehr

Der kleine ALOIS und der aktive Verzeichnisdienst

Der kleine ALOIS und der aktive Verzeichnisdienst Der kleine ALOIS und der aktive Verzeichnisdienst oder Identity-Management an der Universität Augsburg Maria Schmaus, Rechenzentrum 5. Oktober 2010 Es war einmal Überblick IT-Landschaft der Universität

Mehr

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0

Gauß-IT-Zentrum. DHCP für Institute. Zielgruppe: DV Koordinatoren. Version 1.0 Gauß-IT-Zentrum DHCP für Institute Zielgruppe: DV Koordinatoren Version 1.0 1 DHCP für Institute Inhalt Dynamic Host Configuration Protocol (DHCP) für Institute 2 DHCP-Interface im KDD 2 DHCP beantragen

Mehr

Sichere Web-Services in einem föderierten Umfeld

Sichere Web-Services in einem föderierten Umfeld Sichere Web-Services in einem föderierten Umfeld ZKI Arbeitskreis Verzeichnisdienste ZEDAT FU Berlin Axel Maurer Die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH) integrierte

Mehr

10 Jahre Identity Management Stand, Entwicklungen, Resümee

10 Jahre Identity Management Stand, Entwicklungen, Resümee 10 Jahre Identity Management Stand, Entwicklungen, Resümee Hartmut Hotzel, Andreas Böck Hochschule München, ZaK ZKI AK Verzeichnisdienste 2008-11-04 Themen Strategische Sicht (Hartmut Hotzel) Informationen

Mehr

ITSM (BOX & CONSULTING) Christian Hager, MSc

ITSM (BOX & CONSULTING) Christian Hager, MSc ITSM (BOX & CONSULTING) Christian Hager, MSc INHALT Ausgangssituation ITSM Consulting ITSM Box Zentrales Anforderungsmanagement Beispielhafter Zeitplan Nutzen von ITSM Projekten mit R-IT Zusammenfassung

Mehr

Grid-Computing am LRZ 1. Schritt: GSI-SSH

Grid-Computing am LRZ 1. Schritt: GSI-SSH Grid-Computing am LRZ 1. Schritt: GSI-SSH Dr. Helmut Heller und das Grid-Team Verteilte Ressourcen Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften 14.1.2010 1 Überblick Vorteile von Grid

Mehr

Systemüberwachung / Monitoring

Systemüberwachung / Monitoring REGIONALES RECHENZENTRUM ERLANGEN [RRZE] Systemüberwachung / Monitoring Systemausbildung Grundlagen und Aspekte von Betriebssystemen und System-nahen Diensten Uwe Scheuerer, RRZE, 24.06.2015 Agenda Wozu

Mehr

PROFIL REFERENZEN 2015

PROFIL REFERENZEN 2015 PROFIL REFERENZEN 2015 Gartenstraße 24 D-53229 Bonn +49 228 / 976 17-0 +49 228 / 976 17-55 info@glamus.de www.glamus.de KURZPROFIL ÜBER UNS Gründung 1992 Geschäftsführer Gerhard Loosch Ulrich Santo Mitarbeiterzahl

Mehr

Rezentralisierung von. Michael Storz Team Leiter E Mail

Rezentralisierung von. Michael Storz Team Leiter E Mail Rezentralisierung von E Mail Services MilS i Michael Storz Team Leiter E Mail Leibniz Rechenzentrum Ausgangssituation ti (1) bis 1994 virtuelle Maildomains (X.400) am LRZ für Mitarbeiter der TUM seit 1995

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features Seite 2 von 12 1. Übersicht MIK.arjuna ist eine 64-bit multidimensionale Datenbank,

Mehr

MailStore Service Provider Edition (SPE)

MailStore Service Provider Edition (SPE) MailStore Solutions MailStore Service Provider Edition (SPE) E-Mail-Archivierung für Service Provider Mit Hilfe der MailStore Service Provider Edition können Sie Ihren Kunden moderne E-Mail-Archivierung

Mehr

Das Citrix Delivery Center

Das Citrix Delivery Center Das Citrix Delivery Center Die Anwendungsbereitstellung der Zukunft Marco Rosin Sales Manager Citrix Systems GmbH 15.15 16.00 Uhr, Raum B8 Herausforderungen mittelständischer Unternehmen in einer globalisierten

Mehr

TELEKOM CLOUD COMPUTING. NEUE PERSPEKTIVEN. Dietrich Canel Telekom Deutschland GmbH 03/2013 1

TELEKOM CLOUD COMPUTING. NEUE PERSPEKTIVEN. Dietrich Canel Telekom Deutschland GmbH 03/2013 1 TELEKOM CLOUD COMPUTING. NEUE PERSPEKTIVEN. Dietrich Canel Telekom Deutschland GmbH 03/2013 1 DIE TELEKOM-STRATEGIE: TELCO PLUS. 2 AKTUELLE BEISPIELE FÜR CLOUD SERVICES. Benutzer Profile Musik, Fotos,

Mehr

Dynamic Cloud Services

Dynamic Cloud Services Dynamic Cloud Services VMware Frühstück I 2011 Bei IT-On.NET Düsseldorf Infrastructure as a Service 1 Wir begleiten Sie in die Cloud! IT-Service IT-Security IT-Infrastruktur Internet 2 Der Markt Markttrends

Mehr

Quest Software Unternehmensportrait

Quest Software Unternehmensportrait Quest Software Unternehmensportrait Roland Petersen Technical Partner Manager Unsere Vision Mit innovativen Lösungen IT-Abläufe effizienter gestalten und dabei Zeit und Kosten sparen. 1 2 Die Lösungen

Mehr

Der Arbeitsplatz der Zukunft ist heterogen: Mobile Endgeräte, Consumerization & Virtualisierung als Chance für Anwender und IT

Der Arbeitsplatz der Zukunft ist heterogen: Mobile Endgeräte, Consumerization & Virtualisierung als Chance für Anwender und IT Der Arbeitsplatz der Zukunft ist heterogen: Mobile Endgeräte, Consumerization & Virtualisierung als Chance für Anwender und IT Patrick Sauerwein Senior Product Manager 01 Aktuelle Herausforderungen ARBEITSPLATZ

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

08. Juni 2004. Best Practice Mandantenfähige Remote Access Plattform

08. Juni 2004. Best Practice Mandantenfähige Remote Access Plattform 08. Juni 2004 Best Practice Mandantenfähige Remote Access Plattform 08.06.2004 Seite 1 GenoTel Zahlen und Fakten Geschäftsaufnahme - 2000 Gesellschafter - DZ BANK AG - R+V Versicherung AG Sitz - Frankfurt

Mehr

Die FUTUREDAT GmbH. Unsere Partner. Die FUTUREDAT GMBH UNTERSTÜTZT SIE BEI

Die FUTUREDAT GmbH. Unsere Partner. Die FUTUREDAT GMBH UNTERSTÜTZT SIE BEI fit for future Beratung * LÖSUNGSFINDUNG * UMSETZUNG * WEITERBILDUNG * BETREUUNG Die FUTUREDAT GMBH UNTERSTÜTZT SIE BEI der PLANUNG Ihrer Client- Management-, IT-, ERPund Datenbank-Projekte der schrittweisen

Mehr