Jahresbericht 2012 Des Leibniz-Rechenzentrums I

Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften

Jahresbericht

2012

Juli 2013 LRZ-Bericht 2013-01

Direktorium: Leibniz-Rechenzentrum Prof. Dr. A. Bode (Vorsitzender) Boltzmannstraße 1 Telefon: (089) 35831-8000 Öffentliche Verkehrsmittel: Prof. Dr. H.-J. Bungartz 85748 Garching b. München Telefax: (089) 35831-9700 Prof. Dr. H.-G. Hegering E-Mail: [email protected] U6: Garching-Forschungszentrum Prof. Dr. D. Kranzlmüller UST-ID-Nr. DE811335517 Internet: http://www.lrz.de

Jahresbericht 2012 des Leibniz-Rechenzentrums i

Vorwort ...... 1

1 Überblick ...... 4

2 Hochleistungsrechnen und Grid ...... 6 2.1 Schwerpunkte der Arbeit und neue Abteilungsstruktur ...... 6 2.2 Supercomputing ...... 6 2.2.1 SuperMUC: Ein neuer Höchstleistungsrechner für Europa ...... 6 2.2.2 Installation und Inbetriebnahme des SuperMUC ...... 9 2.2.3 Betrieb des Höchstleistungsrechners SuperMUC ...... 9 2.2.4 Benutzerverwaltung für die Hochleistungssysteme...... 10 2.2.5 Nutzungsstatistik ...... 10 2.3 Linux-Cluster ...... 13 2.3.1 Übersicht über die Cluster-Systeme ...... 13 2.3.2 Erweiterung des wassergekühlten Clusters von MEGWare / MAC-Cluster ...... 13 2.3.3 Betrieb der Cluster-Systeme ...... 14 2.3.4 Tests und Prototypen ...... 14 2.3.5 GPGPU-System ...... 14 2.3.6 Nutzungsstatistiken ...... 14 2.4 Technisch-wissenschaftliche Software ...... 16 2.5 Remote Visualisierung ...... 16 2.6 Projekte im Hochleistungsrechnen ...... 16 2.6.1 Gauss Centre for Supercomputing (GCS) ...... 16 2.6.2 KONWIHR ...... 18 2.6.3 Partnership for Advanced Computing in Europe: PRACE ...... 18 2.6.4 DEEP ...... 19 2.6.5 Mont-Blanc ...... 19 2.6.6 AutoTune ...... 20 2.6.7 ScalaLife ...... 20 2.6.8 Arbeiten für die Antragstellung REACT ...... 20 2.6.9 Arbeiten für die Antragstellung FEPA ...... 20 2.6.10 PROSPECT e.V...... 21 2.6.11 ETP4HPC ...... 21 2.7 Benutzerunterstützung für Hochleistungssysteme ...... 21 2.7.1 Benutzeranfragen ...... 21 2.7.2 Kurse und Ausbildung ...... 21 2.7.3 Standardisierungs-Aktivitäten im Bereich der parallelen Programmierung ...... 22 2.7.4 Öffentlichkeitsarbeit ...... 22 2.8 Grid-Dienste ...... 23 2.9 Projekte im Grid-Computing ...... 25 2.9.1 Initiative for Globus in Europe (IGE) ...... 25 2.9.2 D-Grid (Förderung „e-Science und vernetztes Wissensmanagement“ des BMBF) ...... 25 2.9.3 EGI-InSPIRE ...... 26 2.9.4 VERCE ...... 27 2.9.5 MAPPER ...... 27 2.9.6 DRIHM ...... 27 2.9.7 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3) ...... 28 2.9.8 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) ...... 28

ii Inhaltsverzeichnis

3 Serverbetrieb ...... 30 3.1 Linux-Server ...... 30 3.2 Windows ...... 31

4 Datenhaltung ...... 33 4.1 Überblick Datenhaltung ...... 33 4.2 Archiv- und Backupsystem ...... 33 4.2.1 Konfiguration ...... 33 4.2.2 Aktivitäten ...... 38 4.2.3 Statistik ...... 40 4.2.4 Plattform für digitale Langzeitarchivierung ...... 42 4.2.5 Projekt Rosetta ...... 43 4.2.6 Projekt Google ...... 44 4.3 Datenbanken und Web-Schnittstellen für den Betrieb der Supercomputer am LRZ...... 46 4.4 Online-Speicher ...... 46 4.4.1 Konfiguration und Entwicklung im Überblick ...... 46 4.4.2 Hochverfügbarer Speicher für virtuelle Server ...... 47 4.4.3 MWN-Speicher ...... 48 4.4.4 Sonstige Aktivitäten...... 50 4.5 Daten- und Archivräume ...... 51

5 Internetdienste ...... 53 5.1 E-Mail ...... 53 5.1.1 Ersatz des Dienstes Mailout durch Postout...... 53 5.1.2 Neuer Webmailer Roundcube ...... 53 5.1.3 Spezielle Markierung von Newslettern...... 53 5.1.4 Snowshoe-Spam ...... 54 5.1.5 Virenabwehr ...... 54 5.1.6 SRS – Sender Rewriting Scheme ...... 54 5.1.7 Einsatz von Puppet mit Subversion ...... 55 5.1.8 Maximale Mailgröße erhöht ...... 55 5.1.9 Statistiken ...... 55 5.2 Exchange ...... 58 5.2.1 Statistik zur Nutzung des Exchange-Dienstes ...... 58 5.3 Sharepoint ...... 58 5.4 Webhosting ...... 59 5.4.1 E-Learning ...... 59 5.4.2 TUM-Portal ...... 59 5.4.3 Userweb und Research ...... 59 5.4.4 Downloadbereiche zur Softwareverteilung ...... 59 5.4.5 Neuauflage des Webauftritts der BAdW ...... 60 5.4.6 Redesign des Webauftritts des LRZ ...... 60 5.4.7 Webhosting-Statistik...... 60 5.5 Serveradministration und Applikationsunterstützung ...... 62 5.5.1 Serveradministration in BDS ...... 62 5.6 Streamingserver ...... 63

Jahresbericht 2012 des Leibniz-Rechenzentrums iii

6 Netzdienste für Institutionen ...... 64 6.1 Struktur und Betrieb des Münchner Wissenschaftsnetzes (MWN) ...... 64 6.1.1 Struktur des Backbone Netzes ...... 69 6.1.2 Router Auswahl ...... 70 6.1.3 Struktur der Gebäude-Netze im MWN ...... 71 6.1.4 Struktur des Rechenzentrumsnetzes (RZ-Netz)...... 72 6.2 Anschluss ans MWN; Wesentliche Änderungen im Netz ...... 73 6.2.1 Wesentliche Netzänderungen im Jahr 2012 ...... 73 6.2.2 Netzausbau (Verkabelung); Netzinvestitionsprogramm...... 74 6.2.3 Anbindung Studentenwohnheime...... 75 6.3 DNS und Sicherheit im DNS ...... 77 6.3.1 DNS-Amplifikation-Attacks und offene Resolver ...... 79 6.4 DHCP ...... 80 6.5 Radius ...... 80 6.6 Netzkomponenten-Beratung ...... 82 6.6.1 Switch-Auswahl ...... 83 6.7 Telefonie ...... 83 6.7.1 Zugang über UMTS ...... 83 6.8 Unterstützende Infrastruktur-Dienste ...... 83 6.8.1 Service Load Balancer (SLB) ...... 83 6.8.2 IPv6 ...... 85 6.8.3 Wellenlängenmultiplexer ...... 86 6.8.4 IP-Multiplexer ...... 87 6.9 Netzmanagement und –monitoring ...... 88 6.9.1 Netzmanagement ...... 88 6.9.2 Netzdokumentation ...... 89 6.9.3 Überwachung der Dienstqualität ...... 95 6.9.4 Evaluation VistaFoundation Kit 4.3 ...... 95 6.9.5 Reporting für Netzverantwortliche ...... 96 6.10 Projekte im Bereich Netze ...... 96 6.10.1 D-Grid GIDS ...... 96 6.10.2 SASER ...... 98 6.10.3 Customer Network Management (CNM) ...... 99 6.10.4 Projekte im Rahmen von Géant ...... 101 6.10.5 Projekte im Rahmen von Geant3 ...... 103

7 Netzdienste für Endanwender ...... 106 7.1 Internetzugang und LAN ...... 106 7.2 WLAN und Eduroam ...... 108 7.2.1 WLAN-Ausbau im Gebäude der Fakultät Maschinenwesen ...... 110 7.2.2 WLAN-Auswahl ...... 111 7.2.3 Eduroam ...... 111 7.2.4 Unterstützung von Veranstaltungen ...... 112 7.3 VPN ...... 113 7.3.1 Technik ...... 113 7.3.2 VPN-Software ...... 113 7.3.3 Telearbeitsplätze von LRZ-Mitarbeitern ...... 113

iv Inhaltsverzeichnis

7.3.4 Entwicklung des Datenverkehrs über die VPN-Server ...... 113 7.4 Modem / ISDN ...... 115

8 Virtual Reality und Visualisierung ...... 117 8.1 Sichtbarkeit und Öffentlichkeitsarbeit ...... 117 8.2 Kooperationen ...... 118 8.3 Forschung und Lehre ...... 118

9 IT-Service-Management ...... 120 9.1 IT-Service-Management: Einführung von ISO/IEC 20000 ...... 120 9.1.1 Incident-Management ...... 120 9.1.2 Weitere ITSM-Prozesse ...... 121 9.1.3 Sonstige Aktivitäten...... 121 9.2 Service-Management-Plattform Action Request System ...... 122 9.3 Servicedesk ...... 122

10 Informationen und Weiterbildung ...... 123 10.1 Kurse und Veranstaltungen ...... 123 10.1.1 Kursübersicht, Statistik 2012 ...... 123 10.1.2 Kurse und Ausbildung im Bereich Hochleistungsrechnen ...... 124 10.2 Vorträge „Schattenseiten des Internet“ ...... 124 10.3 Öffentlichkeitsarbeit ...... 125

11 Software-Bezug und Lizenzen ...... 127 11.1 Bundesweiter Rahmenvertrag für Microsoft-Lizenzen ...... 127 11.2 Überregionaler Rahmenvertrag zum Bezug von Beratungs- und Supportdienstleistungen zu Microsoft-Produkten ...... 127 11.3 Bayernweiter Mietvertrag für Adobe-Lizenzen...... 127 11.4 Vereinfachung der Versorgung mit ESRI-Lizenzen an der TU München ...... 127 11.5 Vereinfachung der Versorgung mit Mathematica-Lizenzen an der LMU München ...... 128 11.6 Weitere laufende Verhandlungen und Planungen ...... 128 11.7 Tagesgeschäft ...... 128 11.7.1 Abläufe und Änderungen bei der Versorgung der Kunden des LRZ ...... 128 11.7.2 Routinemäßige Verlängerung und Ausbau bestehender Verträge ...... 129 11.7.3 Betrieb von Lizenzservern für Kunden des LRZ ...... 129

12 Benutzerverwaltung und Verzeichnisdienste ...... 130 12.1 Benutzerverwaltung für LRZ-Dienste ...... 130 12.1.1 Für LRZ-Systeme vergebene Kennungen ...... 130 12.1.2 Identity Management und Verzeichnisdienste ...... 131 12.2 CampusLMU und TUMonline ...... 135 12.2.1 CampusLMU-Anbindung ...... 135 12.2.2 TUMonline-Anbindung ...... 135 12.3 MWN Active Directory ...... 136 12.4 DFN-AAI/Shibboleth ...... 137

Jahresbericht 2012 des Leibniz-Rechenzentrums v

12.4.1 Entwicklungen im Identity-Provider-Dienstbetrieb ...... 137 12.4.2 Anpassungen für spezielle Service Provider ...... 137

13 Dienste mit Sondervereinbarungen...... 139 13.1 Bibliotheksverbund Bayern ...... 139 13.2 Managed Hosting für hochschulstart.de ...... 139

14 IT-Sicherheit ...... 140 14.1 Antivirus ...... 140 14.2 WSUS ...... 140 14.3 Virtuelle Firewall ...... 140 14.4 Sicherheitswerkzeuge und Sicherheitsmanagement ...... 141 14.4.1 Secomat ...... 141 14.4.2 Security Information & Event Management...... 143 14.4.3 Nessi ...... 144 14.4.4 Nyx ...... 144 14.5 Server- und Benutzerzertifizierung nach X.509 ...... 145

15 Arbeitsplätze ...... 146 15.1 Windows ...... 146 15.2 Linux-Mitarbeiter-PCs ...... 146 15.3 Rechnerpools und Spezialarbeitsplätze ...... 146

16 Interna ...... 149 16.1 Personal ...... 149 16.1.1 Personalausstattung ...... 149 16.1.2 Personalveränderungen 2012 ...... 149 16.2 Gebäude und Infrastruktur ...... 149 16.2.1 Gebäudemanagement ...... 149 16.2.2 Energieeffizienz ...... 150 16.3 Das LRZ als Ausbildungsbetrieb ...... 150 16.4 Dienstleistungskatalog...... 151 16.5 Management-Tools, Dokumentation und Dienstleistungsbaum ...... 151 16.6 Mitarbeit in Gremien ...... 151 16.6.1 Abteilung „Benutzernahe Dienste und Systeme“ ...... 152 16.6.2 Abteilung „Hochleistungssysteme“ ...... 152 16.6.3 Abteilung „Kommunikationsnetze“ ...... 153 16.6.4 Abteilung „Zentrale Dienste“ ...... 153 16.7 Veranstaltungen am LRZ ...... 154 16.8 Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen ...... 156 16.8.1 Abteilung „Benutzernahe Dienste und Systeme“ ...... 156 16.8.2 Abteilung „Hochleistungssysteme” ...... 157 16.8.3 Abteilung „Kommunikationsnetze“ ...... 161 16.8.4 Abteilung „Zentrale Dienste“ ...... 162 16.9 Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten ...... 164 16.10 Veröffentlichungen der Mitarbeiter 2012 ...... 165

vi Inhaltsverzeichnis

16.11 Promotionen und Habilitationen am LRZ ...... 169

17 Technische Ausstattung ...... 170 17.1 Datenspeicher ...... 170 17.2 Rechner und Server ...... 171 17.2.1 Höchstleistungsrechner SuperMUC ...... 171 17.2.2 Migrationssystem SuperMIG (IBM BladeCenter HX5) ...... 172 17.2.3 Hochleistungs-Linux-Systeme ...... 172 17.2.4 Grid-Rechner ...... 174 17.2.5 Hochleistungs-Graphik-System ...... 174 17.2.6 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner ...... 175 17.3 Netzkomponenten ...... 179 17.3.1 Router ...... 179 17.3.2 Switches ...... 179 17.3.3 WLAN-Komponenten ...... 180 17.3.4 Netz-Server ...... 180

Jahresbericht 2012 des Leibniz-Rechenzentrums, Vorwort 1

Vorwort 2012 war ein außergewöhnliches Jahr für das Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften: unter großer Anteilnahme hochrangiger und internationaler Festgäste, aktueller und ehemaliger Mitarbeiter, Kunden und Kooperationspartner konnte das LRZ am 20. Juli nicht nur seinen 50. Geburtstag feiern, sondern auch die äußerst erfolgreiche Inbetriebnahme des Höchstleistungsrechners SuperMUC, leistungsfähigster Rechner in Europa und Platz vier der Welt! Der vorliegende Jahresbericht dokumentiert wiederum die gestiegene regionale, nationale und internationale Bedeutung des LRZ als Wissenschafts-Rechenzentrum mit vielfältigen Dienstleistungen für For- schung, Lehre und Verwaltung. Die von allen anerkannte Stellung des LRZ konnte nur erreicht werden, weil die Förderer des LRZ mit großer Weitsicht nachhaltig die Arbeit dieser einmaligen Einrichtung finanzieren, allen voran die Bayeri- sche Staatsregierung und speziell das Bayerische Staatsministerium für Wissenschaft, Forschung und Kunst, dem wir zu großem Dank verpflichtet sind. Den Mitarbeiterinnen und Mitarbeitern des LRZ möchte ich für ihre engagierte Arbeit danken. Mein be- sonderer Dank gilt aber auch der Bayerischen Akademie der Wissenschaften, den Mitgliedern des Len- kungsausschusses 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 Hans- Joachim Bungartz, Dieter Kranzlmüller und Heinz-Gerd Hegering, die ihre große Fachkompetenz in die

Prof. Dr. Karl-Heinz Hoffmann, Präsident der BAdW, Martina Koederitz, Geschäftsführerin IBM Deutschland GmbH, Bundesministerin Prof. Dr. Annette Schavan, Prof. Dr. Bernd Huber, Präsi- dent der LMU, Staatsminister Dr. Wolfgang Heubisch, Prof. Dr. Wolfgang A. Herrmann, Präsi- dent der TUM, Prof. Dr. Arndt Bode, Vorsitzender des Direktoriums des LRZ, Prof. Dr. Heinz- Gerd Hegering, Direktoriumsmitglied des LRZ und Prof. Dr. Achim Bachem, Vorstandsvorsit- zender des Forschungszentrums Jülich (v.l.n.r.) bei der Feier am 20. Juli 2012

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 Aufgaben-

2 Vorwort stellung und das LRZ als Institution transparenter machen. Das LRZ nimmt aufgrund seiner Größe und Organisationsform, des Umfangs seines Versorgungsbereiches, der Anzahl seiner Nutzer, Anzahl, Viel- falt und Heterogenität der Systeme, Beteiligung an Entwicklungsprojekten usw. eine deutliche Sonder- stellung ein, die auch im Bericht sichtbar wird. Eine moderne IT-Infrastruktur ist essentiell für die Wettbewerbsfähigkeit der Hochschulen und des Lan- des, und so muss auch das IT-Kompetenzzentrum fest 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 For- schung und Entwicklung in den Bereichen Kommunikationssysteme, IT-Managementprozesse, Computa- tional Science und Grid-Computing. Hierzu zählen auch die Initiativen im Rahmen von ISO/IEC 20000.

Ich danke für die gute Zusammenarbeit mit Ihnen im Jahr 2012 und freue mich auf alle gemeinsamen Vorhaben im Jahr 2013.

Univ.-Prof. Dr. Arndt Bode Vorsitzender des Direktoriums des Leibniz-Rechenzentrums

Jahresbericht 2012 des Leibniz-Rechenzentrums 3

4 Überblick

1 Überblick Herausragende Ereignisse waren im Jahr 2012 die Verleihung des Deutschen Rechenzentrumspreises 2012 in der Kategorie "Energie- und Ressourceneffiziente Rechenzentren", die Festveranstaltung zum 50- jährigen Bestehen der Kommission für Informatik sowie zur Inbetriebnahme des neuen europäischem Höchstleistungsrechners am 20. Juli 2012 im Beisein von Bundesministerin Annette Schavan und des bayerischen Wissenschaftsministers Wolfgang Heubisch und die erfolgreiche Installation und Eröffnung des Zentrums für virtuelle Realität und Visualisierung (V2C).

Abbildung 1 Prof. Dr. Karl-Heinz Hoffmann, Präsident der BAdW, Prof. Dr. Arndt Bode, Vorsitzen- der des Direktoriums des LRZ, Martina Koederitz, Geschäftsführerin IBM Deutschland GmbH, Bundesministerin Prof. Dr. Annette Schavan und Staatsminister Dr. Wolfgang Heubisch (v.l.n.r.) bei der Feier am 20. Juli 2012

Nach der erfolgreichen Inbetriebnahme des SuperMUC (Platz 4 weltweit, Platz 1 in Europa auf der Top500-Liste vom Juni 2012) sind hier die Aktivitäten zum Ausbau der Stellung des LRZ als ein Europä- isches Zentrum für Supercomputing, das seine Dienste eingebettet in GCS und die europäische Infrastruk- tur PRACE (Partnership for Advanced Computing in Europe) einbringt, zu benennen. Im Hinblick auf die zukünftige Versorgung mit Höchstleistungsrechnerkapazität haben Bund und Länder im Jahr 2012 zusätzliche Mittel im Rahmen des Förderprojektes PetaGCS in Höhe von weiteren € 52 Mio. (damit insgesamt € 400 Mio.) für das GCS für Phase 2 zur Verfügung gestellt. Personell ist und war das LRZ bzw. das Direktorium durch Prof. Hegering als Leiter des GCS e.V. (Verlängerung bis Frühjahr 2013), mit Prof. Bode als Vertreter der Bayerischen Akademie der Wissenschaften im Vorstand von GCS sowie als Deutscher Vertreter im PRACE Council, als Mitglied des Verwaltungsrates der European Open File Systems Initiative (EOFS) sowie Gründungmitglied der European Technology Platform for High Performance Computing ETP4HPC und mit Prof. Kranzlmüller als deutschem Vertreter des NGI-DE in EGI in nationale und europäische Aktivitäten eingebunden.

Jahresbericht 2012 des Leibniz-Rechenzentrums 5

Weitere herausragende Ereignisse im Jahr 2012 waren:  Ausbau der Mail-, Groupware- und E-Learning-Dienste für die Münchner Hochschulen, auch bedingt durch den „doppelten“ Studienjahrgang  Ausbau des Münchner Wissenschaftsnetzes, ebenfalls bedingt durch den „doppelten Studienjahr- gang“  Ausbau der Dienstleistungen in den Bereichen Virtuelle Server, Desktop Management, eLearning Plattformen und Digitale Langzeitarchivierung  Professionalisierung verschiedener Dienste (u.a. Sicherheit)  Weitere Rezentralisierung (Übernahme überregionaler Aufgaben)  Einwerbung weiterer Drittmittelprojekte; das LRZ ist aktuell an 13 EU- und 2 BMBF-Projekten beteiligt  Tag der offenen Tür am 27.10.2012 mit etwa 1.500 Besuchern  Antrag und erfolgreiche Umsetzung zahlreicher Großgeräteanträge der DFG (insbes. zum Aufbau eines Visualisierungs- und Virtual-Reality-Zentrums, für ein Hochleistungs-Archiv- und Backup- System, zum Ausbau des Kommunikationsnetzes und zur Modernisierung der IT-Infrastruktur des Bibliotheksverbunds Bayern). Die Planung aller Aktivitäten erfolgt in direkter Absprache mit den Hochschulleitungen von LMU und TUM. Der Umfang der Dienstleistungen des LRZ nahm auch im Berichtsjahr weiter zu. Allerdings ist anzumer- ken, dass die vielfachen Aktivitäten im EU-Umfeld sowie der Inbetriebnahme des SuperMUC und der Planung der Erweiterung des Höchstleistungsrechners (SuperMUC Phase 2) große personelle Ressourcen binden, die nur durch einen außerordentlichen persönlichen Einsatz der Mitarbeiter erfolgreich zu erledi- gen waren. Darüber wird im Folgenden ausführlich berichtet.

6 Hochleistungsrechnen und Grid

2 Hochleistungsrechnen und Grid

2.1 Schwerpunkte der Arbeit und neue Abteilungsstruktur Der Schwerpunkt der Aktivitäten der Abteilung Hochleistungssysteme bestand in der Installation und Abnahme des zum Lieferzeitpunkt leistungsfähigsten Rechensystems in Europa SuperMUC und der zu seinem Betrieb notwendigen Infrastruktur. Diese Aktivitäten gingen einher mit der Umstrukturierung der Abteilung Hochleistungssysteme, in der es seit Mai statt bisher vier Gruppen nunmehr fünf gibt:  APP: Applikationsunterstützung  HPC: HPC Server u. Dienste  DAT: Datenhaltung  ITS: IT-Infrastruktur Server und Dienste  VER: Verteilte Ressourcen

2.2 Supercomputing

2.2.1 SuperMUC: Ein neuer Höchstleistungsrechner für Europa Nach einer Betriebszeit von fünf Jahren wurde der Höchstleistungsrechner in Bayern (HLRB II), eine SGI Altix 4700, Ende Oktober 2011 außer Betrieb genommen und durch ein wesentlich leistungsfähigeres System mit dem Namen SuperMUC ersetzt. Bei SuperMUC handelt es sich um die erste Ausbaustufe eines Clustersystems der Firma IBM, das aus 19 miteinander gekoppelten Rechnerinseln besteht. Das System wurde im obersten Stockwerk des erweiterten Rechnerkubus des LRZ installiert. Die für 2014/2015 geplante zweite Installationsstufe wird dann zusätzlich den Platz des bisherigen Rechners im Bestandsbau einnehmen. Die Leistungsdaten des neuen Systems sind bereits in der ersten Ausbaustufe imposant: SuperMUC besteht aus 9.400 Rechenknoten mit insgesamt 155.656 Prozessorkernen. Die Spitzenleistung des Systems beträgt 3,2 Petaflops (drei PetaFlop/s, das sind drei Billiarden Rechenoperationen pro Sekunde oder eine 3 mit 15 Nullen). Darüber hinaus ist der Supercomputer mit über 300 TByte Arbeitsspeicher sowie 12 PByte Hintergrundspeicher ausgestattet. Alle Rechenknoten sind über ein FDR10-Infinibandnetz mit einer Bisektrionsbandbreite von 35,6 TByte/s untereinander verbunden. Nach den fast vier Monate dauernden Installationsarbeiten konnte rechtzeitig zur Internationalen Super- computing Konferenz in Hamburg im Juni 2012 ein LINPACK-Leistungswert von beeindruckenden 2.9 PFlop/s demonstriert werden, womit die Einstufung als viertschnellstes System der Welt und schnellstes System Europas verbunden war. Auch in der Top500-Liste vom November 2012 lag SuperMUC noch auf Platz 6. Während der bisherige Rechner vor allem für Projekte aus Wissenschaft und Forschung innerhalb Deutschlands genutzt wurde, stellt der neue Rechner auch einen Teil des deutschen Beitrags zur europäi- schen Höchstleistungsrechner-Infrastruktur innerhalb von PRACE (Partnership for Advanced Computing in Europe) dar. Der deutsche Beitrag zur PRACE-Infrastruktur wird zusammen mit den beiden anderen Partnern Jülich und Hochleistungsrechenzentrum Stuttgart (HLRS) vom Gauss-Zentrum für Supercompu- ting (GCS e.V.) erbracht.

Jahresbericht 2012 des Leibniz-Rechenzentrums 7

Abbildung 2 SuperMUC im Rechnerraum: dieses Bild ist keine Photographie sondern wurde künstlich auf dem Rechner aus den vorhandenen Geometriedaten berechnet

Architektur des Systems Bei der Beschaffung des Rechners SuperMUC standen drei Aspekte im Vordergrund: eine breite und einfache Nutzbarkeit des Systems für verschiedene Wissenschaftsdisziplinen, hohe Zuverlässigkeit sowie eine möglichst hohe Energieeffizienz. Diese Ziele des LRZ wurden ab Mai 2009 mit Herstellern im Rah- men einer Markterkundung diskutiert. Nach dem europaweiten Teilnahmewettbewerb wurde ab März 2010 in einem Wettbewerblichen Dialog mit vier Firmen intensiv verhandelt und eine umfangreiche Leis- tungsbeschreibung erstellt, die auch Benchmark-Programme beinhaltete. Die Entscheidung fiel dann im November 2010 zugunsten von IBM mit dem System X iDataPlex, das auf 64 Bit Intel Standard- Prozessoren der neuesten Generation basiert. Die wichtigsten Charakteristiken des neuen Rechners werden im Folgenden dargestellt:

Thin Node Insel Fat Node Insel (zugleich Migrations- system) Anzahl Inseln 18 1 Anzahl Cores 147456 8.200 Anzahl Knoten 9216 205 Prozessor Intel Sandy Bridge-EP Intel Westmere-EX Peak-Rechenleistung (PFlop/s) 3.18 0.078 Gesamter Hauptspeicher (TByte) 288 51 Gemeinsamer Hauptspeicher pro Knoten (GByte) 32 256 Bandbreite zum Hauptspeicher pro Core (GByte/s) 6.4 4.3 Verbindung innerhalb einer Insel FDR10 QDR Verbindungstopologie innerhalb einer Insel Non-blocking Non-blocking Fat Tree Fat Tree Verbindung zwischen den Inseln FDR10 Verbindungstopologie zwischen Inseln Ausgedünnter (4:1) Fat Tree Bisektionsbandbreite des Verbindungsnetzwerkes 35.6 TByte/s Größe und Bandbreite des parallelen Dateisystems 10 PByte mit 200 Gbyte/s GPFS Größe und Bandbreite des Home Dateisystems 1.5 PByte mit 10 GByte/s Stromverbrauch des Systems (MW) <3 Tabelle 1: SuperMUC-Kennzahlen

8 Hochleistungsrechnen und Grid

Das Gesamtsystem ist in 19 Compute-Inseln mit jeweils etwa 8.200 Rechenkernen unterteilt. Eine dieser Inseln ist mit Knoten mit besonders viel Hauptspeicher ausgestattet (Fat-Node Insel mit 205 Rechenkno- ten). Die hierbei verwendete Prozessortechnologie ist Intel Westmere-EX. Dabei besteht ein Rechenkno- ten aus 40 Cores, die auf einen gemeinsamen Hauptspeicher von 256 Gigabyte zugreifen. Diese Insel wurde schon im Jahr 2011 für den Einsatz als Migrationssystem (SuperMIG) vorab geliefert; sie soll nach der Integration ins Gesamtsystem durch Programme benutzt werden, die extrem viel gemeinsamen Hauptspeicher benötigen, etwa für Pre- oder Postprocessing. Der Hauptteil des Systems besteht aus Re- chenknoten mit deutlich weniger Cores und Hauptspeicher pro Knoten (Thin-Node Inseln mit 16 Cores und 32 Gigabyte pro Knoten), da bei hochskalierbaren Programmen die Daten über die Knoten verteilt abgelegt werden. Jede dieser Inseln besteht aus 512 Knoten (zuzüglich Ausfallreserve und Servicekno- ten). Ein Knoten besteht aus jeweils zwei 8-Core Sandy Bridge-EP Sockeln, deren Eigenschaften besonders für das Hochleistungsrechnen geeignet sind.

Abbildung 3 Schematischer Aufbau des SuperMUC

Energieeffizienz Der Energieverbrauch des neuen Rechners von etwa 3 Megawatt unter Volllast, zu dem noch der Auf- wand für die Kühlung hinzukommt, hat das LRZ vor hohe finanzielle und technische Probleme gestellt und entscheidend die Verhandlungen mit den Herstellern geprägt. So wurde beschlossen, bei der Kühlung des Rechners einen völlig neuen Weg zu beschreiten. Die meisten der Knoten des SuperMUC nutzen eine Wasserkühlung, die aufgrund hoher Vorlauftemperaturen gleich mehrere Vorteile verbindet: Etwa 10 Prozent Energie werden durch die reine Wasserkühlung gespart, da auf den Knoten weniger bis gar keine aktiven Lüftungskomponenten mehr benötigt und Leckströme verringert werden. Außerdem werden keine energieintensiven Kältemaschinen für das Rechenzentrum benötigt, was den Energieverbrauch des Ge- samtsystems erheblich reduziert. Die Warmwasserkühlung bringt zudem wertvolle Wärmeenergie zurück, die sich vielfältig verwenden lässt, etwa zur Gebäudeheizung. Im Vergleich zu konventionellen, kaltluft- gekühlten Systemen reduzieren sich die CO2-Bilanz und auch der Lärmpegel im Rechnerraum signifikant. Die Warmwasserkühlung, die die Chips des Systems direkt kühlt, wurde eigens durch IBM entwor- fen und implementiert. Der SuperMUC kombiniert diese Warmwasserkühlung mit den energieeffizienten Intel Xeon Prozessoren und einer anwendungsorientiert arbeitenden Systemsoftware, die gemeinsam von IBM und LRZ weiterentwickelt wird, um den Energieverbrauch weiter zu senken. So wird aufgrund von Messungen des Energieverbrauchs und der Programmcharakteristiken die Taktung der Prozessoren opti-

Jahresbericht 2012 des Leibniz-Rechenzentrums 9 mal eingestellt, ohne die Rechenleistung zu sehr zu beeinträchtigen. Außerdem werden Prozessoren, die für einen gewissen Zeitraum nicht benötigt werden, herunter getaktet, bzw. vollständige Knoten in einen energiesparenden Schlafzustand versetzt. Durch all diese Maßnahmen soll der Gesamt-Energieverbrauch um 30 bis 40 Prozent gesenkt und ein wesentlicher Beitrag zum Klimaschutz geleistet werden.

Abbildung 4 Rechenknoten mit Warmwasserkühlung.

2.2.2 Installation und Inbetriebnahme des SuperMUC Die physische Installation des Phase-1 Systems (Rechenknoten, Massenspeicher und Verbindungsnetz- werk) erstreckte sich über die Monate Februar bis April; nach Anlieferung der ersten Compute-Inseln wurden die ersten LINPACK-basierten Burn-in Tests ab Anfang März vorgenommen. Der für die TOP- 500 Liste relevante LINPACK-Lauf wurde dann im Laufe des Monats Mai vorbereitet und durchgeführt. Das Resultat von 2.897 PFlop/s platzierte den Rechner als weltweit schnellstes Intel-basiertes System auf Rang 4 dieser Liste und damit auch als schnellsten Rechner in Europa. Ende Juni begann dann – nach einigen weiteren notwendigen Arbeiten, die IBM an der Skalierung der eingesetzten Systemsoftware vornehmen musste – die Abnahme des Systems, die sich aus der Leistungs- prüfung (also der Verifikation der von IBM zugesicherten Rechenleistung für einen definierten Satz von Benchmark-Programmen), der Funktionsprüfung (also der Verifikation von zugesicherter Funktionalität), sowie der Zuverlässigkeitsprüfung (also der Betriebsstabilität im normalen Benutzerbetrieb) zusammen- setzte. Leistungs- und Funktionsprüfung waren größtenteils bis Mitte August abgeschlossen; danach folgte die Zuverlässigkeitsprüfung im Benutzerbetrieb. Im Anschluss daran wurden noch einige Benchmarks wiederholt, und noch ausstehende Funktionen nachträglich geprüft. Die Abnahme des Rechensystems wurde am 11. September erklärt. Die während der Zuverlässigkeitsprü- fung gemessene Systemverfügbarkeit betrug 99,23%. Im Rahmen der Zuverlässigkeitsprüfung wurde noch eine Reihe von nicht betriebsgefährdenden Soft- ware-Mängeln festgestellt, die sich erst durch programm-spezifische Nutzungsmuster manifestierten. Diese Mängel wurden entweder durch die üblichen IBM-seitigen Bereinigungsprozesse zumeist bis Ende des Jahres behoben oder den Benutzern wurden Workarounds zur Verfügung gestellt. Ein im Berichtsjahr offener Abnahmepunkt ergab sich im Bereich der Datenhaltung: Für die dem parallelen Dateisystem zugeordnete Storage-Infrastruktur war bereits vorab wegen Liefer-Verzögerungen der Storage Controller eine Nachlieferung und verzögerte Abnahme vereinbart worden. Die Abnahme des Hintergrundspeichers konnte aufgrund von Schwierigkeiten bei der Demonstration der vertraglich verein- barten I/O-Leistung erst im Folgejahr erfolgen.

2.2.3 Betrieb des Höchstleistungsrechners SuperMUC In der ersten Jahreshälfte stand für SuperMUC-Benutzer nur das Migrationssystem „SuperMIG“ zur Ver- fügung. Ausgewählte Nutzer konnten ab August Ihre Berechnungen auf dem neuen System durchführen. Der allgemeine Nutzerbetrieb wurde Mitte September aufgenommen. Ab November hatte sich der Benut-

10 Hochleistungsrechnen und Grid zerbetrieb dann soweit normalisiert, dass eine Abrechnung der des Rechenzeitverbrauchs auf die Kontin- gente der Benutzer vorgenommen wurde. Ab September wurden auf dem Rechner dann auch die ersten Projekte von PRACE zugelassen. Dabei wurde für die Dauer eines Jahres Rechenzeit im Umfang von 200 Millionen Core-Stunden für diese Pro- jekte bereitgestellt, die als deutscher Betrag für das europäische Projekt vorgesehen sind. Eine Reihe von Stabilitätsproblemen, die sich teilweise bereits während der Zuverlässigkeitsprüfung angedeutet hatten (allerdings dort noch in viel zu geringem Umfang, um deren Bestehen zu gefährden), verschärften sich im regulären Benutzerbetrieb im Laufe des Spätherbstes zunehmend. Das Problem äu- ßerte sich in erster Linie durch Abstürze und Fehlstarts insbesondere größerer Jobs; hierbei traten eine Reihe von Signaturen auf (in erster Linie Fehler bei I/O Zugriffen sowie Wegbrechen einzelner Rechen- knoten), die sich jedoch erst im Lauf der Zeit auf die wesentlichen Ursachen reduzieren ließen:  eine im Laufe der Zeit stark zunehmende Anzahl von Defekten bzw. Performance-Verlusten an Infiniband-Kabeln, bedingt durch überschnelle Alterung der integrierten Transceiver,  Defekte in der auf dem Verbindungsnetzwerk eingesetzten Managementsoftware, die zum Ab- sturz von ganzen Netz-Segmenten führen konnte,  Auftreten von gehäuften Latenzen auf der gelieferten Charge von Festplatten, die zu einer deutlichen Verringerung der verfügbaren I/O Bandbreite sowie gelegentlich auch zu Hängern des parallelen Dateisystems führten. Die Behebung oder wenigstens Beherrschung dieser Stabilitätsprobleme reichte noch bis in den Januar des Folgejahres; ein wesentlicher Punkt hierbei war die Implementierung eines datenbankgestützten Feh- leraufzeichnungsverfahrens, damit eine schnellere Korrelation von Job zu möglichen Hardware- Problemen möglich ist, sowie auch als defekt erkannte Knoten möglichst schnell offline zu nehmen zu können. Sowohl der Betrieb des Migrationssystems als auch die Inbetriebnahme des SuperMUC haben zu einer deutlichen Zunahme von Benutzeranfragen geführt. Die Stabilisierung des Benutzerbetriebes und die Beantwortung von Benutzeranfragen bereite den Gruppen APP und HPC bis zum Jahresende (und dar- über hinaus) viel Arbeit und führte in einigen Fällen zu einer zeitweiligen Überlastung der mit der Bear- beitung befassten Mitarbeiter. Zusammenfassend sind folgende Arbeitsschwerpunkte zu nennen:  Ein- und Ausgabe von Daten über Infiniband auf das parallele Dateisystem (GPFS)  Die Behebung von Software-Fehlern in den parallelen Schnittstellen  Die Anbindung und Erweiterung der Archivierungs- und Grid-Infrastrukturen  Implementierung von skalierbaren Mechanismen zum Budgeting, Accounting und System- Monitoring  Implementierung von datenbankgestützten Mechanismen zur Fehlererkennung  Die Einbindung des von IBM gestellten Support-Personals in die LRZ-Prozesse Die Implementierung von Maßnahmen zur Einsparung von elektrischer Energie

2.2.4 Benutzerverwaltung für die Hochleistungssysteme Neben den klassischen Arbeiten der Benutzerverwaltung wie Organisation der Begutachtung der Rechen- zeitanträge, Verwaltung der Benutzerkennungen und Rechenzeitabrechnung kamen im Berichtsjahr noch umfangreiche neue Aufgaben für die Rechenzeitvergaben bei den HPC-Calls von PRACE und GAUSS hinzu, nämlich Organisation und Vorbereitung dieser Calls, die Abstimmung mit den Partnern sowie die technische Begutachtung der Projektanträge. Ein weiterer Punkt war die Klärung der Fragen in Zusam- menhang mit Embargobestimmungen und der Zulassung von Nutzern aus Nicht-EU-Ländern auf den Hochleistungsrechnern.

2.2.5 Nutzungsstatistik Die folgende Tabelle gibt eine Übersicht über die Anzahl der durchgeführten Projekte in den vergangenen Jahren auf den verschiedenen Höchstleistungsrechnern des LRZ wieder. Insgesamt haben auf den Rechner 702 Projekt Rechenzeit erhalten, davon sind 465 beendet und 237 noch aktiv.

Jahresbericht 2012 des Leibniz-Rechenzentrums 11

Jahr Rechner Projekte Projekte Projekte begonnen beendet aktiv 2000 HLRB I 65 0* 65 2001 HLRB I 21 0* 86 2002 HLRB I 29 0* 115 2003 HLRB I 14 0* 129 2004 HLRB I 17 0* 146 2005 HLRB I 16 0* 162 2006 HLRB I/HLRB II 64 2 224 2007 HLRB II 60 7 277 2008 HLRB II 114 47 344 2009 HLRB II 81 86 339 2010 HLRB II 61 77 323 2011 HLRB II/SuperMIG 61 h181 203 2012 SuperMIG/SuperMUC 92 62 237 Gesamt 702 465 237 Tabelle 2: Anzahl der begonnen, beendeten und aktiven Projekte

(* In diesem Jahr wurde noch kein explizites Projektende in der Datenbank gespeichert). Die Gesamtzeit der abgegebenen Rechenzeit im Jahr 2012 an den Systemen SuperMIG und SuperMUC ist in der folgenden Tabelle angegeben.

SuperMIC SuperMUC Gesamt Core-Std.- Jobs Core-Std.- Jobs Core-Std.- Jobs 59,7 Mio. 142.800 74,6 Mio. 34.746 134,3 Mio. 177.546 Tabelle 3: Abgegebene Rechenzeit und Anzahl Jobs an den Höchstleistungssystemen im Jahr 2012

45,0 40,0 35,0 30,0 25,0

SuperMUC Stunden - 20,0 SuperMIG

15,0 Core 10,0 5,0 0,0 1 2 3 4 5 6 7 8 9 10 11 12

Abbildung 5 Abgegebene Rechenzeit pro Monat für 2012 an SuperMIG und SuperMUC

12 Hochleistungsrechnen und Grid

Abbildung 5 gibt die abgegebene Rechenzeit für jeden Monat in Core-Stunden von SuperMIG und von SuperMUC nach Beendigung der „Friendly User Period“ und Aufnahme des allgemeinen Benutzerbe- triebs im November 2012 wieder. Die Rechenzeitabgabe am SuperMIG mit etwa 5 Mio. Core-Stunden pro Monat entspricht etwa der Leistung des vorherigen Höchstleistungsrechners HLRB II. November 2012 wurde auch das Accounting von Rechenzeit am SuperMUC aktiviert, wobei die Grafik einen ersten Eindruck über die Zunahme an Rechenleistung am LRZ durch die Verfügbarkeit von SuperMUC vermittelt. Die Aufteilung der abgegebenen Rechenzeit nach institutioneller Zugehörigkeit ist in der folgenden Ta- belle aufgeführt

Institutionskategorie SuperMIG SuperMUC Gesamt Universitäten 75.2% 27.4% 48.6% Helmholtz-Gemeinschaft 9.8% 17.0% 13.8% Leibniz-Gemeinschaft 2.4% 16.0% 9.9% Leibniz-Rechenzentrum 0.7% 16.3% 9.3% Max-Planck-Gesellschaft 9.2% 5.6% 7.2% Sonstige 0.9% 9.5% 5.7% PRACE 0.0% 8.2% 4.5% Deisa 1.7% 0.2% 0.9% Tabelle 4: Verteilung der abgegebenen Rechenzeit nach Institutionen

Hier wird deutlich, dass der SuperMUC im Jahr 2012 viel stärker für Projekte der Großforschungseinrich- tungen und für PRACE benutzt wird als der SuperMIG. Der aktuell hohe Anteil an Rechenzeit für das LRZ am SuperMUC ist durch Tests und Abnahmebenchmarks bestimmt und wird in den nächsten Mona- ten deutlich zurückgehen. Die jeweils fünf größten wissenschaftlichen Projekte auf SuperMUC und Su- perMIG sind in der folgenden Tabelle aufgeführt. Auch hier wird das unterschiedliche Nutzungsspektrum deutlich, nämlich dass die Nutzung des SuperMUC von einigen Großprojekten dominiert wird.

Projekt Title Principal Investigator Usage Average Core SuperMUC pr63po Chiral Symmetry and topological properties in Lattice Urbach/Rheinische Friedrichs- 15% 1072 QCD with Wilson twisted mass quarks Wilhelms Universitaet h009z Local Supercluster Simulation Gottlöber/Leibniz-Institut für 13% 5645 Astrophysik Potsdam (AIP) pr86go Full-f gyrokinetic simulation of edge pedestal in Textor Kiviniemi/DEISA PRACE 5% 3647 pr86ba Electrophysiology - Atomistic modeling Tarek/DEISA PRACE 4% 1814 pr58fa Structure Formation in Models Beyond LambdaCDM Smith/Bonn 4% 1638 SuperMIG pr63ce Ab initio Metadynamics Simulations of Methanol Syn- Frenzel/RUB Chemie 5.61% 417 thesis over Cu/ZnO catalyst surfaces h0983 Large Scale CFD for Complex Flows Stemmer/TU München 5.15% 137 h006z Simulation of N_f equal 2+1 lattice QCD at realistic Schierholz/DESY Zeuthen 4.67% 898 quark masses h1142 Simulation of the unsteady flow around the Strato- Engfer/Uni Stuttgart 4.55% 147 spheric Observatory For Infrared Astronomy SOFIA pr47bu Numerical Investigation of the Vortical Flowfield about Hickel/TU München 3.38% 413 the VFE-2 Delta-Wing Tabelle 5: Die jeweils fünf größten wissenschaftlichen Projekte auf SuperMUC und SuperMIG

Jahresbericht 2012 des Leibniz-Rechenzentrums 13

Auch in der Übersicht der Nutzung durch die einzelnen Fachgebiete wird das unterschiedliche Nutzungs- spektrum der beiden Systemteile deutlich. Wie auch auf den bisherigen Höchstleistungsrechnern des LRZ, dominieren auf dem SuperMIG die Anwendungen aus dem Bereich der Fluiddynamik, gefolgt von der Astrophysik, die in den letzten Jahren beständig an Rechenzeit zugenommen hat. Die Anwendungen in der Fluiddynamik stammen zum Großteil aus Universitätsinstituten. Auf dem SuperMUC stellt sich aber eine ganz andere Verteilung dar. Hier haben zum ersten Mal die Astrowissenschaften die meiste Rechenzeit verbraucht, da es mittlerweile in diesem Wissenschaftsbereich eine ganze Reihe hochskalier- barer Applikationen gibt.

Abbildung 6 Anteilige Nutzung von SuperMUC und SuperMIG

2.3 Linux-Cluster

2.3.1 Übersicht über die Cluster-Systeme Das Linux-Cluster am LRZ ist über die Zeit immer weiter erweitert worden und wird als heterogenes Cluster mit verschiedenen Segmenten betrieben. Cluster-Segment Anzahl Gesamtleistung elektr. Leistung Beschaffungs- Cores (TFlop/s) (kW) jahr Serielles Cluster (inklusive housing) 3.680 30.0 210 2007/2008/2010 Myrinet 10 GE Systeme 688 5.7 33 2007 SGI(jetzt Altix serial) ICE 512 5.2 25 2010 MPP Infiniband Cluster 2.848 22.8 45 2011 SGI Altix UltraViolet 2.040 20.0 60 2011 Munich Adv. Comp. Infiniband Cluster 1.904 50.0 30 2012 Gesamt: 11.672 133.7 403 -- Tabelle 6: Übersicht über die wichtigsten Segmente des Linux-Cluster

Aus dieser Übersicht wird ersichtlich, dass für die bis 2007 beschafften Systeme dringend Ersatz beschafft werden muss. Eine entsprechende Antragstellung ist für 2013 geplant.

2.3.2 Erweiterung des wassergekühlten Clusters von MEGWare / MAC-Cluster Das bereits 2011 gelieferte wassergekühlte Cluster wurde um zwei Racks erweitert, von denen eines in die bestehende Kühl-Infrastruktur eingebunden wurde, und das andere mit einer über eine Absorptions-

14 Hochleistungsrechnen und Grid kühlmaschine versorgte Luftkühlung versehen ist. Dieses für die Informatik der TU gehouste System (MAC = Munich Centre of Advanced Computing) ist für Forschungszwecke ausgelegt und daher sehr heterogen aus unterschiedlichen Prozessor- und Beschleuniger-Architekturen zusammengesetzt.

2.3.3 Betrieb der Cluster-Systeme Im Laufe des Jahres konnte die schon länger geplante Migration der Cluster-Systeme von dem nicht mehr längerfristig unterstützten SLES10 auf das neue Betriebssystem-Release, SLES11 durchgeführt werden. Auf den parallelen Cluster-Segmenten kam hier zunächst SLES11 SP1 zum Einsatz, auf den seriellen - nach dessen Verfügbarkeit – SLES11 SP2. Fast alle Cluster-Segmente wurden in die bestehende SLURM-Infrastruktur integriert. Auch das Job Accounting unter SLURM konnte in Betrieb genommen werden. Als letzte verbleibende SGE-Insel wird das für LCG gehostete Cluster noch eine Zeitlang mit Sun Grid Engine (SGE) betrieben. Insgesamt kann der Betrieb des Linux-Clusters als stabil bezeichnet werden. Es zeigt sich allerdings, dass auf Grund der sehr angespannten Personalsituation und der wachsenden Komplexität der Infrastruktur und des Betriebsmodells die Beseitigung von Störungen zunehmend längere Zeit in Anspruch nahm. Auch geplante Wartungsmaßnahmen am wassergekühlten Cluster mussten meist über den ursprünglich vorgesehenen Zeitrahmen hinaus ausgedehnt werden.

2.3.4 Tests und Prototypen Das LRZ wurde bereits 2010 als eines von weltweit 4 Zentren ausgewählt, um die neue Intel MIC („Many Integrated Core“) Architektur zu evaluieren. Seitdem wurden dem LRZ verschiedene Prototypen dieser Architektur, wie „Knights Ferry“ und „Knights Corner“ (kürzlich umbenannt in „Intel Xeon Phi“), von Intel zur Verfügung gestellt. Seitens des LRZ lag das Schwergewicht bei der Untersuchung mehrerer Programmiermodelle hinsichtlich ihrer Eignung für die MIC Architektur. Hierbei wurden innerhalb des KONWIHR-Projektes verschiedene Benchmarks und Applikationen auf MIC portiert. Während eines von IBM und Intel veranstalteten Workshops in Montpellier wurde im September 2012 über die am LRZ ge- wonnenen Erfahrungen referiert. Diese fließen derzeit in den im Rahmen von PRACE erstellten Best Practice Guide für die Intel MIC Architektur ein. Eine erste Fassung ist unter http://weinberg.userweb.mwn.de/Best-Practice-Guide-Intel-MIC/Best- Practice-Guide-Intel-MIC.pdf verfügbar.

2.3.5 GPGPU-System Als PRACE-Prototyp für ein wassergekühltes GPU-beschleunigtes Cluster war vorgesehen, ein bereits früher von der russischen Firma T-Platforms geliefertes System von Luftkühlung auf Wasserkühlung umzustellen; auf Grund von konzeptionellen Problemen konnte diese Umstellung jedoch im Berichtszeit- raum nicht fertiggestellt werden. Das System besteht aus vier Intel-Westmere basierten Rechenknoten mit jeweils zwei NVidia Fermi Beschleunigerkarten.

2.3.6 Nutzungsstatistiken Die Nutzung der unterschiedlichen Segmente des Linux-Cluster ist in Abbildung 7 dargestellt. Aufgrund der sehr angespannten Personalsituation konnte die Abrechnung der abgegebenen Rechenzeit erst ab Juni 2012 und für den seriellen Teil sogar erst ab November 2012 realisiert werden. Die Nachfrage nach Rechenzeit am Linux-Cluster übersteigt weiterhin die zur Verfügung stehenden Re- sourcen. Entsprechend lang sind die Wartezeiten bis ein Job zur Ausführung kommen kann (siehe Abbil- dung 8). Auch hier wird deutlich, dass dringend eine Erweiterung für den seriellen Teil des Clusters beschafft werden muss. Die SGI Altix UltaViolet Systeme sind wegen ihres großen Hauptspeichers eine begehrte Ressource mit ebenfalls mit sehr langen Wartezeiten. Auch wenn nicht für das vollständige Jahr 2012 Daten vorliegen, so lässt sich doch aus dem Vergleich mit den vergangenen Jahren feststellen, dass die anteilige Nutzung des Linux-Clusters durch Hochschulen außerhalb Münchens in den vergangenen Jahren weiter zurückgegangen ist. Die Nutzung wird nun durch die beiden großen Münchner Universitäten dominiert. Dies ist vor allem auf den Ausbau der Linux- Kapazitäten in Erlangen zurückzuführen.

Jahresbericht 2012 des Leibniz-Rechenzentrums 15

Abbildung 7 Nutzung des Linux-Cluster (ab Juni bzw. November 2012 für seriellen Teil)

Abbildung 8 Durchschnittliche Wartezeit bis zur Jobausführung auf den verschiedenen Segmenten des Clusters

16 Hochleistungsrechnen und Grid

Institution/Fachgebiet Core-h Jobs Bayerische Akademie der Wissenschaften 20.677 1.862 Bayerische Hochschulen und Fachhochschulen soweit nicht gesondert erfasst 482.644 6.927 Hochschule München 12.583 497 Ludwig-Maximilians-Universität München 4.238.034 170.912 Biologie 6.806 477 Chemie / Pharmazie 600.157 350 Geowissenschaften 2.189.038 2.481 Mathematik / Informatik 120.799 9.886 Medizin 140.154 2.887 Physik 1.181.082 154.831 Nutzer am Höchstleistungsrechner Bayern 5.456 3.284 Öffentlich-Rechtliche und Gemeinnützige Körperschaften 7.068 7 Technische Universität München 3.597.242 36.057 Bauingenieur- und Vermessungswesen 54.787 10.839 Chemie / Pharmazie 833.425 11.438 Elektrotechnik und Informationstechnik 73.598 1.849 Maschinenwesen 1.996.396 4.200 Mathematik / Informatik 276.255 3.525 Physik 128.286 3.822 Sonstige 1.183 179 Wissenschaftszentrum Weihenstephan 231.842 145 Zentralinstitute / Verwaltung 1.469 60 Gesamtergebnis 8.363.705 219.546 Tabelle 7: Nutzung des Linux-Clusters im November und Dezember 2012 nach Institution und Fachgebiet

2.4 Technisch-wissenschaftliche Software Die Überarbeitung des Software-Portfolios, die durch den Umstieg auf neue Betriebssoftware und Scheduling-Systeme erforderlich geworden war, konnte im Verlauf des Jahres im Wesentlichen abgeschlossen werden. Im Software-Portfolio erfolgten Aktualisierungen und Erweiterungen. Aus dem Be- reich der Quantenchemie sind neue Releases von NWChem, Quantum-Espresso, CPMD, CP2K, GROMACS, NAMD und Molpro sowie zusätzliche Pakete wie Abinit, Desmond oder Schrödinger zu nennen.

2.5 Remote Visualisierung Für die Benutzer des Linux-Clusters standen während des gesamten Jahres drei dedizierte Remote- Visualisierungs-Server zur Verfügung (GVS2, GVS3 und GVS4). Aus Effizienzgründen wurde die Sys- temadministration der Remote-Visualisierungs-Server an die Firma MEGWare vergeben, die ein Upgrade auf SLES 11 SP1, die automatisierte Installation per xCAT, sowie die Integration der Maschinen in das neue Batch-Queueing System SLURM durchführte. Die Systeme sind durch die Benutzer des Linux- Clusters nach wie vor gut ausgelastet. Von einigen Benutzern von SuperMIG und SuperMUC wurde eine Möglichkeit zur Remote- Visualisierung nachgefragt. Aufgrund fehlender Investitionsmittel und Personalknappheit kann ein solcher Service für SuperMIG und SuperMUC aber leider derzeit nicht angeboten werden.

2.6 Projekte im Hochleistungsrechnen

2.6.1 Gauss Centre for Supercomputing (GCS) Ziele Mit der Gründung des Gauss Centre for Supercomputing (http://www.gauss-centre.eu) im Jahr 2007 durch die Kooperation der drei Bundeshöchstleistungsrechenzentren in Jülich, Garching und Stuttgart wurde der Grundstein für die optimale Unterstützung der Wissenschaft, Wirtschaft und Politik durch computergestützte Simulation der obersten Leistungsklasse (Tier-0) gelegt. Durch das Projekt PetaGCS

Jahresbericht 2012 des Leibniz-Rechenzentrums 17 konnte das Gauss Centre for Supercomputing (GCS) die leistungsfähigste nationale Infrastruktur für Su- percomputing in Europa aufbauen. Darüber hinaus hat GCS den organisatorischen Rahmen dafür geschaffen, dass Wissenschaftler und Forscher nicht mehr aufgrund regionaler oder institutioneller Strukturen, sondern aufgrund fachlicher Kriterien das für ihre Bedürfnisse am besten geeignete Supercomputer- Zentrum für ihre Anwendung wählen können. Es wurde ein gemeinsames Zugangsverfahren entwickelt und implementiert, das nach abgestimmten Regeln und ausschließlich wissenschaftlichen Kriterien in einem peer-review Verfahren den einheitlichen und fairen Zugang sicherstellt. Die hohe Attraktivität und der hohe Bedarf zeigen sich in der konstant 3-4 fachen Überzeichnung der ausgeschriebenen Rechenzeit (Verhältnis von beantragter zu verfügbarer Rechenzeit). In Summe werden jährlich etwa 200 herausragende Projekte mit Rechenzeitvolumen auf GCS-Systemen gefördert. Die bereits jetzt erzielten wissenschaftlichen Ergebnisse zeigen deutlich die Wichtigkeit der Verfügbarkeit dieser Forschungseinrichtung für Deutschland. Weiterentwicklung Die gemeinsamen Arbeiten im Jahr 2012 bestanden vor allem in der Erstellung des Strategiepapiers „Weiterentwicklung des Gauss Centre for Supercomputing 2016 – 2020“. Aus der Ausrichtung des GCS als eine Einrichtung für High Performance Computing sowie wichtigen wissenschaftlichen und gesellschaftlichen Herausforderungen wurden folgende wesentliche Zieldimensi- onen für die zukünftige Entwicklung des GCS abgeleitet:  Wissenschaftliche Exzellenz,  HPC-Technologie,  Anwendungsunterstützung, Brückenfunktion und Vernetzung,  Aus- und Weiterbildung,  Wettbewerb in Wirtschaft und Industrie,  Gesellschaft / Politikberatung

Thematisch werden sich die Partner im Gauss Centre for Supercomputing zukünftig durch eigene For- schung auf folgende Gebiete konzentrieren und dabei neue Akzente im Hochleistungsrechnen setzen.  Energie  Mobilität  Gesundheit  Umwelt Gemeinsames Rechenzeitvergabeverfahren Der Zugang zu den Systemen wurde vor der Gründung von GCS in unabhängigen Verfahren durch die jeweiligen Vergabegremien der einzelnen Zentren geregelt. Dies war nicht mehr ausreichend, weil nicht garantiert werden konnte, dass Wissenschaftlern ein vergleichbarer Zugang zu allen GCS-Systemen mög- lich ist. Im Rahmen des Projektes wurde deshalb ein gemeinsames Zugangsverfahren entwickelt und implementiert, das nach einheitlichen Regeln und ausschließlich wissenschaftlichen Kriterien in einem peer- review Verfahren den einheitlichen und fairen Zugang sicherstellt. Es wurden dabei verschiedene Klassen von Projektgrößen definiert, damit wissenschaftlich exzellente Projekte, die viel Rechenzeit benötigen, besonders gefördert werden können. So wird zweimal jährlich ein nationaler Call für sogenannte „Large Scale-Projekte“ veröffentlicht, die mindestens 2% der Leistung des Supercomputers über eine Laufzeit von 12 Monaten benötigen. GCS Lenkungsausschuss Der gesamte Prozess der Rechenzeitvergabe wird durch den neu gegründeten gemeinsamen GCS- Lenkungsausschuss gesteuert und überwacht. Mitglieder des gemeinsamen GCS-Lenkungsausschusses sind Vertreter der wissenschaftlichen Vergabegremien der GCS-Zentren. So wird die Kohärenz mit den lokalen Vergabeverfahren sichergestellt. Gemeinsames Ausbildungs- und Schulungsprogramm Innerhalb von Gauss wird ein umfangreiches Ausbildungs- und Trainingsprogramm koordiniert (http://www.gauss-centre.eu/events/). Viele der Kurse und damit auch diejenigen vom LRZ werden auch auf europäischer Ebene innerhalb der PRACE Advanced Training Centers (PATC, http://www.training.prace-ri.eu) angeboten.

18 Hochleistungsrechnen und Grid

2.6.2 KONWIHR Im Rahmen des Kompetenznetzwerkes für Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR) wird am LRZ und RRZE Erlangen das Projekt „OMI4papps: Optimierung, Modellierung und Implemen- tierung hoch skalierbarer Anwendungen“ seit September 2008 durch das Bayerische Staatsministerium für Wissenschaft, Forschung und Kunst gefördert. Die Evaluierung neuer Programmiersprachen und –paradigmen insbesondere für Akzeleratoren steht seit Beginn dieses KONWIHR-Projektes neben der synthetischen Applikationsmodellierung im Zentrum der Arbeiten am LRZ. Wurden in der Anfangsphase des Projektes 2008 noch Cell-basierte Systeme untersucht, so konzentrierten sich die weiteren Arbeiten auf GPGPU-basierte Systeme und zunehmend auf Intels neue MIC-Architektur. Im Bereich der GPU-Programmierung wurde insbesondere die Programmie- rung mit NVIDIA CUDA, Pragma-basierten Programmiermethoden wie HMPP (Hybrid Multicore Paral- lel Programming Workbench der französischen Firma CAPS), PGI Accelerator Compiler, sowie mit Bib- liotheken wie CUBLAS, CUFFT, cuSPARSE und der Sprache OpenCL näher untersucht. Die Intel MIC-Architektur ist als Kandidat für einen Teil der zweiten Ausbaustufe des SuperMUC (2014- 2016) am LRZ von besonderem Interesse. Im Rahmen der Portierung mathematischer Kernel und ausge- wählter Benchmarks der SuperMUC Benchmark-Suite auf Intel Xeon Phi Coprozessoren wurden diverse Programmiermodelle für die MIC-Architektur evaluiert. Verglichen wurden native Implementierungen mit OpenMP, MKL und Intrinsics, die direkt auf dem Co- prozessor gestartet werden mit Implementierungen mit Offload Pragmas, die auf dem Host gestartet werden und rechenintensive Teile des Programms auf den Coprozessor auslagern. Auch die verschiedenen Modi der MKL Bibliothek (native mode, compiler assisted offload und automatic offload) wurden detail- liert getestet. Mit der Portierung von Applikationen wie SEISSOL oder BQCD konnten erste Erfahrungen mit der MPI-Programmierung und den unterschiedlichen Ausführungsmodi (MPI Prozesse nur auf dem Coprozessor, auf Coprozessor und Host etc.) gewonnen werden. Das dabei gewonnene Knowhow fließt derzeit in den im Rahmen von PRACE federführend vom LRZ erstellten Best Practice Guide für die Intel MIC Architektur ein. Durch die Ressourcen aus KONWIHR konnte auch das Kursangebot des LRZ und RRZE erneut erweitert werden. Folgendes KONWIHR Projekt wurde vom LRZ unterstützt:  GeoPF: Geophysik für PetaFlop Rechner: Projektleiter: Prof. Dr. Heiner Igel, Department für Geo- und Umweltwissenschaften, Ludwig-Maximilians-Universität München, Projektlaufzeit: September 2008 – voraussichtlich August 2013

Im Rahmen der KONWIHR Software Initiative wurden am LRZ folgende Projekte betreut:  Resamplingbasierte Modellierung und Evaluation bei Genexpressionsdaten, Institut für medizinische Informationsverarbeitung, Biometrie und Epidemiologie der Ludwig- Maximilians-Universität München und LRZ, Projektlaufzeit: November 2011 - November 2012  Tuning a cosmo Gadget for SuperMUC, Universitäts-Sternwarte München (USM) und LRZ, Projektlaufzeit: Dezember 2012 - Juni 2013

2.6.3 Partnership for Advanced Computing in Europe: PRACE PRACE ist ein europäisches Projekt mit 25 Partnerländern. Das Ziel von PRACE ist die Entwicklung einer europäischen Höchstleistungsrechner-Infrastruktur. Das LRZ war das ganze Berichtsjahr federfüh- rend in den beiden Projekten PRACE First Implementation Phase Projekt (PRACE-1IP) und Second Im- plementation Phase Projekt (PRACE-2IP) involviert. Seit seinem Start im September ist das LRZ auch an dem Third Implementation Phase Projekt (PRACE-3IP) beteiligt. In PRACE-1IP und PRACE-2IP leitet das LRZ das Arbeitspaket zum Thema Prototypen für neue Technologien, und in PRACE-2IP zusätzlich auch die Säule „Technology & Industry“. Im Softwarebereich koordinierte das LRZ im Rahmen von PRACE-1IP die Evaluierung neuer Program- miersprachen und beobachtete insbesondere die Entwicklung höherer Programmiersprachen für den Ein- satz von Beschleunigern wie GPGPUs oder Intel Xeon Phi Coprozessoren. Hierbei wurden die Ergebnis-

Jahresbericht 2012 des Leibniz-Rechenzentrums 19 se der Evaluierung der Programmiersprache Intel Array Building Blocks in einem PRACE Whitepaper publiziert. In PRACE-2IP ist das LRZ ferner federführend an der Erstellung eines Best Practice Guides für SuperMUC beteiligt. Im Rahmen von PRACE-3IP koordiniert das LRZ die Erstellung eines Best Practice Guides für die neue Intel MIC-Architektur und kooperiert hierbei mit Partnern in Bulgarien, Finnland und Schweden. Im Bereich HPC-Hardware war das LRZ über den gesamten Berichtszeitraum für die Koordination und Auswertung der PRACE-Prototyp Aktivitäten im Bereich „Energy-to-Solution“ federführend verantwortlich. Diese Untersuchungen dienen der Evaluierung des Energieverbrauchs von HPC-Systemen und - Infrastruktur, bzw. der Untersuchung von potentiellen Einsparungsmöglichkeiten durch neue Prozessor- technologien (GPUs, FPGAs & ARM) und innovativer Rechenzentrums-Infrastruktur. Das LRZ kooperiert hierfür mit Partnern in Barcelona (ARM/GPU), Poznan/Posen (GPU), Linz (FPGA) und Stockholm (ARM/DSP). Am LRZ wird die Möglichkeit untersucht, mit Hilfe von Warmwasserkühlung und „Trige- neration“ (Kraft-Wärme-Kälte-Kopplung), den für den Betrieb der Infrastruktur und der Rechner notwendigen Energiebedarf zu minimieren (z.B. durch das Ausnutzen „freier Kühlung“) und andererseits die Rechnerabwärme zur Gebäudeheizung und Kühlung wiederzuverwenden (z.B. mit Hilfe von Adsorbti- onskältemaschinen). Zur Messung des Energieverbrauchs wurde die „PRACE energy benchmark suite“ definiert, welche - im Vergleich zur Green500 - Aussagen für verschieden wissenschaftliche Anwendun- gen erlaubt. Die im Rahmen des 4. und 5. „PRACE Access Call“ akzeptierten Projekte wurden erfolgreich betreut. Das LRZ unterstützte dabei Projekte aus folgenden drei verschiedenen wissenschaftlichen Gebieten: • Chemistry and Materials • Astrophysics • Engineering and Energy Diese insgesamt 10 Projekte stammen aus 7 Ländern und nutzen die Infrastruktur des SuperMUC am LRZ im Rahmen von PRACE mit insgesamt 200 Millionen CPU-Stunden.

2.6.4 DEEP DEEP ist ein von der Europäischen Kommission gefördertes und vom Forschungszentrum Jülich geleite- tes Exascale-Projekt mit dem Ziel, eine neuartige 'Cluster Booster Architektur' zu entwickeln. Ein wichtiges Element dieser Architektur sind die kürzlich veröffentlichten XEON Phi Prozessoren von Intel, welche speziell für das Parallelrechnen ausgelegt sind und über 60 Rechenkerne auf einem Chip vereinen. Die Kommunikation zwischen diesen Prozessoren übernimmt ein neuartiges Verbindungsnetz, welches an der Universität Heidelberg entwickelt wurde. Seit dem Projektstart im Dezember 2011 leitet das Leibniz-Rechenzentrum die Öffentlichkeitsarbeit des Projektes und konnte durch seine Expertise im Bereich des energieeffizienten Höchstleistungsrechnens die Hardwareentwicklung maßgeblich beeinflussen. So wird das finale DEEP System, von dem übrigens auch ein kleinerer Teil im kommenden Jahr am Leibniz-Rechenzentrum in Betrieb geht, über umfassende Überwachungsmöglichkeiten zur Erfassung und Optimierung des Energieverbrauchs verfügen. Die Fort- schritte und Zwischenergebnisse der Projektarbeit, welche zu großem Teil auch unmittelbar zur Optimie- rung des Betriebs am Leibniz-Rechenzentrum beitragen konnten, wurden in mehreren Projektberichten dokumentiert.

2.6.5 Mont-Blanc Mont-Blanc ist ein von der Europäischen Kommission gefördertes Exascale-Projekt, dessen Ziel es ist, auf Basis der ARM-Prozessorarchitektur eine neue, besonders energieeffiziente Systemarchitektur für zukünftige Hochleistungsrechner zu entwickeln. Das Projekt startete im Oktober 2011 unter der Leitung des Barcelona Supercomputing Center. Im ersten Projektjahr konnte durch das Leibniz-Rechenzentrum bereits eine wissenschaftliche Anwen- dung aus dem Bereich der Quantenchromodynamik auf einem Vorläufer des finalen Mont-Blanc-Systems zur Ausführung gebracht werden. Zudem konnte, ähnlich wie im DEEP Projekt, in enger Absprache mit den an der Hardwareentwicklung beteiligten Firmen ein Konzept zum energieeffizienten Betrieb des Sys- tems entwickelt werden.

20 Hochleistungsrechnen und Grid

Mit der Durchführung der beiden Exascale Projekte DEEP und Mont-Blanc sind am Leibniz- Rechenzentrum derzeit mehr als 7 wissenschaftliche Mitarbeiter beauftragt.

2.6.6 AutoTune Das LRZ ist Projektpartner innerhalb des FP7-Projektes „Automatic Online Tuning“ (AutoTune). Das seit Oktober 2011 durch die EU für drei Jahre geförderte Projekt wird von der TUM koordiniert und hat die automatische Optimierung von Applikationen im HPC-Umfeld bezüglich Performancesteigerung und Energieeffizienz zum Ziel. IBM unterstützt das LRZ bei der Realisierung der Ziele auf dem neuen LRZ- Höchstleistungsrechner SuperMUC. In der ersten Phase des Projektes entwickelte das LRZ verschiedene Modelle für eine energieeffiziente Nutzung von SuperMUC. Die Modelle basieren auf der Regelung der CPU-Frequenz in Abhängigkeit verschiedener Frequenz-Parameter (CPU-Governor und Taktfrequenz- Bereich) sowie der Berücksichtigung des Laufzeitverhaltens verschiedener paralleler Applikationen. Für die praktische Umsetzung der Modelle wurde eine Energie-Optimierungs-Bibliothek entwickelt, die eine einfache Instrumentierung des Programmcodes hinsichtlich Messung der Energie und Performance sowie des Setzens der Frequenzparameter auf CPU-Ebene erlaubt. Sie bildet die Grundlage für die momentan anstehende Implementation von Energie-Plugins für Periscope, die Teil des Periscope-Tool-Framework (PTF) von AutoTune bilden.

2.6.7 ScalaLife Das EU-Projekt ScalaLife (Scalable Software Services for Life Science), bei dem das LRZ die Leitung eines Workpackages übernommen hat, soll die Grundlage für die e-Infrastruktur im Bereich Life Science in der EU bilden. Das LRZ hat in diesem Rahmen eine Benchmark- und Validierungssuite entwickelt, die es Hochleistungsrechenzentren erlaubt, automatisierte Performanceanalysen durchzuführen. Von Anwen- dern wurden Inputdaten für Tests und Benchmarks zur Verfügung gestellt. Das Projekt hat noch eine Laufzeit bis September 2013. Im Herbst 2012 wurde das Projekt von der EU positiv begutachtet.

2.6.8 Arbeiten für die Antragstellung REACT Im Rahmen des zehnten ICT-calls „FP7-ICT-2013.12.1“ hat das LRZ an einen Projektantrag „Resource- Aware Dynamic Application Tuning“ (REACT) mitgewirkt. Neben dem LRZ sind die Technische Uni- versität München, die Universität Wien, die Universitat Autònoma de Barcelona und die National Univer- sity of Irland, Galway sowie CAPS Enterprise an dem Projektantrag beteiligt. REACT soll die Arbeiten des FP7-Projektes AutoTune fortsetzen bzw. ergänzen, indem das in AutoTune realisierte Periscope Tu- ning Framework (PTF) für massiv parallele Applikationen weiterentwickelt werden soll. Es soll das innerhalb des PTF realisierte statische Tuning bezüglich Performance und Energieersparnis dynamisch und in Abhängigkeit aktuell bereitstehender System-Ressourcen erfolgen. Über den Antrag wird im Jahr 2013 entschieden.

2.6.9 Arbeiten für die Antragstellung FEPA Innerhalb des dritten BMBF-Call „HPC-Software für skalierbare Parallelrechner“ hat das LRZ mit dem Regionales Rechenzentrums Erlangen (RRZE) und mit dem Industriepartner NEC Deutschland GmbH die Projektskizze „Ein flexibles Framework zur Energie- und Performanceanalyse hochparalleler Appli- kationen im Rechenzentrum“ (FEPA) eingereicht. Das Ziel von FEPA ist die Realisierung einer Überwa- chungssoftware zur systematischen Effizienzanalyse von Applikationen in Abhängigkeit des zu Grunde liegenden HPC-Systems. Neben der gezielten Optimierung bezüglich Performance und Energieverbrauch von kritischen Applikationen sollen im Projekt Erkenntnisse gewonnen werden, die eine Senkung des Energieverbrauchs durch angepasste Ausführungs-Modalitäten (Frequenzanpassung, Nutzung weniger Cores/Sockel, etc.) bei vertretbaren Laufzeit-Zugeständnissen ermöglichen. Für das LRZ würde dabei eine Projektstelle geschaffen, mit der u .a. das im LRZ produktiv eingesetzte Monitoring-Tool „PerSyst“ weiterentwickelt werden könnte. „PerSyst“ wurde während des BMBF-Projektes ISAR entwickelt, welches 2011 erfolgreich abgeschlossenen wurde. Über den Antrag wird im Jahr 2013 entschieden werden.

Jahresbericht 2012 des Leibniz-Rechenzentrums 21

2.6.10 PROSPECT e.V. Das LRZ ist gemeinsam mit dem FZ Jülich und dem Barcelona Supercomputing Center Gründungsmit- glied von PROSEPCT e.V. Der Fokus der Arbeiten lag auch 2012 auf den Themen „European OFS“ und „European Technology Platform (ETP) for HPC“.

2.6.11 ETP4HPC Die European Technology Platform for High Performance Computing (ETP4HPC) wurde nach intensiven Abstimmungsgesprächen mit anderen europäischen HPC-Akteuren im Juni 2012 als niederländischer Verein mit Büros in Barcelona, Bologna, München und Paris gegründet. Ziel der ETP4HPC ist es, mit Hilfe eines noch auszuarbeitenden Forschungs- und Entwicklungsprogrammes sowohl die Anwendung als auch die Herstellung von HPC-Technologien in Europa zu fördern. Das LRZ ist ein Gründungsmit- glied und im Lenkungsausschuss mit einer Stimme vertreten.

2.7 Benutzerunterstützung für Hochleistungssysteme

2.7.1 Benutzeranfragen Die in den vergangenen Jahren deutlich gestiegene Anzahl von Nutzern und der große Job-Durchsatz an den Höchstleistungssystemen und am Linux-Cluster haben zu einer kontinuierlichen Steigerung von Sup- portanfragen geführt, die nur mittels des Troubleticket-System kontrolliert abgearbeitet werden können (siehe Abbildung 9). Diese Möglichkeit der Kontaktaufnahme wurde von den Benutzern sehr gut angenommen und hat die Kontaktaufnahme via E-Mail oder Telefon fast völlig ersetzt. Die leichte Benutzung des Servicedesk-Portals “verleitet“ leider manche Benutzer dazu, einfache Fragen direkt in das System einzustellen, ohne vorher die Dokumentation oder die aktuellen Meldungen des LRZ gelesen zu haben.

1400 1166 1200 934 1000 838 800 574 625 600 400 200 0 2008 2009 2010 2011 2012

Abbildung 9 Entwicklung der Anzahl der Supportanfragen im Bereich Hochleistungsrechnen

2.7.2 Kurse und Ausbildung Der hohe Stand des Aus- und Weiterbildungsangebots mit den etablierten Kursen zu Programmierspra- chen und Programmentwicklung, Parallelisierung und Optimierung, Fluid-Dynamik sowie Life-Sciences und Visualisierung wurde gehalten. Darüber hinaus wurden das erste Mal eine Reihe von Kursen im PRACE Advanced Training Centre (PATC) Programm angeboten, in dem die drei Gauß-Zentren partizi- pieren. Neben dem traditionellen, halbjährlich stattfindenden Workshop zum parallelen Programmieren fanden auch ein einwöchiger Fortran-Kurs sowie mehrere eintägige Einführungen in Tools zur parallelen Per- formance-Analyse statt. Als PATC-Kurse fanden statt: Eine einwöchige Veranstaltung zur Programmierung und Optimierung am neuen Supercomputer des LRZ in Zusammenarbeit mit den Lieferfirmen IBM und Intel, ein einwöchiger

22 Hochleistungsrechnen und Grid

Workshop zu fortgeschrittenen HPC Themen, sowie ein einwöchiger Kurs zu fortgeschrittenen Fortran Themen. Die Aktivitäten zu parallelen Programmiersprachen (PGAS) wurden mit einem Tutorial auf der Super- computing Conference in Salt Lake City fortgeführt.

2.7.3 Standardisierungs-Aktivitäten im Bereich der parallelen Programmie- rung Die technische Spezifikation ISO/IEC TS29113, die als Erweiterung des Fortran-Standards zusätzliche Interoperabilität mit C definiert, hat ihre Abstimmung erfolgreich bestanden und ist damit veröffentli- chungsreif. Diese Spezifikation ist eine wesentliche Grundlage für die Fortran-spezifischen Neuerungen im ebenfalls veröffentlichten MPI-3 Standard, der darüber hinaus signifikante Erweiterungen für das parallele Programmieren bereitstellt. Im Bereich der PGAS-Funktionalität wurde darüber hinaus vom Stan- dardisierungskomitee die Arbeit an zusätzlicher in Fortran integrierter paralleler Semantik in Angriff genommen, die für eine bessere Skalierbarkeit von Programmieraufwand und erzielbarer Rechenleistung ausgelegt ist. Als Vertreter der deutschen Delegation in der internationalen Standardisierungskommission JTC1/SC22/WG5 für die Programmiersprache Fortran wirkte und wirkt der LRZ-Mitarbeiter Dr. Rein- hold Bader an der Erstellung der vorgenannten Technischen Spezifikationen mit; er hat darüber hinaus auch bei der Definition der neuen Fortran-Schnittstelle für MPI-3 in beratender Funktion an der diesbe- züglichen Diskussion im MPI-Forum teilgenommen.

2.7.4 Öffentlichkeitsarbeit Das LRZ hat sich wieder auf den Supercomputing-Konferenzen ISC12 in Hamburg und SC12 in Salt Lake City präsentiert. Dabei traten die drei Gauss-Mitgliedszentren auf der ISC zum ersten Mal mit einem neu gestalteten, gemeinsamen Stand auf. Das LRZ verwendete wieder sein verteiltes Display mit vier großen HD-Monitoren, das mit Informationen, Filmen, Animation oder Simulationen beschickt wurde, die alle Bereiche des LRZ vorstellen und zudem einen Ausblick auf den Neubau und den SuperMUC boten.

Abbildung 10 Neuer GCS Stand auf der ISC

Während der CeBIT vom 6.-10. März 2012 war das LRZ erneut mit seinen GCS Partnern am Stand des Bundesministeriums für Bildung und Forschung unter dem diesjährigen Motto „Energie“ vertreten. Ge- zeigt wurden primär Simulationen zum Thema „Supercomputing im Bereich regenerativer Energieerzeu- gung“, z.B. eine 3-D „Virtual Reality“ Simulation eines von EnBW geplanten Pumpspeicherkraftwerkes

Jahresbericht 2012 des Leibniz-Rechenzentrums 23 im nördlichen Schwarzwald und eine „Augmented Reality“-Simulation einer Kaplan-Turbine, bei der dem Kamerabild einer real aufgebauten Turbine der hydrodynamisch berechnete Wasserfluss durch die Turbinenschaufeln überlagert werden konnte. Neben den auf einem 152 Zoll großen Monitor gezeigten 3- D Simulationen liefen an einer Info-Säule u.a. diverse wissenschaftliche Simulationen, die auf dem HLRB II berechnet wurden. Viele der im Schnitt täglich 1.000 Besucher am Stand waren an näheren In- formationen zu den gezeigten Filmen u.a. aus Astrophysik, CFD und Biochemie interessiert.

Abbildung 11 Bundesministerin Annette Schavan verfolgt eine 3-D Simulation am BMBF-Stand auf der CeBIT 2012

Anfang 2012 wurde ein abschließender Berichtsband über die Arbeiten am HLRB II erstellt. Der Berichtsband enthält mehr als 90 Artikel aus den Fachgebieten Astrophysik, Chemie, Fluiddy- namik, Informatik und Mathematik, Geowissenschaften, Hoch- energiephysik, Lebenswissenschaften und Festkörperphysik. Das Buch liefert einen Überblick über das breite Anwendungsspekt- rum von Problemen, die eine Nutzung von Höchstleistungsrech- nern erfordern. Die Artikel liefern Informationen über den wissenschaftlichen Hintergrund, die erzielten Resultate und über die eingesetzten Methoden. Das Buch bietet auch Einblicke in die erreichte Rechenleistung sowie in die Skalierbarkeit der Anwen- dungen. Viele Autoren geben auch einen Ausblick auf die Prob- leme die sie mit dem neuen Höchstleistungsrechner lösen wollen. Dieser Berichtsband und auch Berichtsbände aus den Vorjahren können beim LRZ angefordert werden oder sind unter der folgenden Adresse abrufbar: http://www.lrz.de/services/compute/supermuc/magazinesbooks/

Der Berichtsband wurde auch bei der Einweihungsfeier für den SuperMUC verteilt. Für die Einweihungs- feier des SuperMUC wurde auch ein 10-minütiger 3-D Film erstellt, der mit Animationen das Gebäude des LRZ, den Rechner selbst aber auch viele Aspekte des wissenschaftlichen Rechnens am LRZ aufzeigt. Ein Ausschnitt davon (Animation des SuperMUC) findet sich unter folgender Adresse: http://www.youtube.com/watch?v=GxGrLm4ufYE

2.8 Grid-Dienste Grid-Computing bezeichnet die Vernetzung weltweit vorhandener heterogener Ressourcen wie Rechner, Instrumente, Software und Daten zur koordinierten Lösung sogenannter „großer Herausforderungen “

24 Hochleistungsrechnen und Grid

(grand challenges). Die Grid middleware abstrahiert dabei von den Eigenheiten der Hardware und stellt dem Benutzer ein einfach zu bedienendes, homogenes Interface zur Verfügung. Typische Grid- Anwendungen sind daher datenintensive (Big Data) oder rechenintensive Berechnungen, die auf Ressour- cen 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. 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 besonders zur Deckung von Bedarfsspitzen geeignet ist, mit zu den wichtigsten Technologien der nächsten Jahre und zum Motor völlig neuer An- wendungen entwickeln werden. Der große Unterschied zwischen Grid-Computing und Cloud-Computing ist der föderale Aspekt beim Grid-Computing, der beim Cloud-Computing fehlt: eine Gruppe von Res- sourcenanbietern, z.B. Rechenzentren wie das LRZ, stellen ihre Rechner ins Grid, das dann den Grid- Benutzern eine sehr hohe Gesamtrechenkapazität bieten kann. Dank Grid-Middleware wie Globus, Unicore oder gLite, welche die Unterschiede in der Bedienung der verschiedenen Ressourcen nivelliert, erscheint das Grid dem Benutzer wie eine einzige große, homogene Ressource. Bis zu 10% der Rechenleistung der LRZ-Höchstleistungsrechner SuperMUC und SuperMIG sowie ein nicht unerheblicher Teil der Rechenleistung unseres Linux Clusters werden über Grid-Middleware von den Wissenschaftlern in Deutschland und Europa abgerufen. Der Regelbetrieb der Grid-Dienste wurde durch die Mitarbeiter der Gruppe „Verteilte Ressourcen“ betreut und ausgebaut. Derzeit betreut die Gruppe etwa 70 Server auf denen ca. 40 Dienste in Produktions- und Testbetrieb laufen. Bei den seit Anfang 2012 in Produktion befindlichen Systemen lag die Verfüg- barkeitsquote bei 99.998%. Um die Ausfallsicherheit der Dienste weiter zu erhöhen, wurde fortgefahren, sie von physischer Hardware auf virtuelle Maschinen aus dem LRZ VMware-Pool zu migrieren. Außer- dem wurde die automatische Überwachung der Maschinen und Dienste deutlich erweitert, sowie regel- mäßige Kernel-Updates und Security-Checks durchgeführt. Das LRZ bot seinen Benutzern die folgenden Grid-Dienste an  Interaktiver Zugang über Globus GsiSSH  Datentransfer (Globus GridFTP, Unicore, gLite dCache). Das LRZ installierte weltweit sichtbare Einstiegspunkte für die LRZ Hoch- und Höchstleistungsrechner im neuen europäischen Globus- Online Service (http://www.globusonline.eu/).  Job-Submission (Globus, Unicore, gLite). Auf dem Linux-Cluster wurden 4.867.331 Grid-Jobs mit insgesamt 10.428.658 CPU-h gerechnet.  Grid-FTP, Gsi-SSH und GRAM Door Node für PRACE  Proxyzertifikatsmanagement (Globus MyProxy) für PRACE und D-Grid  Ausstellen von langlebigen Grid-Zertifikaten im Rahmen des Betriebs der Registration Authori- ties für die großen Münchner Universitäten (TUM, LMU, Universität der Bundeswehr) wie auch für das LRZ selbst. Insgesamt wurden 2012 49 Zertifikate ausgestellt. Der Rückgang dieser Zahl gegenüber dem Vorjahr begründet sich in einer zunehmenden Nutzung des Short Lived Credenti- al Services (SLCS) des DFN, der ein langlebiges Zertifikat überflüssig macht.  Grid-Überwachungs- und -Informationsdienste (Inca, MDS, WebMDS, D-MON, DMOS, NAGIOS)  Grid Test Bed (für die Projekte IGE, SLA4D-Grid, VERCE und DGSI)  Download-Site (sog. Repository) für das Projekt IGE  Web-Server für das European Globus Community Forum (EGCF)  Grid Anwenderprogramme: GlobusOnline, gtransfer, GSI-SSHTerm, JSAGA, UNICORE  Training-Kurse für die Globus Middleware  Grid-Benutzerunterstützung (Helpdesk)  Grid-Portal (http://www.grid.lrz.de/)  Grid-Benutzerverwaltung (GUA) als Bindeglied zwischen den unterschiedlichen Benutzerverwal- tungssystemen der Grid-Projekte (siehe nächster Abschnitt) und dem am LRZ verwendeten Sys- tem LRZ-SIM. Die Zahl der Grid-Accounts betrug ca. 1.250. Als abteilungsübergreifende Einrichtung war und ist der Arbeitskreis Grid Computing (AK-Grid) maß- geblich an der Koordinierung der verschiedenen Grid-Projekte (DGI-2, PRACE-1IP, PRACE-2IP, PRACE-3IP, LCG Tier-2, EGI-InSPIRE, IGE, VERCE, Grid Aktivitäten an LMU, TUM, RZG, UniBW

Jahresbericht 2012 des Leibniz-Rechenzentrums 25 und LRZ) innerhalb des LRZ und im Münchner Raum beteiligt, hilft Synergien auszunutzen und Doppel- arbeit zu vermeiden.

2.9 Projekte im Grid-Computing Das LRZ ist aktiv beteiligt an vielen nationalen und internationalen Grid-Projekten „Initiative for Globus in Europe – IGE“, „European Grid Initiative - Integrated Sustainable Pan-European Infrastructure for Researchers in Europe – EGI-InSPIRE“,„Partnership for Advanced Computing in Europe, 1st Implemen- tation Phase - PRACE-1IP“, „Partnership for Advanced Computing in Europe, 2nd Implementation Phase - PRACE-2IP“, „Partnership for Advanced Computing in Europe, 3rd Implementation Phase - PRACE- 3IP“ , „Virtual Earthquake and seismology Research Community e-science environment in Europe – VERCE“, den D-Grid-Projekten DGI2, SLA4D-Grid sowie DGSI, LHC-Grid (LCG) und „e- Infrastructure Reflection Group Support Programme 3 (e-IRGSP3)" beteiligt. Dabei hat das LRZ bei IGE erstmalig die Führungsrolle in einem europäischen Projekt inne. Im Folgenden beleuchten wir einige der in den Grid-Projekten durchgeführten Arbeiten ausführlicher.

2.9.1 Initiative for Globus in Europe (IGE) IGE will hauptsächlich koordinierend eingreifen und die europäischen Wün- sche zur Globus Middleware bündeln und abstimmen, um sie dann mit einer gewichtigen Stimme gegenüber den anderen Globus-Entwicklern vorzutragen. IGE integriert zehn europäische Partner sowie die University of Chicago, die die zentrale Globus-Codebasis pflegt. IGE liefert die Globus Middleware für die europäischen Grid-Infrastrukturen wie EGI, PRACE, VERCE, DRIHM, etc., und führt neben Benutzerunterstüt- zung und Training auch Anpassungen von Globus an europäische Bedürfnisse durch. Dieses Projekt stärkt die Rolle Europas und natürlich auch des LRZ im Globus-Projekt, dem weltweit führenden Midd- leware-Projekt. Das LRZ hat hier erstmals die Konsortialführerschaft eines EU Projekts inne und organisierte im Novem- ber 2012 das zweite EU Review Meeting von IGE in Brüssel. Die Gutachter konstatierten dem Projekt gute bis sehr gute Fortschritte. Es wurde das zweite Treffen des European Globus Community Forums (EGCF: http://www.egcf.eu/) am LRZ ausgerichtet und die zweite GlobusEUROPE-Konferenz, das europäische Pendant zur amerikani- schen GlobusWORLD-Konferenz, in Prag organisiert. IGE lieferte Software-Releases der Globus Tools für die europäischen e-Infrastrukturen aus, die auch Eingang in die Unified Middleware Distribution (UMD) von EGI fanden.

2.9.2 D-Grid (Förderung „e-Science und vernetztes Wissensmanagement“ des BMBF) In Deutschland hat insbesondere die D-Grid-Initiative (www.d- grid.de) die Auswirkungen der neuen Technologie „Grid“ auf das wissenschaftliche Arbeiten thematisiert und ein entspre- chendes Forschungs- und Entwicklungsprogramm vorgeschla- gen. D-Grid hat es sich zum Ziel gesetzt, alle Grid-Aktivitäten in Deutschland zu bündeln, um so intern Synergieeffekte auszunutzen und nach außen mit einer einheitlichen Stimme sprechen zu können. Die vom BMBF für den Zeitraum von 2005 bis 2012

26 Hochleistungsrechnen und Grid 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 2012 an vielen Work- shops und Treffen teil. Da D-Grid zum Jahresende 2012 zu Ende ging, wurden die Aktivitäten im letzten Jahr schrittweise an NGI-DE (National Grid Initiative – Deutschland) übergeben. NGI-DE ist die deutsche Vertretung im Rahmen des europäischen Grid-Verbunds, der European Grid Infrastructure (EGI).

2.9.2.1 D-Grid Integrationsprojekt (DGI) Als Rechenzentrum und damit als Ressourcenanbieter war das LRZ vorrangig am D-Grid Integrations- projekt (DGI, Laufzeit Jan. 2008 bis Dez. 2012) beteiligt. Aufgrund langjähriger guter Kontakte zu HPC- Benutzern aus Astro- und Hochenergiephysik trat das LRZ aber auch als assoziierter Partner der Astro- physik- und der Hochenergiephysik-Community auf. Außerdem war zur Vertretung der Globus- Ressourcen-Anbieter ein Mitarbeiter des LRZ im Technical Advisory Board (TAB) des D-Grid vertreten. Das LRZ stellt im verteilten Kompetenzzentrum Middleware vielfältiges Know-how für die Unterstüt- zung von Benutzern und Ressourcenanbietern bezüglich Globus bereit. Auf den Produktionssystemen des LRZs wurde Globus von GT5.0.3 auf GT5.2.2 angehoben. Das LRZ hat die Ressourcen, die im Rahmen früherer Sonderinvestitionen beschafft wurden, weiterbe- trieben und für das D-Grid verfügbar gemacht. Im Jahr 2012 wurden auf diesen Ressourcen fast 4,5 Mio. Jobs submittiert, die ca. 10 Mio. CPUh verbraucht haben. Der Speicherplatz im dCache-Pool belief sich auf ca. 560 TB. Als zentrale Dienste für D-Grid hat das LRZ Grid-Monitoring mittels der Werkzeuge RFT, MDS, WebMDS, GridCSM, D-MON und Inca sowie den zentralen MyProxy-Server zur Authentisierung der Nutzer betrieben. Es wurde intensiver Globus-Support für alle Communities, allen voran die Astro- Community, geleistet. Das LRZ arbeitete an der Weiterentwicklung des Monitoringdienstes D-MON, sowie der Durchführung der Zertifizierung der Globus-Installation auf den D-Grid Ressourcen, die Voraussetzung für eine Integra- tion der deutschen Ressourcen in den europäischen EGI-Verbund ist.

2.9.2.2 DGSI Das D-Grid-Projekt „D-Grid Scheduler Interoperability“ (DGSI) entwickelte eine Interoperabilitäts- schicht für Scheduling in Service Grids, die es Benutzern einer Community erlaubt, bei freien Ressourcen Arbeitslast auf Ressourcen einer anderen Community zu verlagern. LRZ-Mitarbeiter beteiligten sich dazu an Telefonkonferenzen und Projekttreffen und brachten so die Sichtweise des LRZ in das Projekt ein. Das LRZ war als Leiter von Task 4 für die Anbindung lokaler Resource Management-Systeme verantwortlich. Im Rahmen dieses Tasks installierte das LRZ die in DGSI entwickelten Ressource-Delegation-Mechanismen der zweiten Generation sowie advance reserva- tion Adaptoren in seinem Testbed. DGSI wurde Mitte 2012 erfolgreich abgeschlossen.

2.9.2.3 SLA4DGRID Das D-Grid-Projekt “Service Level Agreements for D-Grid” (SLA4D-GRID) realisierte 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. Das LRZ entwickelte D-MON, eine D-Grid Eigenentwicklung im Monitoring-Bereich, zu einem in SLA4DGRID verwendbaren Werkzeug weiter. Vom LRZ wurde das Testbed mit sechs Servern den aktuellen Erfordernissen angepasst. SLA4DGRID wurde zum ebenfalls Mitte 2012 erfolgreich abgeschlossen.

2.9.3 EGI-InSPIRE Mit der Beteiligung an EGI-InSPIRE spielt das LRZ auch eine wesentliche Rolle in der zweiten großen europäischen e-Infrastruktur EGI. Zusammen mit der Beteiligung an PRACE fällt damit dem LRZ eine

Jahresbericht 2012 des Leibniz-Rechenzentrums 27 wichtige Funktion für die Integration der Infrastrukturen zu, an der auch in 2012 mit Hochdruck gearbeitet wurde. Die Anforderungen dazu kommen unter anderem aus den Nutzer-zentrierten Projekten MAP- PER, VERCE und DRIHM. Im Projekt EGI-InSPIRE beteiligt sich das LRZ an den Arbeitspaketen zum Entwurf der notwendigen Policies und zur Definition der Grid-Management-Infrastruktur auf europäischer Ebene. Es arbeitet mit am verlässlichen Betrieb der Grid-Dienste, die von der deutschen Grid-Infrastruktur der EGI zur Verfü- gung gestellt werden. Darüber hinaus leistet das LRZ den europaweiten 2nd-Level-Support für das Globus Toolkit

2.9.4 VERCE VERCE hat sich die Unterstützung der Seismologen in Europa zum Ziel gesetzt. VERCE beabsichtigt, die in der Wissenschafts-Community vorhandene Dateninfrastruktur mit den Grid und HPC Infrastrukturen (vorrangig PRACE und EGI) zu verschmelzen. Dem LRZ fällt hierbei die herausragende Rolle zu, einer der Lieferanten von VERCEs service-orientierter Infrastruktur zu sein. Das LRZ leitet das Arbeitspaket „Integration and evaluation of the platform services“ und ist auch in den Arbeitspaketen „Training and User Documentation“, “Management and operation of research platform“, „Harnessing data-intensive applications“ und „VERCE Architecture and Tools for Data Analysis and Data Modelling Applications“ beteiligt. Für die Integration der verschiedenen Software-Produkte in die VERCE Software-Platform wurden zwei Qualitätmanagementzyklen in Anlehnung an die Vorgaben des ISO 20000-Standards durchgeführt. Durch die Leitung einer HPC Taskforce konnte das LRZ maßgeblich zur Erstellung eines Use cases beitragen, der erstmalig einen vollständig automatisierten seismologischen Workflow von den Sensordaten bis zum wissenschaftlichen Endergebnis demonstrierte. Im April erhielt das Projekt beim ersten EU-Review eine sehr gute Bewertung.

2.9.5 MAPPER MAPPER (Multiscale Applications on European e-Infrastructures, http://www.mapper-project.eu/) kon- zentriert sich darauf, die für die Forschung immer wichtiger werdenden Multi-Skalen-Systeme, die mehrere wissenschaftliche Gebiete (wie etwa die Fluiddynamik, die Strukturmechanik und die Chemie der Verbrennungsvorgänge) gemeinsam betrachten, effizient auf die europäischen Infrastrukturen wie EGI und PRACE abzubilden. Solche interdisziplinären Multi-Skalen-Systeme erfordern zu ihrer Simulation höchste Rechenleistung.

Das LRZ fungiert hier als Unterstützung für die LMU, einem der MAPPER Partner, und stellt in diesem Rahmen Hardware und Software sowie weitere umfassende Unterstützung für das Projekt zur Verfügung. So unterstützte das LRZ letztes Jahr das MAPPER-Konsortium bei der Umsetzung und Durchführung von Multi-Skalen-Simulationen auf dem Linux-Cluster und den SuperMUC/SuperMIG HPC-Systemen. Insgesamt wurden drei unterschiedliche Multi-Skalen-Szenarien aus den Bereichen Plasma-Physik, Hyd- rologie und Medizin auf den LRZ-Systemen aufgesetzt, getestet und durchgeführt. Das Hydrologie- Szenario wurde beim MAPPER EU Review Meeting im Novenber dazu verwendet, die Fähigkeiten und Vorteile des Multi-Skalen-Ansatzes zu demonstrieren.

2.9.6 DRIHM DRIHM (Distributed Research Infrastructure for Hydro-Meteorology) baut eine prototypische e-Science- Umgebung für die Hydrometeorologie in Europaauf. Die Hydrometeorologie beschäftigt sich mit der Wechselwirkung zwischen Wetter, insbesondere Regen, dem Boden und den Wasserabflüssen, die zu Überschwemmungen und Erdrutschen führen können. Ziel ist, durch rechtzeitige Gefahrenvorhersage und Evakuierungen Menschenleben retten zu können. Durch mehrere Meetings am LRZ konnte die Zusam- menarbeit mit dem DRIHM-Konsortium, in dem wir bei MAPPER die LMU als Partner fungiert, intensiviert werden. Unter anderem konnte das LRZ die Schwierigkeiten beim Transfer großer Datenmengen zwischen den Partner-Standorten durch Beratung und Unterstützung bei der Verwendung der Globus- Werkzeuge (GridFTP, Globus Online) deutlich reduzieren

28 Hochleistungsrechnen und Grid

2.9.7 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3) Die e-Infrastructure Reflection Group (e-IRG) ist ein Beratergremium der EU, das Empfehlungen zu Best Practices für europäische e-Infrastrukturen ausspricht. Das Gremium setzt sich aus jeweils zwei Delegier- ten der Regierungen aller EU-Staaten zusammen. Es erstellt Weißbücher, Fahrpläne und Empfehlungen und analysiert die zukünftigen Grundlagen der europäischen Wissensgesellschaft. Dieses Beratergremium wird durch das auf drei Jahre angelegte Projekt „e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3)" in seiner Arbeit unterstützt. Das LRZ leitet in diesem Zusam- menhang das Arbeitspaket "Policy Support", das unter anderem die bestehenden Policies analysiert und die Erstellung der Policy-Dokumente (Weißbücher, Fahrpläne, etc.) vorbereitet, koordiniert und publiziert. Das LRZ leitete die Erstellung des Strategiepapiers „e-IRG Policy Paper on Scientific Software“ sowie der „e-IRG Roadmap 2012“. Weitere unter der Koordination des LRZ entstandene Strategiepapiere waren „e-IRG e-Infrastructures in Support of the Digital Agenda“, „e-IRG Reaction on the GÉANT Ex- pert Group Report“, „e-IRG Task Force Report on Cloud Computing“, „e-IRG Blue Paper on Data Ma- nagement“ und ein Dokument über die Neuausrichtung der Stategie der e-Infrastructure Reflection Group. Im Jahr 2012 wurde die bisher größte Anzahl von Strategiepapieren in der neunjährigen Geschich- te der e-IRG veröffentlicht.

2.9.8 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) 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 im LHC Computing Grid (LCG) vernetzt. Das LRZ betreibt dabei zusammen mit dem MCSC-Partner RZG und dem Lehrstuhl für Hochenergiephysik der LMU ein Tier-2-Zentrum (siehe Abbildung 12).

Abbildung 12 Tier-Struktur des LHC Computing Grids.

Speicher- und Rechenknoten des Tier-2 Zentrums wurden im Rechnerwürfel des LRZs installiert. Den Betrieb bis zur Vermittlungsschicht, der Middleware gLite, übernimmt das LRZ, die Middleware und die darüber liegende Experiment-Software wird von den Physikern der LMU betreut. Derzeit steht am LRZ für die Speicherung von Experimentdaten und Auswertungsergebnissen ca. 1 PetaByte zur Verfügung. Durch die Absicherung als RAID beträgt die Nettokapazität aber nur 777 TB, die über die dCache-

Jahresbericht 2012 des Leibniz-Rechenzentrums 29

Speicherverwaltung bereitgestellt werden. Die LCG-Rechenknoten sind in den LRZ-Linux-Cluster integriert. Dadurch können Kapazitätsengpässe sowohl bei LCG-Aufgaben als auch bei LRZ-Aufgaben um- gangen und insgesamt alle Ressourcen besser ausgelastet werden. Im Moment verwaltet das LRZ LCG- Rechenknoten mit 1.828 Cores. Das LRZ stellt dem LCG-Projekt auch virtuelle Maschinen zur Verfügung. Dabei werden die speziellen LCG-Anforderungen – etwa bezüglich des Betriebssystems „Scientific Linux“ – unterstützt.

30 Serverbetrieb

3 Serverbetrieb

3.1 Linux-Server Das Jahr 2012 war im Großen und Ganzen durch die Aufrechterhaltung der Vielzahl bestehender Dienste, basierend auf vermehrt virtueller und vereinzelt noch physischer Hardware geprägt. Die zahlenmäßige Entwicklung installierter Linux-Systeme verdeutlicht folgende Abbildung:

Abbildung 13 Anzahl der Linux-Hosts im Leibniz-Rechenzentrum

Zu den anstehenden Arbeiten zählte in diesem Jahr die ServicePack-Aktualisierung der meisten Server mit „SUSE Linux Enterprise Server 11“ von Version SP1 auf SP2. Die Zunahme an gehosteten, virtuellen Servern für externe Kunden ließ auch die Zahl abzuarbeitender Kunden-Tickets anwachsen. Ein spürbarer Anstieg war in der Kundenberatung für die Bayerische Staats- bibliothek (BSB) zu verzeichnen. Hier gab es die deutlichste Zunahme neuer Kunden-Server. Eine Übersicht über den Anstieg virtueller Server verdeutlicht Abbildung 14. Aufgrund der Fülle an Aufgaben wurde das „Team Linux-Server und -Mitarbeiter-Arbeitsplätze“ (Team- LSM) in der ersten Jahreshälfte durch Zusammenführung mit den Verantwortlichen für das „Hoch- schulstartsystem“ (HSS) zu einer eigenständigen „Gruppe IT-Infrastruktur Server und Dienste“ (ITS) innerhalb der Abteilung Hochleistungssysteme. Verstärkt mit zusätzlichem Personal erfuhr das Thema Sicherheit im Bereich der Linux-Server eine spür- bare Erweiterung. Neben Arbeiten zur Umsetzung einer Passwort-Policy etablierte sich ein zentrales Sys- temmonitoring auf Basis der Analyse-Software „Splunk“. Die mittels Überwachungssoftware „LRZmonitor“ erfassten hostspezifischen Daten wurden zusammen mit den Daten virtueller Hosts aus dem „VMware vCenter“ in eine MySQL-Datenbank integriert. Auf dieser gemeinsamen Datenstruktur können fortan Dienste, wie das in Entwicklung befindliche Self- Service-Portal zum Managen virtueller Hosts, operieren.

Jahresbericht 2012 des Leibniz-Rechenzentrums 31

Abbildung 14 Anzahl virtueller Hosts im Leibniz-Rechenzentrum

Die Virtualisierungsinfrastruktur des LRZ bestand 2012 aus 80 Blade-Systemen mit 640 Kernen, 7,6 TB RAM und 100 TB Hintergrundspeicher unter VMware sowie einigen zusätzlichen Testsystemen. Auf dieser Infrastruktur werden über 820 virtuelle Server unter Windows und Linux betrieben. Seit die Virtua- lisierung von Servern allgemein akzeptiert wurde, werden immer anspruchsvollere und größere Anwen- dungen auf diese Art betrieben. Aus diesem Grund werden auch große virtuelle Systeme mit mehreren Kernen stark nachgefragt. Die organisatorischen Abläufe bei der Bereitstellung von Servern wurden optimiert und der Kundenservice konnte dank zusätzlicher Mitarbeiter verbessert werden. Seit Mitte des Jahres wird im Hinblick auf die Ablösung der aktuellen Server-Blade-Infrastruktur neue Hard- und Software u.a. der Fa. Cisco untersucht. Zu Testzwecken befindet sich deshalb ein Chassis: Cisco UCS 5108 und darin eingebaut: zwei Fabric Interconnects: Cisco UCS 6248UP, zwei Blades: Cisco UCS B200-M3 mit 16 Kernen und 126 GB RAM sowie ein Beta-Blade: Cisco UCS B420-M3 mit 32 Kernen und 256 GB RAM im Serverraum. In der zweiten Jahreshälfte gelangte das Thema Cloud-Computing in den Fokus der Diskussion und Ana- lyse: erste Tests verschiedener Anbietersoftware wurden durchgeführt. Im September 2012 fand eine Life-Demo der „OpenStack-basierten Private Cloud-Suite“ durch den Anbieter SUSE statt.

3.2 Windows Am LRZ werden zurzeit rund 100 physische oder virtuelle Windows Server betrieben. Der Anteil der virtuellen Systeme liegt bei 80%. Es hat sich aber in den vergangenen Jahren wiederholt gezeigt, dass es unter Umständen nicht sinnvoll ist, bestimmte Systeme zu virtualisieren. So wurden die Mailbox-Server für die Exchange-Infrastruktur in 2012 neu mit physischer Hardware aufgebaut um den Storage direkt anbinden zu können. Aus Performancegründen werden noch ein physisches SQL-Cluster und alle Domain Controller des MWN-Active Directory betrieben, da die Leistungsfähigkeit der virtuellen Maschinen zu schlecht ist. Auch verhindern bestimmte Anwendungen wie z.B. für das Gebäudemanagement am LRZ oder Überwachungskomponenten, die möglichst unabhängig von weiterer Infrastruktur betrieben werden müssen, eine Virtualisierung. Die momentan unterstützten Betriebssystemversionen am LRZ reichen dabei von Windows 2000 Server bis zur aktuellen Version Windows Server 2012. Windows Server ist dabei das Basisbetriebssystem für verschiedene höherwertige Dienste am LRZ wie Active Directory, Exchange oder Terminalserver. Die Installation, Pflege und Reporting der Systeme erfolgt über den zentralen Microsoft System Center Configuration Manager 2012 (SCCM) am LRZ, der auch für die Clientsysteme Verwendung findet. Für Monitoring und Alerting findet der Microsoft System Center Operation Manager 2012 (SCOM) von

32 Serverbetrieb

Microsoft Verwendung, der mit seinen vorgefertigten Management Packs gezielt, nicht nur das Betriebs- system, sondern auch die auf den Servern betriebenen Dienste wie Active Directory, Exchange oder MS SQL überwacht. Unterstützt wird das Monitoring der Hardware bei den physischen Servern durch DELL Openmanage, wodurch Hardwareprobleme an den SCOM gemeldet werden.

Jahresbericht 2012 des Leibniz-Rechenzentrums 33

4 Datenhaltung

4.1 Überblick Datenhaltung Hinsichtlich der Art der Datenträger gliedert sich die Datenhaltung am LRZ im Wesentlichen in zwei Bereiche,  den Bereich der Massenspeicher der Archiv- und Backupsysteme mit ihren Bandbibliotheken (Abschnitt 4.2), auf die sich unter anderem die Langzeitarchivierung (Abschnitt 4.2.4) abstützt,  und in den Bereich der Online-Speicher (Abschnitt 4.3) vorwiegend auf der Basis von Network Attached Storage (NAS). Bezeichnend für den rasanten Datenzuwachs ist die Tatsache, dass inzwischen Petabyte als Einheit zur Angabe größerer Datenmengen die noch im Jahresbericht 2011 benutzte Einheit Terabyte abgelöst hat (ein Petabyte = 1.000 Terabyte =1015 Byte = 1.000.000.000.000.000 Byte). Für Sicherungssysteme zweiter Ordnung sowie für die Archivierung von großen Datenmengen sind Bän- der als Datenträger gestern wie heute unverzichtbar. Der Umfang der in den Bandbibliotheken des LRZ gespeicherten Daten wuchs im Jahr 2012 von 20 PetaByte auf 28 PetaByte an. Die Zusammenarbeit mit der Bayerischen Staatsbibliothek und dem Bibliotheksverbund Bayern wurde weiter intensiviert. Dabei fungiert das LRZ als IT Service Provider in den Bereichen Serverhosting, Clus- terhousing, Storagehousing einerseits und als Projekt- und Kooperationspartner in verschiedenen Projek- ten andererseits. Die Bayerische Staatsbibliothek verfügt über einen eigenen Online-Speicher mit 0,7 Petabyte Kapazität am LRZ, der von verschiedenen Arbeitsgruppen und Projekten genutzt wird. Dieser Speicher ist auch Ausgangspunkt für die Übertragung der Daten ins Langzeitarchiv des LRZ, in dem sich mittlerweile knapp 0,5 Petabyte Archivdaten befinden. Am LRZ und an den anderen Kommissionen der Bayerischen Akademie der Wissenschaften wird gemeinsam nutzbarer, hoch verfügbarer und optimal gesicherter Speicher auf Basis der NAS-Technologie eingesetzt. Dieser sogenannte MWN-Speicher oder „Speicher für Wissenschaft“ steht als Grundversor- gungsangebot auch Mitarbeitern und Studierenden der TU München und der LMU zur Verfügung und ersetzt dort immer häufiger lokale Lösungen. Im Zuge der Installation des SuperMUC wurden sowohl die Online-Speichersysteme als auch die Archiv- und Backupsysteme erheblich erweitert. Das gesamte Jahr 2012 war geprägt von den umfangreichen Ar- beiten in diesem Zusammenhang, insbesondere die Verlagerung der Daten auf die neuen Systeme. Insgesamt ist der zur Verfügung stehende Online-Speicherplatz auf NAS-Basis auf mehr als 9 Petabyte brutto angewachsen. Zusammen mit dem SAN-Speicherplatz beträgt die Bruttokapazität der Plattenspei- cher über 12 Petabyte verteilt auf über 8.000 Festplatten. Hinzu kommen 10 PB für das parallele Filesys- tem des SuperMUC.

4.2 Archiv- und Backupsystem

4.2.1 Konfiguration Das Archiv- und Backupsystem des LRZ besteht aus drei großen Systemen mit Bandrobotern:  einem Hochleistungssystem HABS, das Anfang 2006 installiert und seitdem dreimal (Ende 2007, 2010 und Mitte 2012) erweitert wurde,  und einem System mit LTO-Bandlaufwerken in mehreren Bibliotheken (LABS), das 2010 neu installiert wurde.  Zusätzlich wurde mit der jüngsten HABS Erweiterung im Jahr 2012 ein Desaster Recovery Sys- tem (DRABS) beschafft, das eine zweite Kopie der Archivdaten vorhält. Dieses System ist, um die Ausfallsicherheit zu erhöhen, räumlich getrennt am Rechenzentrum Garching der Max-Plack- Gesellschaft installiert. Ebenfalls aus Gründen der Ausfallsicherheit befinden sich die Komponenten der drei Systeme in getrennten Speichernetzen (SAN-Fabrics). An die SAN-Fabrics sind die Storageserver, alle Bandlaufwerke der Libraries und alle Serversysteme mit hohem Datenverkehr, insbesondere die File- und Backupserver an-

34 Datenhaltung geschlossen. Die SAN-Fabrics sind Grundlage für einen effizienten Transport von großen Datenmengen, durch sie wird die Last am LAN reduziert und eine dynamische Zuordnung der Speicherkomponenten zu den Verbrauchern ermöglicht.

Archive and Backup System, Dec 2012

IBM SUN Disk Cache + DB Brocade Brocade 6510 DELL Brocade 6510 IBM DS3500 399 TB

Library IBM TS3500 7 tape devices IBM LTO5 2 TSM Servers 19,137 slots DRABS – TSM Desaster Recovery Archive and Backup System (RZG)

10 GBit Ethernet

2-8 TSM Servers 2-8 TSM Servers DB 3 TSM Servers 3 TSM Servers 8 machines 12 machines

TSM TSM TSM TSM IBM StorWize TSM SUNFire X4270 TSM IBM X3850x5 V7000 IBM X3550 M3 10 TB SSD

Disk Cache + DB Disk Cache SAN Disk Cache + DB SAN Brocade 5300

Brocade 5300 Brocade Brocade IBM DS3500 DCX DCX DELL PowerVault Brocade 5300 SUN 6780 1539 TB 8510-4 8510-4 MD36XXf Brocade 5300 486 TB 281 TB

Library SUN SL8500 Library IBM TS3500 Library SUN SL8500 Library IBM TS3500 L52 26 tape devices SUN T10K-B 16 tape devices IBM LTO5 10 tape devices IBM LTO4 10,000 slots 15 tape devices IBM LTO5 17,333 slots 16 tape devices IBM LTO4 8 tape devices IBM LTO5 10,000 slots 5,039 slots

HABS – LABS – High Performance Archive and Backup System LTO Archive and Backup System

Abbildung 15 Überblick Archiv- und Backupsysteme

Die wesentlichen Komponenten des Systems sind:  21 Rechner (Vorwiegend Intel Nehalem EP und EX), 388 Cores, 3.952 GB Memory  6 Fibre Channel Switches (8 Gbit/16 Gbit) und 2 Fibre Channel Direktoren (8/16 Gbit)  56 10 GE LAN Ports mit 100 Gbit/s Uplink zum LRZ Backbone  18 Storage Servern mit insgesamt 2.700 TB (Brutto) verteilt auf 2.424 Disks und 38 SSDs mit 70 GB/s theoretischer Gesamtdurchsatz  5 Tape Libraries mit insgesamt 61.500 Slots  98 Bandlaufwerke (LTO-4, LTO-5, T10K) mit 24 GB/s theoretischem Gesamtdurchsatz

Softwareseitig wird die gesamte Architektur mit dem Tivoli Storage Manager von IBM betrieben. Auf den 21 Rechnern des Systems laufen jeweils mehrere Instanzen des Tivoli Storage Manager, insgesamt waren Ende 2012 64 TSM-Server in Betrieb

Die Abbildungen auf den folgenden Seiten zeigen die drei Teil-Konfigurationen des HABS, LABS bzw. DRABS im Detail.

Jahresbericht 2012 des Leibniz-Rechenzentrums 35

High Performance Archive and Backup System 2012

Cur. tape capacity: 17.500 TB, 10.000 T10K cartridges + 5000 LTO-5 cartridges Max. tape capacity: 53.000 TB, 10.000 T10K cartridges + 17.300 LTO-6 cartriges Tape devices: 26 x T10K-B, 15 x LTO-5 Disk capacity: 10 TB SSD, 117 TB SAS, 1702 TB NL-SAS

Linux Compute Munich Scientific Cluster Network

Router MWN

10 Gbit 10 Gbit

SuperMUC Network HP E6600-24XG Switch HP E6600-24XG Switch Switches 24 x 10 GbE Ports 24 x 10 GbE Ports

4 x 10 Gbit Ethernet HPC special 12 x 10 Gbit Ethernet 11 x 10 Gbit Ethernet 1 x 10 Gbit Ethernet HPC special

1 x IBM X3550 M3 4 x IBM X3850 X5 3 x IBM X3850 X5 2 x Intel Xeon E5606 4 x Intel Xeon X7550 2.0 GHz 4 x Intel Xeon E7-4860 2.27 GHz 2.13 GHz 256-512 GB Memory 512 GB Memory 16 GB Memory Pentium 4 8 x FC 8 Gbit 8 x FC 8 Gbit Pentium 4 OPTERON 4 x FC 8 Gbit WorkOSePr1 TSEeRrvOerN 4 x 10 GbE Trunk WoOrkPeTr ESRerOveNr 4 x 10 GbE Trunk Mgmt. Server S1 Sn 2 x 2 core 2 x 1 GbE 27 x 2 coSrne XEON E5606 XEON X7550 SLES 11 SP2 XEO2 Nx 2X 7c5o5re0 SLES 11 SP2 7 SLES 11 SP2 4 x 8 Core TSM Server 6.3 4 x 10 Core TSM Server 6.3 1 x 4 core TSM Server 6.3

72 x 8 Gbit FC National Supercomputer 8 x 8 Gbit FC SuperMUC Storage Area Network

FC-Direktor FC-Direktor 48 Port 8Gb + 64 Port 16Gb 48 Port 8Gb + 64 Port 16Gb

26 x 4 Gbit FC

104 x 8 Gbit FC

15 x 8 Gbit FC

Dell MD3660f Dell MD3620f Dell MD3620f Dell MD3620f NL-SAS SAS 39 TB SAS 39 TB SAS 39 TB 163 TB

IBM TS3500 tape library 15 FC tape drives LTO-5 IBM DS3500 IBM DS3500 IBM DS3500 IBM DS3500 Max library capacity: 43.000 TB uncompressed NS-SAS NS-SAS NS-SAS NS-SAS Cur. library capacity: 7.500 TB uncompressed 212 TB 212 TB 212 TB 212 TB

IBM DS3500 IBM DS3500 IBM DS3500 NS-SAS NS-SAS NS-SAS 229 TB 229 TB 229 TB STK SL8500 tape library 26 FC tape drives Titanium B

IBM V7000 IBM V7000 1118 disks total capacity: Max library capacity: 10.000 TB uncompressed SSD 5TB SSD 5TB Cur. library capacity: 10.000 TB uncompressed 1830 TB

Abbildung 16 Hochleistungs-Archiv-und Backupsystem Ende 2012

36 Datenhaltung

LTO Archive and Backup System 2012

Cur. tape capacity: 14.039 TB, 5.500 LTO-4 cartridges + 6426 LTO-5 cartridges Max. tape capacity: 22.500 TB, 16.500 LTO-5 cartridges Tape devices: 26 x LTO4 + 24 LTO5 drives Disk devices: 222 TB FC-AL, 262 TB SATA

Router MWN

10 Gbit

HP E6600-24XG Switch HP E6600-24XG Switch 24 x 10 GbE Ports 24 x 10 GbE Ports

Munich Scientific Network

28 x 10 Gbit Ethernet

12 x Sun Fire X4270

Pentium 4 2 x INTEL X5560 2.8 GHz Pentium 4 Pentium 4 72/16 GB Memory PentiumS n4 Sn PentiumS n4 Sn 4 x FC 8 Gbit PentiumS n4 Sn PentiumS n4 Sn 2 x 10 GbE (Failover) PentiumS n4 Sn Sn Sn SuSn S1Fnire X4270Sn 9 Worker / 3 MgSmnt. SLES 11 SP2 7 2 XEON x 4 Core TSM Server 6.3

56 x 8 Gbit FC

Storage Area Network

8 GBit FC-Switch 80 Port 8 GBit FC-Switch 80 Port

26 x 4 Gbit FC 48 x 8 Gbit FC 24 x 8 Gbit FC

5.000 slots total capacity: 7.500 TB

IBM TS 3500 tape library 10.000 slots total 10 x LTO-4 + 8 x LTO-5 capacity: 15.000 TB

SUN 6780 SUN 6780 SUN 6780 SUN SL8500 tape library FC-AL 65 TB FC-AL 65 TB FC-AL 61 TB 16 x LTO-4 + 16 x LTO-5 SATA 87 TB SATA 87 TB SATA 87 TB Max library capacity: 22.500 TB uncompressed Cur. library capacity: 14.039 TB uncompressed 1152 disks, total capacity: 484 TB

Abbildung 17 LTO-Archiv-und Backupsystem Ende 2012

Jahresbericht 2012 des Leibniz-Rechenzentrums 37

Desaster Recovery Archive and Backup System 2012

Cur. tape capacity: 9.000 TB, 6.000 LTO-5 cartridges Max. tape capacity: 47.800 TB, 19.137 LTO-6 cartriges Tape devices: 7 x LTO-5 Disk capacity: 6 TB SAS, 393 TB NL-SAS

Munich Scientific Network

Router MWN

10 Gbit

HP E6600-24XG Switch 24 x 10 GbE Ports

4 x 10 Gbit Ethernet

1 x IBM X3850 X5

4 x Intel Xeon E7-4860 2.27 GHz 512 GB Memory 8 x FC 8 Gbit Worker Server 4 x 10 GbE Trunk XEON X7550 SLES 11 SP2 4 x 10 Core TSM Server 6.3

16 x 8 Gbit FC

Storage Area Network

FC-Switch FC-Switch 24 Port 16Gb 24 Port 16Gb

7 x 8 Gbit FC 16 x 8 Gbit FC

IBM DS3500 IBM DS3500 IBM TS3500 tape library SAS 3 TB SAS 3 TB 7 FC tape drives LTO-5 NL-SAS 196 TB NL-SAS 196 TB

Max library capacity: 47.800 TB uncompressed 192 disks total capacity: Cur. library capacity: 9.000 TB uncompressed 399 TB

Abbildung 18 Desaster Recovery Archiv- und Backupsystem Ende 2012

38 Datenhaltung

4.2.2 Aktivitäten

Beschaffung und Inbetriebnahme eines Hochleistungsarchivs für den SuperMUC Der Schwerpunkt im Jahr 2012 lag bei den Aktivitäten rund um das neue Archiv-System für den Super- MUC, welches auch das neue Desaster Recovery Archiv- und Backupsystem (DRABS) umfasste. An der europaweiten Ausschreibung im ersten Quartal 2012 beteiligten sich die Firmen IBM, Oracle und SpectraLogic/SGI, vertreten jeweils durch deren Businesspartner. Den Zuschlag konnte die Firma IBM – vertreten durch die SVA GmbH – für sich entscheiden. Das IBM-Angebot erfüllte alle Kriterien und konnte an einigen Stellen sogar mit deutlicher Übererfüllung hinsichtlich Kapazität und Leistungsfähig- keit punkten. Im zweiten Quartal 2012 wurde die Hardware für das SuperMUC-Archivs am LRZ und das Desaster Recovery Archiv- und Backupsystems am RZG geliefert und aufgebaut. Es wurden 5 Server, 4 SAN Switche, 9 Storagesysteme mit 750 Platten und zwei Libraries mit insgesamt fast 36.500 Stellplätzen innerhalb weniger Wochen installiert und in Betrieb genommen. Der Hardwareaufbau inklusive Verkabe- lung (etwa 250 Kabel) und Beschriftung wurde wie in der Ausschreibung gefordert, von den Firmen IBM und SVA übernommen. Der Aufbau verlief sehr zügig und reibungslos, so dass das System bereits im Juni betriebsbereit erklärt wurde. Parallel dazu wurde das neue SuperMUC-Archiv und das vorhandene HABS durch den Umzug der HABS-Server in den hochverfügbaren Rechnerraum DAR1 zu einem Sys- tem zusammengeschlossen (siehe unten). Nach Installation der Geräte durch den Lieferanten konnte die Konfiguration der Hardware wie z.B. die Storagesysteme und SAN-Switche durch das LRZ relativ schnell bewerkstelligt werden, da fast sämtliche Systeme bzw. deren Vorgänger bereits am LRZ im Einsatz waren und dadurch das entsprechende Know- How bereits vorhanden war. Ebenso effizient konnte die Installation und Konfiguration der Software und die Provisionierung der TSM Instanzen auf den neuen Servern erfolgen, da hier mittlerweile einen sehr hohen Automatisierungsgrad durch den Einsatz von CF-Engine erreicht ist. Die Abnahme des SuperMUC Archivs begann mit einem Fehler an einem Storagecontroller, der nur durch den Tausch der sogenannten Midplane (ein Teil, an dem laut Hersteller äußert selten Defekte auftreten) behoben werden konnte. Da dieser Austausch sehr kompliziert und langwierig war, konnte die Verfügbarkeitsprüfung auf Anhieb nicht bestanden werden und musste um 11 Tage verlängert werden. Bis auf diesen Vorfall verlief die Verfügbarkeitsprüfung relativ reibungslos und ohne größere Zwischen- fälle. Während der Abnahme wurden die Archivdaten des Migrationssystems SuperMIG, sowie die Bestands- daten des Vorgängers des SuperMUC (HLRB II) in das neue Archiv verlagert sowie die Zweitkopie der Archive des HABS und des LABS auf dem Desaster Recovery System angelegt (siehe unten). Durch diese Maßnahme wurde hohe Last erzeugt, so dass die Abnahme unter realen Produktionsbedingungen stattfinden konnte.

Umzug der HABS Server in DAR1 und Zusammenschluss mit SuperMUC Archiv Anfang 2012 hätte für die 6 SGI IS4500 Storagesysteme, auf denen die TSM-Datenbanken des HABS lagen, der Wartungsvertrags verlängert werden müssen. Die Kosten für drei Jahre Wartung überstiegen die Kosten für die Ersetzung durch ein neues System inkl. drei Jahren Wartung. Deshalb wurden aus Restmitteln drei Dell PowerVault MD3620f Storagesysteme mit je 144 136TB SAS Platten als Ersatz beschafft. Zudem musste Mitte 2012 die Wartung für die alten HABS SAN Direktoren und Storageserver verlängert werden. Da dies ebenso unverhältnismäßig hohe Kosten verursacht hätte, wurde entschieden, die alte Storage-Infrastruktur (SAN und Platten) des HABS komplett abzuschalten und stattdessen die Server und die Dell-Storagesysteme mit dem SuperMUC Archiv zum HABS 2.0 zu verschmelzen. Im Rahmen der Beschaffung des SuperMUC Archivs wurden zusätzliche SAN Ports durch das LRZ gekauft, über die die HABS 1.0 Komponenten (Server, Dell Storagesysteme, Tapes) integriert wurden. Weiterhin wurde das 2011 aus Eigenmitteln finanzierte SuperMIG-Backup- und Archivsystem, bestehend aus einem IBM X3850 X5 und zwei DS3500 Storageservern mit 144 TB Kapazität in das HABS 2.0 integriert. Die Dell Storagesysteme wurden im neuen Serverraum DAR1 aufgestellt und die neue Verkabelung vorbereitet. Danach konnte der Umzug der verbliebenen HABS 1.0 Komponenten mit weniger als 8 Stunden Dienstausfallzeit bewerkstelligt werden.

Jahresbericht 2012 des Leibniz-Rechenzentrums 39

Migration der Archivkopien in das neue DRABS-System Um einen Verlust von Archivdaten im Falle eines Mediendefekts oder einer Katastrophe wie z.B. eines Brandes zu vermeiden, wird von den Archivdaten eine Zweitkopie erstellt. In der Vergangenheit wurde diese Zweitkopie auf Grund eines bilateralen Abkommens zwischen LRZ und RZG im TSM-System des RZGs gespeichert. Um mehr Unabhängigkeit bei der verwendeten Software bzw. Softwarekonfiguration zu bekommen, entschieden sich das LRZ und das RZG 2011 dafür, in Zukunft nicht mehr die Daten im TSM-System des jeweiligen Partners zu speichern, sondern im Partnerrechenzentrum eigene Hardware zu installieren. Seit 2012 betreibt das LRZ sein Desaster Reocvery-System am RZG und ab 2013 wird das RZG umgekehrt ein eigenes System am LRZ installieren. Nachdem das LRZ-eigene Desaster Recovery-System zusammen mit dem SuperMUC-Archiv im Früh- jahr 2012 installiert wurde, musste die Migration der Zweitkopie in das neue System erfolgen. Dafür mussten alle Archivdaten auf der Primärseite mit einem Gesamtumfang von etwa 6 PB erneut gelesen und per 10 Gbit Netzwerk in das neue System kopiert werden. Danach konnte die alte Zweitkopie im RZG TSM System gelöscht werden.

Einführung einer neuen Reporting-Software als Ersatz für DatWEB Ende 2012 wurde die Software TSM-Reporter als Teilersatz für das vom LRZ in den 90er Jahren selbst programmierte DatWEB eingeführt. Die neue Software stammt von der niederländischen Firma PLCS welche sich auf Produkte und Services rund um TSM spezialisiert hat. Die Software sammelt täglich wichtige Kenndaten aus der TSM Datenbank und erzeugt daraus Reports. Das ermöglicht den TSM- Administratoren Trends, die zu Engpässen führen, proaktiv zu Erkennen und frühzeitig darauf zu reagie- ren. Zudem stellt es u.a. Prognosen über das Datenwachstum an. Durch den Einsatz dieser Software konnte der benötigte Funktionsumfang eines Nachfolgersystems für DatWEB, das zwangsläufig wieder großteils eine Eigenentwicklung sein wird, deutlich verschlankt werden. Zudem ist die Weiterentwicklung und Support durch die Firma PLCS garantiert.

Neues Backupverfahren für Exchange-Server Im Rahmen einer Ausschreibung wurde 2012 eine neue Storagelösung für die Microssoft Exchange- Umgebung des LRZ beschafft. Das alte System, basierend auf virtuellen Servern, stützte sich auf die NAS-Speicher von NetApp und konnte die inhärenten Exchange Features zur Erhöhung von Redundanz und Sicherheit nicht nutzen, jedenfalls nicht zu vertretbaren Kosten. Das neue System besteht aus physischen Servern mit Direct Attached Storage. Ein neues, effizientes Backupverfahren wurde aufgesetzt, das die im Rahmen des Tivoli Landeslizenzvertrags vorhandenen Lizenzen nutzt. Mit TSM for Mail ist es möglich, die Exchangedatenbanken im laufenden Betrieb in TSM zu sichern. Um einen schnellen Restore zu gewährleisten, werden die Daten nicht nur auf Band, sondern auch auf Festplatten in TSM gespeichert. Damit sich der benötigte Festplattenplatz aber auf ein Mindestmaß beschränkt, wurde hier zusätzlich noch die Deduplizierungsfunktion von TSM eingesetzt. Dadurch konnte der tatsächlich belegte Platz auf den Storagesystemen um 75% reduziert werden. Um höchste Datensicherheit des Backups zu gewährleisten, wird zusätzlich eine Kopie auf Band im neuen DRABS am RZG gespeichert.

Tivoli Landeslizenzvetrag LL3 Der im September 2008 abgeschlossene Landeslizenzvertrag für IBM-Softwareprodukte, mit dem auch die TSM-Lizenzen und Support beschafft wurden, wird im September 2013 auslaufen. Im Herbst 2012 wurden in einem ersten, konkret diesem Zweck gewidmeten Treffen, der Bedarf und die Möglichkeiten für einen weiteren Nachfolgevertrag mit den interessierten bayerischen Hochschulrechen- zentren und IBM diskutiert. Danach wurde der aktuelle Bestand erfasst und basierend auf den Erfahrun- gen der vergangenen Jahre eine detaillierte Trendanalyse für den zu erwartenden Fünfjahresbedarf erstellt. Erwartungsgemäß konzentrierten sich die Anforderungen auf die Tivoli-Produktsuite, durch die die Be- reiche Speicher-, Netz- oder Systemmanagement abgedeckt werden. Hier ist die landesweite Synergie am größten. Die Hinzunahme von anderen Produkten hat sich nur bedingt bewährt, da sich IBM nicht dazu bewegen ließ, diese Produkte in der gleichen sogenannten Austauschkategorie zu platzieren und der Be- darf nicht groß war. Dadurch ging viel an Flexibilität verloren. Die Universität Regensburg war zum Bei-

40 Datenhaltung spiel der einzige Nutzer von Informix-Lizenzen. Die Hochschule wird nun die Lizenzen in Eigenregie verlängern, das Produkt wird aber nicht Bestandteil eines neuen Landeslizenzvertrags. Anhand der Be- darfsmeldungen der Hochschulen von Ende 2012 wurde von IBM ein Informationsangebot erstellt, das Grundlage für einen Großgeräteantrag (LL3) werden wird, der Anfang 2013 vorbehaltlich einer gesicher- ten Finanzierung gestellt werden soll.

4.2.3 Statistik

Ende 2012 waren in den

5 Libraries des Archiv- und Backupsystems 28 Petabyte, verteilt auf 14 Milliarden Dateien gespeichert. Täglich wurden auf die Systeme durchschnittlich 70 Terabyte neu geschrieben. Die Daten stammten von rund 8.000 Servern des MWN aus über 400 Einrichtungen der Münchner Hochschulen.

Im Vergleich zum Vorjahr sind Last und Datenmenge im Rahmen der Erwartungen, d.h. nicht schneller als in den Vorjahren, weiter gestiegen. Es bleibt abzuwarten, ob sich dieser Trend fortsetzt, oder ob die Archivdaten des SuperMUC das Wachstum wieder beschleunigen. Hauptsächlich bedingt durch die 11.000 Kassetten, die Teil der Beschaffung des SuperMUC Backup- und Archivsystems waren, ist die Anzahl der in den Libraries nutzbaren Kassetten stark gestiegen. Ende 2012 befanden sich 37.500 Kassetten in den Slots der 5 Libraries. 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. 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. 2012 wurden 1.400 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 ge- sorgt, 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 Ba- ckupsystems den Umfang ihrer abgelegten Daten immer wieder bewusst zu machen und sie zum sinnvol- len Umgang mit den vom LRZ zur Verfügung gestellten – für sie vorläufig noch kostenlosen – Ressour- cen 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äßi- gen Abständen von diesem Server über die von ihnen verbrauchten Speicherressourcen via E-Mail informiert. Integriert sind Werkzeuge, die der betrieblichen Überwachung und Analyse der Systeme dienen. Nutzer mit besonders auffälligem Datenprofil werden direkt angesprochen. Unter anderem um diese auf- fälligen Profile schnell zu erfassen wurde 2012 die Software TSM-Reporter beschafft (siehe Abschnitt 4.2.2). Alle Kontaktdaten werden zusätzlich regelmäßig auf ihre Aktualität überprüft. Entsprechend den Benut- zungsrichtlinien werden Daten, zu denen sich keine Ansprechpartner mehr ermitteln lassen, nach Ablauf einer festgelegten Frist gelöscht. Den Zuwachs von Speicherbelegung und Dateneingang im Laufe des Jahres 2012 zeigen Abbildung 19 und 20.

Jahresbericht 2012 des Leibniz-Rechenzentrums 41

Abbildung 19 Datenverkehr (GB pro Monat)

Abbildung 20 Datenumfang in TB

Der Archiv-Anteil am Datenbestand ist relativ statisch, d.h. es gibt nur wenige Änderungen an den Datei- en im Archiv. Archivdaten werden in der Regel einmal ins Archiv übertragen und dort sehr lange aufbe- wahrt, im Fall der Langzeitarchivierung für Jahrzehnte. Der „Buckel“ der Archivkurve im Zeitraum Sep- tember bis Dezember wurde durch den Aufbau der Zweitkopie im neuen Desaster Recovery Archiv- und Backupsystem verursacht. Hier gab es vorübergehend drei Kopien der Archivdaten (eine im LRZ, eine im TSM System des RZGs und eine im LRZ System am RZG), wobei die dritte Kopie im TSM System des RZGs nach dem erfolgreichen Verschieben in das DR System gelöscht wurde. Datensicherungen finden regelmäßig statt. Backupdaten werden daher häufig ins System geschrieben. Die veralteten Backup-Daten werden automatisch aus dem Bestand gelöscht. Durch diese Dynamik erklärt sich die im Vergleich zur Archivierung deutlich höhere Dateneingangsrate bei geringerer Steigerung des Datenumfangs. Die Entwicklung seit der Installation des ersten unabhängigen Archiv- und Backupsystems im Jahr 1995 zeigt Abbildung 21. Das Diagramm zeigt ein kontinuierliches exponentielles Wachstum des Datenbe- stands über die Jahre hinweg.

42 Datenhaltung

Abbildung 21 Speicherbelegung 1995 - 2012

4.2.4 Plattform 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 Daten- träger. 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), die BSB-Google Partnerschaft und die Einführung des LZA-Managementsystems Rosetta der Firma Ex Libris an der BSB ausgeweitet wurde. Dabei tritt das LRZ für die BSB als Dienstleister für die Langzeit- archivierung, das Bereitstellen von Online-Speicher, das Attended Housing von Clusterknoten und Hosting von virtuellen Servern auf. Die langfristige Speicherung der Daten übernimmt bei allen Projekten ein NAS-System und das Archiv- und Backupsystem des LRZ mit dem Softwarepaket Tivoli Storage Manager (TSM). TSM verfügt über alle wesentlichen Funktionalitäten, die für Langzeitarchivsysteme Voraussetzung sind. Das Gesamtsystem deckt damit alle wichtigen Bereiche eines langfristig funktionie- renden Archivs ab und folgt dem allgemeinen „Open Archival Information Systems“-Referenzmodell (OAIS). Abbildung 22 und 23 zeigen die Entwicklung der Anzahl der Archivobjekte und des Datenvolumens des Langzeitarchivs von Januar 2006 bis Januar 2013. Der starke Anstieg der Dateianzahl ab März 2009 ist durch den Produktivbeginn der Archivierung der Google-Digitalisate (siehe Abschnitt 4.2.6) zu erklären. Bisher wurden von der BSB mehr als 975 Millionen Objekte mit einem Datenvolumen von mehr als 459 TB am LRZ archiviert. Der Datenzuwachs im Jahr 2012 betrug ca. 210 Mio. Dateien mit einem Volumen von ca. 76 TB. Noch im ersten Quartal 2013 wird die Anzahl der Objekte die Schwelle von 1 Milliarde Datengrenze überschreiten. In Abbildung 23 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 Sicherheits- gründen erstellte Zweitkopie auf einem weiteren Magnetband verdoppelt in der Praxis die Objektanzahl und das Datenvolumen. Sie ist in den Diagrammen nicht berücksichtigt.

Jahresbericht 2012 des Leibniz-Rechenzentrums 43

Abbildung 22 Objektanzahl im LRZ-Archiv

Abbildung 23 Datenvolumen im LRZ-Archiv

Die gespeicherten Daten werden auf Systemen aufbereitet, archiviert und als Webpräsenz bereitgestellt, die zum überwiegenden Teil auf der virtuellen Serverplattform des LRZ betrieben werden. Zu diesen Systemen gehören unter anderem die Verkündungsplattform Bayern, der Web Server der Bayerischen Landesbibliothek oder ein Server, der die Volltextindizierung der Digitalisate steuert, um nur einige Bei- spiele zu nennen. Die Anzahl dieser am LRZ für das Münchner Digitalisierungszetrum der Staatsbiblio- thek gehosteten virtuellen Linux-Server ist im Jahr 2012 von 40 auf 76 angewachsen. Im Folgenden werden die beiden aktuell prominentesten Projekte beschrieben. Auf der LRZ-Homepage im Bereich Projekte (http://www.lrz.de/projekte_2012/forschung-daten/) finden sich weitere Details zu diesem Thema.

4.2.5 Projekt Rosetta Im Frühjahr 2010 hat sich die BSB für die Einführung des Langzeitarchivsystems Rosetta der Firma Ex Libris als neue strategische Plattform für die Langzeitarchivierung in Bayern entschieden. Diese Ent- scheidung wurde auch dadurch beeinflusst, dass das bislang verwendete System Digitool der Firma Ex Libris nicht mehr weiterentwickelt wird. Eine wesentliche Anforderung an das neue Langzeitarchivsys- tem Rosetta war der Anspruch, dass pro Tag mindestens 1.000 Bücher in das System eingefügt werden können. Dies entspricht einem geschätzten Zuwachs des Datenvolumens von 100 TB pro Jahr. Mittelfris-

44 Datenhaltung tig ist geplant den bisher archivierten Datenbestand (459 TB; 975 Mio. Dateien) nach Rosetta zu migrieren. Gegenüber der bisherigen Konfiguration werden neben den Bereitstellungsdaten auch die digitalen Masterdateien auf einem Online-Speichersystem vorgehalten. Diese ambitionierten Pläne haben dazu beigetragen, dass der bestehende Online-Speicher (NAS-System) der BSB im Oktober 2010 durch ein performanteres und skalierbareres NAS-System ersetzt wurde. Die Bruttokapazität des NAS-Filers wurde von 586 TB auf 730 TB erweitert. Das LRZ betreibt für die BSB die Systeminfrastruktur des Langzeitar- chivsystems Rosetta (virtuelle Server, Online-Speicher und Archivspeicher).

Abbildung 24 Rosetta-Speicherarchitektur

Das Hauptaugenmerk des LRZ bezüglich Rosetta im Jahr 2012 galt der weiteren Verfeinerung des Spei- cherkonzeptes und der Umsetzung der Langzeitsicherungsaufgaben. Seitens Ex Libris wurden neben der funktionalen Systemerweiterung und Fehlerbehebung zahlreiche Versuche unternommen, die geforderte Tagesproduktion von 1.000 Büchern zu erreichen, was bisher noch nicht gelungen ist. Aufgrund von wie- derholten Verzögerungen seitens Ex Libris erfolgte der Produktivgang erst im Sommer 2012 mit ausge- wählten Kollektionen.

4.2.6 Projekt Google Im Rahmen einer im Jahr 2007 entstandenen Public-Private-Partnership digitalisiert Google über einen Zeitraum von mehreren Jahren mehr als 1 Million urheberrechtsfreie Druckwerke aus dem Bestand der BSB. Die BSB erhält Kopien der Digitalisate, die am LRZ gespeichert, archiviert und über den OPAC der BSB weltweit zugänglich gemacht werden. Das LRZ unterstützt die BSB in diesem Projekt als Dienstleis- ter und ist für die Langzeitarchivierung der Digitalisate, das Housing von Clusterknoten für die Format- migration 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 als interne und externe Schnittstelle virtuelle Server bereit, die sich um den Down- load, die Verarbeitung, Archivierung und Bereitstellung der Daten im Internet kümmern. Die Originalda- teien, die die BSB von Google erhält, werden im Archiv- und Backupsystem des LRZ abgelegt. Die Da- teien, die im Internet angeboten werden, werden am LRZ auf einem NAS-System gehostet. Die Umwand-

Jahresbericht 2012 des Leibniz-Rechenzentrums 45 lung aller originalen Bilddateien in jeweils zwei Bilddateien mit niedriger Auflösung geschieht am LRZ auf dem Linux Cluster. In Abbildung 25 sind die Infrastruktur sowie der Workflow schematisch dargestellt.

Abbildung 25 Workflow im Google Projekt

Aufgrund der guten Erfahrungen mit der Formatkonvertierung auf dem Linux-Cluster im Google-Projekt wurde für ein weiteres Projekt der BSB die Konvertierung von hochauflösenden TIFF-Bildern in zwei niedriger auflösenden JPEG-Formaten auf dem Linux-Cluster produktiv genommen. Weiterhin wurden 2012 die Konvertierungsroutinen auf das neue Batch-Processing System SLURM (früher SGE) umgestellt. Bis Ende 2012 wurden rund 840.000 Bücher heruntergeladen und verarbeitet, der Bestand an Ar- chivdaten im Google-Projekt ist so auf fast 160 TB angewachsen. Der stagnierende Datenzuwachs im Zeitraum von Februar 2011 bis Juli 2011 wurde dadurch verursacht, dass primär keine neuen Digitalisate in das Archiv eingepflegt, sondern eine Vielzahl an Objekten im Archiv durch überarbeitete und verbes- serte Versionen (z.B. Bildqualität und OCR) ausgetauscht wurde.

Abbildung 26 Archivierte Daten in TB

46 Datenhaltung

Ab dem Jahr 2012 steht ein Teil der digitalisierten Bücher auch als Farb-Image zur Verfügung. Für diese Exemplare verdoppelt sich der Speicherbedarf und es ist notwendig, diese Bücher erneut von Google zu holen und in den Langzeitarchivierungsprozess einzupflegen.

4.3 Datenbanken und Web-Schnittstellen für den Betrieb der Supercom- puter am LRZ Beim Betrieb der Hochleistungsrechner (Früher SGI, jetzt SuperMIC und SuperMUC) und des VMware- Clusters fallen große Mengen Leistungs- und Abrechungsdaten an, die intern ausgewertet und teilweise auch den Nutzern zur Verfügung gestellt werden. Die zur Auswertung allein nur für diese beiden Berei- che bereitgestellte Datenbankinfrastruktur umfasst derzeit 8 eigene Datenbankserver für HPC und einen für das VMware-Cluster. Die Arbeiten daran beinhalten den Aufbau sowie die laufende Pflege dieser Datenbanksysteme sowie den hausinternen Support bei Fragen und Problemen mit den darauf laufenden Anwendungen. Vier der Datenbankserver sind im aktuellen Jahr neu hinzugekommen, also eine Verdopp- lung der benötigten Infrastruktur. Zur Darstellung von Übersichten wie Statistiken und Betriebszustandsdaten wurden Schnittstellen zum Content-Management-System Fiona des LRZ-Webservers geschaffen, die es erlauben, diese Daten auch über den Webserver des LRZ abzurufen.

4.4 Online-Speicher

4.4.1 Konfiguration und Entwicklung im Überblick 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 be- währt und als strategische Plattform etabliert. Die rapide wachsenden Datenmengen erfordern die gute Skalierbarkeit der eingesetzten Systeme. Abbildung 27 zeigt die Entwicklung der am LRZ betriebenen NAS-Infrastruktur seit ihrer Einführung im Jahr 2005.

Abbildung 27 Links: Entwicklung Datenvolumen und Anzahl Festplatten in den Jahren 2005 bis 2012 Rechts: Entwicklung der Anzahl an Filer-Köpfen (Storage Controller)

In der linken Abbildung ist Ende 2011 ein sehr deutlicher Zuwachs zu erkennen. Diese Steigerung wird durch die Inbetriebnahme des Speichersystems der Home-Verzeichnisse des SuperMUC bedingt. Die NAS-Datenkapazität steigt um einen Faktor 4,5 von 2.000 TB auf über 9.000 TB an. Die Anzahl der Festplatten wachsen um einen Faktor 2 auf 6.000. Im Jahr 2005 betrug das Bruttospeichervolumen der gesamten NAS-Infrastruktur überschaubare 54 TB (ca. 350 Festplatten). Die Anzahl an Filer-Köpfen (Storage Controller) ist im Zeitraum von 2005 bis 2012 von 5 auf 42 Filer-Köpfe angestiegen (Steige- rungsfaktor: 10,5). Das Personal zur Betreuung der NAS-Systeme ist im gleichen Zeitraum nur um einen Faktor 1,5 bis 2 gestiegen. Abbildung 28 zeigt die Konfiguration der Speicherinfrastruktur aller Primärspeichersysteme (Produk- tivsysteme) inklusive der Replikations- und Backupsysteme. Zwischen Primär- und Replikationsspeicher-

Jahresbericht 2012 des Leibniz-Rechenzentrums 47 systemen werden die Daten in der Regel asynchron, im VMware-Umfeld, wo die Verfügbarkeit eine besonders große Rolle spielt, werden die Daten synchron gespiegelt. Zur weiteren Erhöhung der Datensi- cherheit werden die Daten von den Replikationssystemen zusätzlich über NDMP (Network Data Ma- nagement Protocol) auf Magnetbänder gesichert. Die Primär- und Replikationssysteme befinden sich in getrennten Brandabschnitten des Rechnergebäudes.

Abbildung 28 Primärsysteme, Replikation und Backup

Ein Cluster von Filerköpfen (supernasNN rechts in Abbildung 28) liefert den Speicher für die Homever- zeichnisse der Nutzer des neuen Höchstleistungsrechners. Das Cluster besteht aus 12 Storage-Controllern (FAS 6820) der Firma NetApp und verfügt in der ersten Ausbaustufe über ein Speichervolumen von brut- to 3.456 TB. Das zugehörige Replikationssystem (nasrepNN) verfügt über 4 Storage Controllern (FAS 6820), denen eine Kapazität von 1.536 TB Brutto zur Verfügung steht.

4.4.2 Hochverfügbarer Speicher für virtuelle Server Um die notwendige hohe Verfügbarkeit bei der Speicherversorgung der VMware-Infrastruktur zu erreichen, wird ein Speichersystem eingesetzt, das seine Daten synchron spiegelt und zusätzlich repliziert (nas3170a/b). Als nutzbarer Speicherplatz standen VMware seit Frühjahr 2010 ca. 55 TB zur Verfügung. In einem Speicherantrag, der im Frühjahr 2011 eingereicht wurde, wurde mindestens eine Verdopplung der aktuellen Speicherkapazität dieses System angestrebt, um der steigenden Zahl an virtuellen Maschi- nen gerecht zu werden. Die Beschaffung der Speichererweiterung erfolgte im Frühjahr 2012. Der virtuellen Infrastruktur steht seitdem ca. 150 TB nutzbarer Speicherplatz zur Verfügung. Das in die Jahre gekommene Replikationssystem (nas6070r), das ursprünglich für den MWN-Speicher beschafft wurde und übergangsweise auch für das hochverfügbare VMware-Speichersystem gedient hat, wurde durch ein neues System (nas6280r2) ersetzt. Dabei wurde zunächst ein zusätzlicher Spiegel aufgebaut und im An- schluss der alte Replikationsdatenbestand gelöscht. Abbildung 29 zeigt das hochverfügbare NAS-System inkl. Replikations- und Backupsystem, das in räumlich getrennten Brandabschnitten aufgebaut und installiert wurde.

Im Rahmen des Hostings für das Dialogorientierte Serviceverfahren der Stiftung für Hochschulzulassung ist eine analog aufgebaute Konfiguration (2 x NetApp FAS 3170, 50 TB) mit synchroner Spiegelung in Betrieb.

48 Datenhaltung

Abbildung 29 Hochverfügbares NAS-System für VMware inkl. Replikation und Backup

4.4.3 MWN-Speicher Das LRZ bemüht sich um die Bereitstellung von Speicherkapazitäten für alle Studierenden und Mitarbei- ter der Hochschulen und stellt seit Mitte 2008 eine einfach zu bedienende, sichere und zentral admi- nistrierte Speicherlösung bereit. Durch eine enge Kopplung mit Verzeichnisdiensten verfügen alle Mitar- beiter und Studierenden sowohl über persönlichen Speicherplatz als auch über den Zugang zu Projektab- lagen. 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. Der sogenannte Speicher für die Wissenschaft oder MWN-Speicher wird – vor allem von Seiten der TU München - sehr gut angenommen, was die stetig steigende Anzahl der eindeutigen Benutzer-Kennungen (ohne Funk- tions- und lokale Benutzerkennungen) mit simultanen Zugriffen zeigt (siehe Abbildung 30). Die Zugriffe haben sich innerhalb der letzten beiden Jahre (2011/12) von 1.100 auf 2.800 simultane Zugriffe fast ver- dreifacht. Deutlich zu erkennen sind in den Diagrammen die betriebsschwachen Zeiten an den Wochen- enden und zwischen Weihnachten und Neujahr.

Wegen des schnellen Wachstums mussten die Daten des Speichers für die Wissenschaft auf ein neues Speichersystem verlagert werden. Dabei war die Herausforderung, die Unterbrechung für die Kunden möglichst gering zu halten. Deshalb fand die Verlagerung an einem Feiertag im August statt. Die Daten wurden bereits im Vorfeld im Hintergrund periodisch auf das neue Speichersystem gespiegelt. Am Um- schalttag wurde der letzte Abgleich durchgeführt und die Konfiguration des neuen Speicherbereiches angepasst. Auch das Replikationssystem wurde durch ein neues System ersetzt. Nach dem Datenumzug des Primärsystems wurde der asynchrone Spiegel neu aufgebaut.

Jahresbericht 2012 des Leibniz-Rechenzentrums 49

Abbildung 30 Durchschnittliche Anzahl simultan zugreifender Kennungen

Abbildung 31 Infrastruktur des Speichers für die Wissenschaft

Abbildung 31 zeigt die Zugriffswege und den strukturellen Aufbau des MWN-Speichers. Hauptnutzer des MWN-Speichers war auch 2012 die TU München. Aber auch die LMU nutzt zunehmend den MWN-Speicher, wenn auch noch nicht in dem Maße wie die TUM. Die organisationsübergreifende Bereitstellung von Speicherplatz ist eine Herausforderung, die weit über die Grenzen des MWNs hinaus- geht. In einigen Bundesländern wird bereits landesweit Speicher bereitgestellt. Gemeinsam mit dem DFN wurde 2012 über einen föderierten Dienst nachgedacht, der bundesweit genutzt werden kann. Die Diskus- sion, an der sich das LRZ im Rahmen seiner Möglichkeiten beteiligt, wird 2013 fortgesetzt.

50 Datenhaltung

4.4.4 Sonstige Aktivitäten

Hochleistungs-NAS-Systeme für HPC-Anwendungen Im Juni 2012 wurden die Homeverzeichnisse des SuperMUC und die Bereiche SCRATCH und WORK vom temporären Speicherort auf dem Replikationssystem auf das Hauptsystem verlagert. Abbildung 28 (rechte Seite) zeigt die schematische Konfiguration, bestehend aus 12 Filerköpfen für das Primärsystem und 4 Filerköpfen für das Replikationssystem. Leider hat sich gezeigt, dass die neue Controller-Generation von NetApp (FAS 6280) aufgrund eines Hardware-Problems häufiger ohne Vorwarnung abstürzen, bzw. einfrieren. Aufgrund des Hardware- Defektes mussten bei allen 20 Controllern die Mainboards, Erweiterungsboard, SAS-HBAs und NV- RAM-Karten getauscht werden. Auch die Stabilität der neusten Software-Version der NetApp Cluster Mode System ließ anfänglich zu wünschen übrig. Diese Instabilitäten haben in der zweiten Jahreshälfte erhebliche Personalressourcen gebunden und konnten erst im Januar 2013 endgültig behoben werden. Das Linux-Compute-Cluster des LRZ verfügt über ein NAS-Speichersystem mit 300 TB Kapazität. Auf- grund der gestiegenen Performance- und Kapazitätsanforderungen wurde entschieden, die Daten auf das neue Speichersystem für den SuperMUC zu konsolidieren. Die Planungen und Vorbereitungen dazu fanden Ende 2012 statt, die Datenmigration der 250 TB ist für Januar 2013 geplant. Das alte Speichersys- tem soll noch bis Ende März 2013 parallel betrieben werden, um gegebenenfalls auf Daten noch zugreifen zu können. Danach wird das System abgeschaltet und evtl. anderweitig verwendet.

Konsolidierung verschiedener Speicherbereiche Da das 2007 beschaffte Speichersystem, bestehend aus einem Primärspeichersystem (2 x FAS6070) und einem Replikationssystem (FAS6070) zum Jahreswechsel außer Dienst gestellt werden sollte, mussten die Daten verschiedener Dienste, wie z.B. Exchange, VMware-Testumgebung und die Fakultät 11 der LMU verlagert werden. Bei dieser Gelegenheit wurden die Daten der Fakultät 11 der LMU, welche als Pilotkunde einen eigenen, gesonderten Speicherbereich hatte, in den Speicher für die Wissenschaft integriert.

Speicher für NFS-Dateidienste und Linux-Mailsysteme Die in die Jahre gekommene Speichersysteme für die NFS-Dateidienste und der Linux-Mailsysteme wurden durch neue Speichersysteme ersetzt. Diese Geräte sind Systeme der ersten Stunde im damaligen Neu- bau in Garching. Im Zeitraum von August bis September 2012 wurden daher die Speicherbereiche schrittweise auf das neue Speichersystem (nas6280b) verlagert. Aufgrund der Individualität der Speicher- bereiche musste die Verlagerung schrittweise mit den Dienste-Administratoren geplant und durchgeführt werden. Diese individuelle Betreuung hat einen hohen zeitlichen Aufwand bedeutet. Nach gründlicher Vorplanung verlief die Verlagerung der Speicherbereiche für die NFS-Dateidienste und der Linux- Mailsysteme problemlos. Es gab jeweils eine kurze Diensteunterbrechung von ca. 2 – 5 Minuten. Nach der Verlagerung der Daten wurde die asynchrone Spiegelung auf ein ebenfalls neues Replikationssystem aufgesetzt. Die alten Speichersysteme nas3050a, nas3050b und das angebundene Replikationssystem r200 wurden im Oktober außer Dienst gestellt und abgeschaltet. Insgesamt war das Jahr 2012 geprägt durch zahlreiche aufwändige Datenverlagerungen, die sowohl wäh- rend der Planung, als auch bei der Durchführung einen hohen personellen Einsatz erforderten. Ein Groß- teil der in diesem Abschnitt beschriebenen Aktivitäten handelt von diesen Verlagerungen. Die raschen Innovationszyklen in der IT und die damit bedingten häufigen Ersetzungen der Hardware wirken sich hier besonders stark aus. Anders als bei der Ersetzung eines Rechners oder Rechner-Clusters kann das zu er- setzende Speichersystem erst abgeschaltet werden, wenn alle Daten, die darauf gespeichert waren, verlagert worden sind. Die Verlagerung dieser Daten verursacht immer wieder erheblichen Aufwand und zieht sich durch die gesamte Geschichte seit Einführung der unabhängigen Datenhaltung Anfang der Neunziger Jahre. Auch der nächste Abschnitt ist dafür ein gutes Beispiel.

AFS Seit 1992 wurde am LRZ das verteilte Filesystem AFS (Andrew Filesystem) eingesetzt. AFS war in den 90er Jahren das zentrale Filesystem am LRZ, das von allen Diensten genutzt wurde. Im Rahmen des TUM-Großprojekts IntegraTUM wurden auch die Alternativen für ein hochschulübergreifendes hochver-

Jahresbericht 2012 des Leibniz-Rechenzentrums 51 fügbares Filesystem evaluiert. Bereits 2005 fiel dann die Entscheidung zu Gunsten einer NAS-basierten Lösung. Seitdem wird an der Ablösung von AFS gearbeitet. Die tiefe Verwurzelung von AFS in zahlreiche Teilbereiche des LRZ-Dienstespektrums machte die Ablösung zu einem langwierigen Unternehmen, das bis heute noch nicht gänzlich abgeschlossen ist. Nach und nach wurden die Speicherbereiche verschiedener Dienste aus AFS herausgelöst, zunächst der Mailbereich, der am wenigsten mit der speziellen Filesystemarchitektur von AFS zurechtkam, dann die Daten der Compute-Cluster. Mitte 2010 fand eine große Bereinigungsaktion nicht mehr oder kaum genutzter AFS-Homeverzeichnisse und damit gekoppelt der AFS-Kennungen statt. Dadurch konnte die Anzahl der AFS-Kennungen von vormals über 30.000 auf 2.300 reduziert werden. Mit der Einstellung des Betriebs des öffentlichen und internen SUN-Cluster sind die Restdaten in AFS nur noch über einen speziellen FTP-Zugang erreichbar. 2012 konzentrierten sich die Migrationsarbeiten auf die Verlagerung der Web-Bereiche nach NAS. Die Vorarbeiten dazu stellten sich einmal mehr als sehr zeitaufwändig heraus. Die Verlagerung der letzten 300 Webserver wird erst 2013 abgeschlossen werden können. Bemerkenswert ist in diesem Zusammenhang auch die Stabilität des Systems. Natürlicherweise steigt die Stabilität zwar mit dem Rückgang der Nutzung, trotzdem ist es nicht selbstverständlich, dass die teilweise 10 Jahre alte Hardware noch ohne größere Ausfälle funktioniert. Auch wird die komplexe Software, die zum Betrieb von AFS nötig ist, seit dem Weggang des letzten AFS-Administrators Mitte 2012 nicht mehr gepflegt.

Diverse Stromabschaltungen Für die gesetzlich vorgeschriebene Sachverständigenprüfung der LRZ-Brandmeldesysteme und Brand- meldebekämpfungssysteme im Rechnergebäude mussten mehrere Rechnerräume stromlos geschaltet werden. Um den Betrieb der Speichersysteme auch während der Stromabschaltung aufrecht zu erhalten mussten mit hohem Aufwand die Systeme über eine provisorische Stromversorgung betrieben werden. Eine zusätzliche Stromabschaltung musste aufgrund defekter Abgangskästen und Formstücke der Strom- schiene im DAR1 durchgeführt werden. Auch hier wurde der Betrieb der Speichersysteme nicht unter- brochen. Die Sicherstellung des unterbrechungsfreien Betriebs während dieser Maßnahmen band zusätz- liche Personalressourcen ebenso wie die schon beschriebenen Instabilitäten und Hardware-Probleme. Diese Herausforderungen mussten zusätzlich zu den normalen Tagesaufgaben bewältigt werden. Die Belastung für die Mitarbeiter war während des ganzen Jahres enorm hoch.

4.5 Daten- und Archivräume Im Rechnerwürfel des LRZ steht für die Geräte des Archiv- und Backupbereichs nahezu ein gesamtes Stockwerk des Altbaus mit 560 m2 Nutzfläche zur Verfügung, der sogenannte DAR0 (Daten- und Archiv- Raum). Der Raum würde, wie alle anderen Brandabschnitte in diesem Stockwerk auch, im Brandfall mit Argon geflutet werden, d.h. Daten und Geräte würden keinen Schaden nehmen. Die sicherheitstechni- schen und klimatischen Randbedingungen sind im Prinzip gut geeignet für die langfristige, sichere Auf- bewahrung großer Datenmengen. Die Dimensionierung erlaubte bisher eine optimale Aufstellung der Geräte. Den meisten Raum nehmen 5 Bandbibliotheken ein. Neben den Bandbibliotheken wird der Raum allerdings zunehmend für die Aufstellung der umfangreichen NAS-Plattenbasis (Replikatsysteme) genutzt. Anders als leistungsstarke Server haben Platten eine relativ geringe Leistungsaufnahme. Die durch die Platten verursachte Wärmeentwicklung und damit Änderung der klimatischen Verhältnisse im Ar- chivraum wird als vertretbar erachtet. Wie an vielen anderen Stellen auch, musste hier ein vernünftiger Kompromiss zwischen Kosten und Nutzen gefunden werden. Mit einer durchschnittlichen Leistungsaufnahme von unter 60 KW ist der Raum DAR0 ein Aushänge- schild für Green-IT. Der geringe Energiebedarf ist darauf zurückzuführen, dass in dem Raum primär Bandbibliotheken und Plattensysteme stehen, deren Stromverbrauch verglichen mit den energiehungrigen Prozessoren der Serverracks in den anderen Räumen sehr gering ist.

52 Datenhaltung

Abbildung 32 Daten- und Archivraum

DAR = DAR0 +DAR1 + DAR2 Diese Gleichung steht für die substantielle Erweiterung des Daten- und Archivraums im Zuge der Erwei- terung des Rechnergebäudes. Während der „alte“, 2006 in Betrieb genommene DAR0 und der neue DAR2 primär für die Archiv- und Backupsysteme vorgesehen sind, wird der sogenannte DAR1 neben hochverfügbaren Plattenspeichern auch hochverfügbare Server beherbergen. In diesem Raum wurden über 50 Geräteschränke zur Trennung von kalter und warmer Luft speziell „eingehaust“. Die Trennung der Luftströme erhöht die Energieeffizienz der Klimatisierung erheblich. Hochverfügbarkeit geht oft einher mit Hochsicherheit. Künftig soll daher der DAR1 als getrennte Sicherheitszone mit eigener Schließ- berechtigung betrieben werden.

Abbildung 33 Brandabschnitte im Rechnerwürfel

Durch die Gebäuderweiterung wurde auch die Anzahl der Brandabschnitte insgesamt erhöht. Dadurch wurde es möglich, die Komponenten vieler wichtiger Dienste redundant aufzustellen, was vorher nicht immer möglich war. Hochverfügbare Datenspeicher konnten so auf die Räume verteilt werden, dass der Dienst, für den sie benötigt werden, bei Abschaltung kompletter Brandabschnitte nicht beeinträchtigt wird. Bei der Aufstellungsplanung wurden dabei noch weitere Faktoren berücksichtigt, wie eine redundante Einbindung in die Klimainfrastruktur oder eine unterbrechungsfreie Stromversorgung (grüne Berei- che in Abbildung 33).

Jahresbericht 2012 des Leibniz-Rechenzentrums 53

5 Internetdienste

5.1 E-Mail

5.1.1 Ersatz des Dienstes Mailout durch Postout Anfang August wurde ein neuer Dienst zum Versenden von Mails für den Benutzerbetrieb freigegeben. Im Unterschied zum bisherigen Mailout-Dienst können Mails beim neuen Postout-Dienst nur nach vorhe- riger Authentifizierung und nur mit Absenderadressen, für die der jeweilige Nutzer nutzungsberechtigt ist, verschickt werden. Der neue Dienst ist dadurch wesentlich besser gegen missbräuchliche Nutzung (wie Versand von Spammails) abgesichert. Ein weiterer Vorteil gegenüber dem Mailout-Dienst ist, dass er weltweit nutzbar ist und nicht nur innerhalb des MWN bzw. nach Aufbau einer entsprechenden VPN- Verbindung – eine Einschränkung, die insbesondere für die Nutzer von mobilen Geräten unbequem war. Der bisherige Mailout-Dienst wird noch für eine gewisse Übergangszeit parallel zum neuen Postout- Dienst verfügbar bleiben. Mittelfristig wird Mailout in etwas veränderter Form nur noch für lokale Mailserver im MWN, aber nicht mehr für einzelne Benutzer angeboten werden.

5.1.2 Neuer Webmailer Roundcube Grund für den Wechsel auf einen neuen Webmailer war, dass das bisher eingesetzte Produkt SquirrelMail nicht mehr in ausreichender Weise weiterentwickelt wurde. Nach Sondierung der verfügbaren (freien) Alternativen haben wir uns für Roundcube als neuen Webmailer entschieden, ein gut gepflegtes Produkt mit einer modernen, intuitiv zu bedienenden Benutzeroberfläche. Der Roundcube-Betrieb wurde Anfang Mai aufgenommen und nach einem zweimonatigen Parallelbetrieb mit SquirrelMail, während dem sich die Benutzer an die neue Umgebung gewöhnen konnten, wurde der alte Webmailer Anfang Juli abgeschaltet. Mit Roundcube ist es jetzt auch möglich server-side Filter anzulegen. D.h. E-Mails können direkt bei der Auslieferung in die Mailbox gefiltert werden, ohne dass ein Client aktiv werden muss. Dadurch können entsprechend markierte Spammails unmittelbar in den Spamordner verschoben werden. Spammails, die nicht als solche markiert wurden und sich daher weiterhin im Posteingang befinden, kön- nen mit dem Spam-Button verschoben und gleichzeitig ans LRZ gemeldet werden. Diese E-Mails werden dann vom LRZ untersucht und dienen der Optimierung der Spamabwehr.

5.1.3 Spezielle Markierung von Newslettern Der neue Spam-Button von Roundcube wird von den Nutzern fleißig betätigt. Es zeigte sich dabei aber, dass  oft korrekt markierte Spammails gemeldet wurden (d.h., es wurde vom Nutzer kein Spamfilter konfiguriert, der die E-Mails direkt in den Spamordner befördert),  die meisten gemeldeten E-Mails (> 90%) sich als Newsletter herausstellten,  nur sehr wenige E-Mails nicht ausreichend als Spam markiert wurden. Um die Masse der gemeldeten E-Mails zu ordnen, wurde ein neues Verfahren zur Markierung der Newsletter begonnen. Bei den meisten Newslettern handelt es sich nicht um solche, die der Nutzer explizit abonniert hat, sondern um Werbung von Firmen (E-Mail-Marketing). Landet ein Nutzer in der Daten- bank einer solchen Marketingfirma, erhält er oft eine Vielzahl an Newslettern. Wir haben nun die IP- Adressbereiche von inzwischen 75 Marketingfirmen ermittelt und markieren ihre Newsletter beim Emp- fang aus dem Internet mit einer extra Headerzeile „X-Newsletter-ISP: name“ anhand dieser IP- Adressbereiche. Somit können auch die Newsletter analog zu Spammails in extra Ordner ausgefiltert werden.

54 Internetdienste

5.1.4 Snowshoe-Spam Der größte Teil des Spamaufkommens besteht aus Botnet-Spam, d.h. infizierte PCs verschicken mit spe- zieller Software die Spammails. Diese Art an Spam lässt sich inzwischen mit Hilfe der DNS-basierten Blacklists von Spamhaus zum größten Teil direkt ablehnen. Dies scheinen auch die Spammer bemerkt zu haben. War früher der Anteil des Spams auf 95% des Gesamtvolumens an E-Mails gestiegen, so haben wir inzwischen vor allem tagsüber Zeiten, an denen sich Spam- und Ham-Mails die Waage halten. Probleme bereiten inzwischen die Spammails, die über gephishte Accounts verschickt werden. Da diese E-Mails somit von regulären Mailservern verschickt werden, kann man nicht einfach den Mailserver blockieren. Oft greift auch die struktur-basierte Erkennung der E-Mails (SpamAssassin) nicht mehr, da zum Versand reguläre Mailprogramme verwendet werden. Solche E-Mails lassen sich nur inhaltsbasiert als Spam identifizieren und diese Art der Erkennung ist wesentlich fehleranfälliger. Daher sind wir auf die Meldungen bzgl. falsch markierter E-Mails unserer Nutzer angewiesen (s. Spam-Button von Roundcube). Einen anderen Weg gehen die Spammer mit dem sogenannten Snowshoe-Spam. Hierbei mietet sich der Spammer eine größere Anzahl an IP-Adressen und verschickt über jede IP-Adresse nur eine geringe An- zahl an Spammails, um sozusagen unter dem Radar der Spamalarmierung zu bleiben. Sind die IP- Adressen „verbrannt“, d.h. tauchen sie doch in Blacklists auf, so zieht der Spammer zum nächsten IP- Adressbereich weiter. Die Abwehr dieser Art von Spam wird noch nicht ausreichend durch Blacklists unterstützt, so dass hier noch viel Handarbeit notwendig ist. Bei den oben angesprochenen Newslettern hat sich herausgestellt, dass es Firmen gibt, deren Newsletter zwar wie normale Marketingnewsletter aussehen, die aber mit Snowshoe-Methoden verbreitet werden, es handelt sich also um normalen Spam. Andere Newsletterversender bewegen sich in der Grauzone zwischen Snowshoe-Spam und regulären Newslettern. Man sieht das daran, dass die Newsletter solcher Fir- men extrem oft als Spam gemeldet werden. Da die Firmen sich aber anscheinend noch gerade auf der legalen Seite befinden, können wir den Versand nicht blockieren, sondern nur obige Markierung zur nut- zerseitigen Filterung bereit stellen.

5.1.5 Virenabwehr Wie aus der Statistik weiter hinten zu ersehen ist, ist die Anzahl der pro Tag ausgefilterten vireninfizierten E-Mails relativ gering verglichen mit den großen Virenausbrüchen früherer Jahre. Trotzdem machen vireninfizierte E-Mails seit einiger Zeit ziemlich Probleme. Insbesondere ein bestimmtes Botnet versucht neue Rechner zu infizieren, indem es entweder E-Mails verschickt, die einen Link auf eine infizierte Webseite enthalten, oder die E-Mails enthalten den Virus direkt in einem Anhang. Damit der Virenscan- ner diesen Virus nicht sofort feststellen kann, wird der Virus in kurzen Zeitabständen so modifiziert, dass der Virenscanner eine neue Signatur zur Erkennung braucht. Da das Erstellen und Aktivieren einer Signa- tur mehrere Stunden dauert, nutzt das Botnet diese Zeit um große Mengen an vireninfizierten E-Mails zu verschicken, die dann nicht ausgefiltert, sondern dem Benutzer zugestellt werden. Um dies zu verhindern, wurde am LRZ eine Reihe von Signaturen entwickelt, die nicht versuchen, den Virus selbst zu erkennen, sondern die Software mit der der Virus verschickt wird. Mit Hilfe dieser Signa- turen werden die infizierten E-Mails als Spam markiert und können somit in den Spamordner ausgefiltert werden. Leider ist das nicht für alle Viren möglichl, so dass jeder davon ausgehen muss, dass ein Anhang einer E-Mail einen Virus enthalten kann, der nicht vom Virenscanner erkannt wird.

5.1.6 SRS – Sender Rewriting Scheme Sender Policy Framework (SPF) ist ein Verfahren, bei dem im DNS beschrieben wird, von welchen IP- Adressen E-Mails mit einer bestimmten Absenderdomain verschickt werden dürfen und wie mit E-Mails umzugehen ist, die von anderen Mailservern kommen, z.B. diese ablehnen. Damit soll sichergestellt werden, dass Absenderdomains nicht gefälscht werden. Dieses Verfahren hat aber einige gravierende Nach- teile, so dass es von der IETF nicht als Standard akzeptiert wurde. Der größte Nachteil ist, dass E-Mails nicht mehr wie bisher weitergeleitet werden können, da die Absenderadresse dabei nicht verändert wird und der weiterleitende Mailserver nicht in der Liste der erlaubten Mailserver enthalten ist. Die Absender- adresse muss daher vor der Weiterleitung so verändert werden, dass die Domain zum sendenden Mailser- ver passt. Dies ist mit dem Sender Rewriting Scheme (SRS) möglich.

Jahresbericht 2012 des Leibniz-Rechenzentrums 55

Da einige ISPs, z.B. GMX und Google, SPF trotz der Nachteile einsetzen und daher vom LRZ weiterge- leitete E-Mails entweder abgelehnt wurden oder im Nirwana verschwanden, hat sich das LRZ trotz seiner ablehnenden Haltung gegenüber SPF dazu entschlossen, SRS für die weitergeleiteten E-Mails einzuset- zen, um die Probleme für seine Kunden zu minimieren.

5.1.7 Einsatz von Puppet mit Subversion Um eine so komplexe Umgebung wie das Mailsystem des LRZ von einem Team administrieren zu kön- nen, ist es notwendig, jeden Service vollständig zu beschreiben und für jede einzelne Konfigurationsände- rung festzuhalten:  Was wurde geändert?  Wann wurde etwas geändert?  Wer hat etwas geändert? Aus dieser Dokumentation muss dann automatisch die Konfiguration des Services generiert, installiert und auf aktuellem Stand gehalten werden. Dazu verwenden wir das Tool Puppet, mit dessen deklarativer Sprache ein Service beschrieben wird. Diese Beschreibung und alle Änderungen werden zentral im Ver- sionsverwaltungssystem Subversion gespeichert. Mit Hilfe dieser Daten installiert Puppet automatisch alle benötigten Softwarekomponenten mit zugehöriger Konfiguration und überprüft in kurzen Zeitabstän- den den Ist- mit dem Soll-Zustand. Dadurch wird verhindert, dass undokumentiert lokale Änderungen an einem Service vorgenommen werden. Auch im Extremfall der physischen Zerstörung des Mailsystems ist nach Bereitstellung neuer Hardware in kürzester Zeit ein Desaster-Recovery durch die automatische Neu- installation des Mailsystems möglich. In 2012 wurde mit dem Aufbau dieses Administrationssystems begonnen und bereits ein Teil der Services migriert. Bis Ende 2013 ist geplant alle Mailservices auf Linux-Basis über Puppet zu administrieren.

5.1.8 Maximale Mailgröße erhöht Auf vielfachen Wunsch wurde die maximale Mailgröße im Juni 2012 von 30 auf 50 MByte erhöht, um so den Versand von noch größeren Dokumenten zu ermöglichen. Für den Austausch größerer Dateien steht der FTP-Server des LRZ zur Verfügung.

5.1.9 Statistiken

5.1.9.1 Spam- und Virenabwehr Das Gros der Spam- und Virenmails wird bereits von den Postrelays, die für die Annahme von E-Mails aus dem Internet zuständig sind, durch die dort implementierten Abwehrmechanismen abgewiesen. Die angenommenen E-Mails werden von den Postrelays über die Mailrelays an ein Cluster von Scan- Rechnern weitergeschickt. Dort werden Virenmails ausgefiltert (und die Empfänger darüber informiert) und die verbleibenden E-Mails markiert, ob es sich vermutlich um Spammails handelt oder nicht. Diese Markierung kann dann dazu verwendet werden, die betreffenden E-Mails durch Konfiguration entspre- chender Regeln in Roundcube oder im eigenen Mailprogramm auszufiltern. In der folgenden Graphik ist die Entwicklung von ausgefilterten Virenmails, markierten Spammails und regulären erwünschten E-Mails (Ham-Mails) für die Jahre 2006 bis 2012 graphisch dargestellt. Dabei sind nur die E-Mails berücksichtigt, die aus dem Internet angenommen wurden, also ohne die abgewiese- nen Spam- und Virenmails. Wie man sieht, steigt der Anteil der Ham-Mails seit Jahren nur relativ lang- sam an, während der Anteil der Spammails in den letzten Jahren auf gleichem Niveau verharrt. Der Anteil an Virenmails ist so klein, dass man ihn in der Graphik ab 2008 nicht mehr erkennen kann. Die Werte liegen bei ca. 87 erkannten Viren pro Tag (Vorjahr: 95).

56 Internetdienste

7.000.000

6.000.000

5.000.000

4.000.000 Ham

3.000.000 Spam Viren 2.000.000

1.000.000

Jul Jul Jul Jul Jul Jul Jul

Jan Jan Jan Jan Jan Jan Jan

Okt Okt Okt Okt Okt Okt Okt

Apr Apr Apr Apr Apr Apr Apr Abbildung 34 Monatliches Ham-, Spam- und Virenaufkommen in den Jahren 2006 bis 2012

5.1.9.2 Relaydienst Am Übergang vom Internet in das Münchner Wissenschaftsnetz (MWN) ist an den Routern der Port für das SMTP-Protokoll für fast alle Rechner gesperrt. Nur einige ausgewählte Mailserver – neben den Post- relays des LRZ sind das in der Regel große Fakultätsmailserver – können daher E-Mails direkt aus dem Internet annehmen. Alle anderen Mailserver im MWN müssen diese speziellen Mailserver als Relay- Server benutzen. Der Vorteil ist, dass sich ein lokaler Mailserver im MWN nicht um Viren- und Spamfil- terung kümmern muss; das wird bereits durch den Relay-Server erledigt. Den Relay-Service des LRZ nehmen zurzeit 170 Mailserver im MWN mit insgesamt 440 verschiedenen Maildomains in Anspruch. Die auffällige Abnahme an Servern und Domains bei der TUM ist bedingt durch die Migration auf den zentralen Exchange-Server.

Mailserver Einrichtung Domains im MWN

Ludwig-Maximilians-Universität München 53 (58) 115 (117) Technische Universität München 81 (94) 195 (219) andere Hochschulen und hochschulnahe Einrichtungen 36 (31) 130 (120)

Gesamt 170 (183) 440 (456)

5.1.9.3 Mailhosting (virtuelle Mailserver) Das LRZ bietet Hochschul- und hochschulnahen Einrichtungen, die keinen eigenen Mailserver betreiben wollen, an, den Maildienst am LRZ zu „hosten“. Es wird dann ein virtueller Mailserver eingerichtet, in dem sich der Name der betreffenden Einrichtung widerspiegelt (z.B. jura.uni-muenchen.de) und Angehö- rige dieser Einrichtungen erhalten entsprechende Mailadressen. Ein virtueller Mailserver kann wiederum mehr als eine virtuelle Maildomain haben, z.B. im Zuge einer Umbenennung der zugehörigen Einrich- tung. Die zu den virtuellen Mailservern gehörenden Mailboxen können sich sowohl auf dem POP/IMAP- Server mailin.lrz.de als auch auf dem vom LRZ betriebenen Exchange-Server befinden. Die Entschei- dung, an welchen Server eine E-Mail auszuliefern ist, übernimmt der sogenannte Forwarder, der sich die notwendige Information dafür aus der jeweiligen Benutzerverwaltung holt. Ende 2012 waren am LRZ 216 (Vorjahr: 220) virtuelle Mailserver eingerichtet. Eine Aufteilung auf die Hauptnutzer ist der folgenden Tabelle zu entnehmen. Auch hier ist an den Zahlen die Migration der TUM auf den Exchange-Server zu sehen.

Jahresbericht 2012 des Leibniz-Rechenzentrums 57

virtuelle Einrichtung Domains Mailserver Ludwig-Maximilians-Universität München 90 (93) 144 (137) Technische Universität München 44 (54) 99 (110) Bayer. Akademie der Wissenschaften (inklusive LRZ) 40 (38) 79 (77) andere Hochschulen und hochschulnahe Einrichtungen 42 (35) 46 (46)

Gesamt 216 (220) 368 (370)

5.1.9.4 POP/IMAP-Messagestores Die Anzahl der Mailboxen an den POP/IMAP-Servern war aufgrund der verstärkten Nutzung des Exchange-Dienstes etwas rückläufig. Ende 2012 gab es 108.833 Mailboxen (Vorjahr: 116.077). Nachfol- gend eine Aufteilung nach Server bzw. Benutzergruppen:

Anzahl POP/IMAP-Server für … Benutzer … Mitarbeiter der vom LRZ bedienten Einrichtungen (Mailserver „mailin“): Ludwig-Maximilians-Universität München 8.317 Technische Universität München 7.811 Bayer. Akademie der Wissenschaften (inklusive LRZ) 556 Hochschule München 267 andere bayerische Hochschulen 41 andere wissenschaftliche Einrichtungen 3.006 19.998 … Mitarbeiter und Studenten der TU München (Mailserver „mytum“) 30.532 … Studenten der Ludwig-Maximilians-Universität München (CampusLMU) (inkl. Mitarbeiter, die ihre CampusLMU-Mailadresse behalten haben) 56.274 … Studenten anderer Münchner Hochschulen 2.029

Gesamt 108.833

5.1.9.5 Weiterleitungsservice Der oben bereits erwähnte Forwarder, der für die Verteilung von E-Mails an den richtigen Messagestore zuständig ist, übernimmt neben individuell eingerichteten Weiterleitungen auch einen Weiterleitungsser- vice für ganze Domains, zu denen es keine Mailboxen gibt. Bei der LMU handelt es sich dabei um die Domain lmu.de, bei der TUM um die Domain alumni.tum.de.

Einrichtung Weiterleitungen Ludwig-Maximilians-Universität München 26.110 Technische Universität München 5.100 Gesamt 31.210

5.1.9.6 E-Mail-Verteilerlisten Das LRZ bietet seinen Nutzern die Möglichkeit eigene E-Mail-Verteilerlisten einzurichten (auf Basis des Programms Mailman). Ende 2012 gab es 714 Listen (Vorjahr: 612), die sich wie folgt verteilten:

58 Internetdienste

E-Mail- Einrichtung Verteilerlisten

Ludwig-Maximilians-Universität München 183 Technische Universität München 363 Bayer. Akademie der Wissenschaften (inklusive LRZ) 119 andere Hochschulen und hochschulnahe Einrichtungen 49

Gesamt 714

5.2 Exchange Beim Exchange-Dienst war auch in 2012 ein starkes Wachstum zu verzeichnen. Im Zeitraum November 2011 bis November 2012 kletterte die Nutzerzahl um ca. 8.500 auf ca. 23.500 und der Netto- Speicherbedarf hat sich von 2 auf knapp 4 TByte nahezu verdoppelt (brutto wird wegen des zusätzlichen Bedarfs für Replikate und Snapshots sogar das 3- bis 4-Fache davon benötigt). Um der anhaltend großen Nachfrage nach Exchange gerecht werden zu können, wurde gemeinsam mit den für die Speichersysteme zuständigen Kollegen ein Nachfolgesystem konzipiert, ausgeschrieben, beschafft und Ende des Jahres in Betrieb genommen, inkl. Migration der Nutzer. Da sich das bisherige Sys- tem – mit virtuellen Mailbox-Servern und einem über iSCSI angeschlossenen NAS-Filer – im Betrieb leider als wenig fehlertolerant gegenüber Netzstörungen erwiesen hat, wurde nun eine Konfiguration mit physischen Mailbox-Servern und direkt daran angeschlossenem SAS-Speicher gewählt. Das neue System ist für bis zu 40.000 Benutzer mit einem Speicherbedarf von bis zu 20 TByte (netto) ausgelegt. Im Jahresverlauf 2012 konnte auch eine große Erweiterung der automatischen Provisionierung für Exchange aus den Identity-Management Systemen der Kunden in Betrieb genommen werden. Neben der Treiberunterstützung für die Anlage von Benutzern wird jetzt auch die Anlage von Funktionsmailboxen zusammen mit ihren Berechtigungsgruppen unterstützt. Damit ist es jetzt möglich neben den klassischen Benutzermailboxen auch gemeinsam genutzte Mailboxen (shared Mailboxen), Raum- und Gerätemailbo- xen (Room- und Equipment-Mailboxen) sowie Exchange-Verteilerlisten anzulegen und zu nutzen. Die Funktionsmailboxen und Verteilerlisten haben zudem den Vorteil, dass sie spezielle Berechtigungskon- zepte aufweisen, die z.B. den Zugang und die Nutzung zu den Mailboxen begrenzen können oder den Kalender veranlassen auf Terminanfragen automatisch zu antworten.

5.2.1 Statistik zur Nutzung des Exchange-Dienstes

Wie eben bereits erwähnt, sind die Benutzerzahlen bei Exchange im Jahr 2012 stark angestiegen. Ende 2012 gab es auf dem Exchange-Cluster 23.834 Mailboxen (Vorjahr: 15.750), die sich wie folgt verteilten:

Exchange- Einrichtung Domains Mailboxen Ludwig-Maximilians-Universität München 1.110 39 Technische Universität München 22.277 77 Bayer. Akademie der Wissenschaften (inklusive LRZ) 447 9 Gesamt 23.834 125

5.3 Sharepoint SharePoint ist zum einen die Ergänzung der Groupwarelösung von MS Exchange, da hier die public Fol- der entfallen sind und diese durch SharePoint ersetzt wurden. Zum anderen bietet SharePoint die Mög- lichkeit, für Gruppen die Zusammenarbeit zu verbessern, um z.B. gemeinsam an Dokumenten zu arbeiten oder die Zusammenarbeit über Gruppenkalender, Besprechungsbereiche, Benachrichtigungen, Wikis oder gemeinsame Aufgaben zu organisieren. Der Zugriff auf die Ressourcen erfolgt webbasiert.

Jahresbericht 2012 des Leibniz-Rechenzentrums 59

Es gab zahlreiche Anfragen in 2012 für die Nutzung des Dienstes, es wurden auch einige Testsites aufgebaut, aber nur drei Einrichtungen waren bereit den kostenpflichtigen Dienst zu beauftragen. So werden momentan sechs Sites für zahlende externe Kunden betrieben. Der interne Nutzerkreis umfasste zum Ende des Jahres 2012 neben mehreren Sites für die Gruppenkoor- dination, Ausbildung und Hotline auch Sites zur Koordination mit externen Dienstleistern des LRZ für den neuen Höchstleistungsrechner SuperMUC. In 2012 wurde das Backup um den Data Protecton Manager DPM erweitert, wodurch nun auch einzelne Objekte innerhalb der Sites wiederhergestellt werden können. Mit dem Release von MOSS 2013 im Sommer 2012 haben die ersten Tests der neuen Version begonnen.

5.4 Webhosting

5.4.1 E-Learning Die laufenden E-Learning-Projekte für TUM und LMU wurden mit Unterstützung und Beratung des LRZ weiter ausgebaut. Dabei lag einer der Schwerpunkte bei der technischen Beratung und der Planungsmit- hilfe. Insbesondere beim Moodle-Team der TUM musste aufgrund personeller Engpässe der produktive Betrieb der E-Learning-Plattform besonders sorgfältig erfolgen. Dank der vorsichtigen Planung kam es im Betriebsjahr auch zu keinen größeren Störungen. Unterstützung wurde auch bei der zunächst probe- weisen Bereitstellung eines Video-Konferenzsystems ("Adobe Connect") in Zusammenarbeit mit dem DFN geleistet. Bei der LMU wurde unter anderem auch bei der Erstellung einer Verfahrensbeschreibung zum Datenschutz für die Moodle-Instanzen mitgewirkt. Außerdem wurden die Instanzverantwortlichen der Moodle-Server bei Upgrades durch Beratung und Bereitstellung zusätzlicher Backups unterstützt.

5.4.2 TUM-Portal Für die TUM wurde zu dem bisherigen Typo3-Webhosting-Projekt ein auf dieses Rahmenkonzept aufset- zendes Sonderprojekt begonnen. Es handelt sich dabei um den Betrieb des zentralen Webservers der TUM, der Zug um Zug in die Webhosting-Umgebung am LRZ migriert werden soll. In einem ersten Schritt wurde dazu Mitte des Jahres die Betriebsumgebung am LRZ aufgesetzt, so dass bereits ein erster Teil-Umzug der zentralen TUM-Website erfolgen konnte. Die TUM will nach und nach die bisher selbst gehostete Portal-Lösung auf die LRZ-Systeme umziehen, einzelne Teilbereiche liegen bereits zur Ent- wicklung am LRZ.

5.4.3 Userweb und Research Alle gehosteten persönlichen Homepages (ungefähr 650), die bisher über den externen Webserver des LRZ erreichbar waren, wurden im September 2012 auf einen eigenen Webserver (userweb.mwn.de) migriert. Dabei wurden gleichzeitig auch die zugehörigen Webdaten aus dem nicht mehr unterstützten Datei- system AFS nach NFS umgezogen. Ziel des Umzugs war insbesondere auch, eine klarer erkennbare Trennung zwischen dem Webauftritt des LRZ und den persönlichen Seiten der Nutzer zu erreichen, die bei der Verwendung des gleichen Domainnamens bisher nicht gegeben war.

5.4.4 Downloadbereiche zur Softwareverteilung Für den Download von Softwarepaketen (ISO-Images, ZIP-Files, etc), die vom LRZ im MWN bereitgestellt werden, wurde ein Downloadserver bereitgestellt. Die zuvor relativ unterschiedlichen Methoden zum Download von Software wurden durch diesen Downloadserver stark vereinheitlicht und kunden- freundlicher realisiert. Der früher viel verwendete Download per FTP war im Kontext von dezentralen Firewalls zunehmend problematisch. Durch die Umstellung auf den Download per HTTP-Protokoll treten für die Anwender wesentlich weniger Probleme auf. Auf der Seite der Anwendungsbetreuer am LRZ, die Softwarepakete für den Download bereitstellen, wurde durch die Inbetriebnahme eines Gateway Servers für diesen Zweck auch eine einheitliche Transferschnittstellen zur Verfügung gestellt.

60 Internetdienste

5.4.5 Neuauflage des Webauftritts der BAdW Die BAdW plant für 2013 eine vollständige Neuauflage des bestehenden Webauftrittes. Dieser wird wie auch bisher im Content-Management-System Fiona erstellt werden. Die Entwicklung innerhalb von Fiona wurde an eine externe Firma vergeben (Oestreicher und Wagner). Der gesamte Betrieb wird am LRZ ablaufen. Das dazu notwendige Webhosting-Konzept wurde dem Bedarf entsprechend am LRZ konzipiert und bereitgestellt, dazu wurden u.a. drei neue Maschinen eingerichtet, die das CMS, die dazugehörige Datenbank und eine Suchmaschine aufnehmen werden. Weiterhin gehört eine separate Datenbank der BAdW zum System, die die Daten der Mitarbeiter, Projekt- und Pubikationslisten sowie Termine enthält und die in die neue Website eingebunden werden soll. Neben der serverseitigen technischen Beratung für dieses Projekt erfolgte auch eine umfangreiche Bera- tung zum Konzept des Webauftrittes selber, u.a. im Hinblick auf Nutzbarkeit und Bedienung sowie Barri- erefreiheit. In der folgenden Abbildung ist die Konfiguration der am LRZ betriebenen Komponenten des neuen BAdW Webauftritts und ihre Integration in das allg. Webserverkonzept des LRZ dargestellt.

Abbildung 35 Konfiguration des BAdW Webauftritts

5.4.6 Redesign des Webauftritts des LRZ Anlässlich der Inbetriebnahme des SuperMUC wurde auch das Layout des Webauftritts des LRZ grundlegend überarbeitet und modernisiert, wobei die bessere Erreichbarkeit der Inhalte mit mobilen Endgerä- ten im Fokus stand.

5.4.7 Webhosting-Statistik Auf die zentralen Webserver am LRZ wurde im Jahr 2012 durchschnittlich ca. 86 (Vorjahr: 67) 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-

Jahresbericht 2012 des Leibniz-Rechenzentrums 61

Requests“ gezählt. Wenn also z.B. eine HTML-Seite drei GIF-Bilder enthält, so werden insgesamt vier Zugriffe registriert. Die Zugriffe auf TUM-Webserver stiegen nochmals um ca 50%, nachdem sie sich bereits von 2010 auf 2011 verdoppelt hatten. Das liegt haupsächlich an TUM-Moodle, für das 2012 das erste vollständige Be- triebsjahr war (Beginn war SS 2011). Hinzu kommt die Verlagerung von www.tum.de ans LRZ. Die folgende Tabelle 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üs- selt. 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.

Server Zugriffe Seiten- Daten- aufrufe umfang Mio. GByte

Leibniz-Rechenzentrum 11,47 4,04 2415 Ludwig-Maximilians-Universität München 5,68 1,79 292,1 Technische Universität München 53,82 12,75 3346,9 Einrichtungen im Münchner Hochschulnetz 2,75 0,93 73,2 Einrichtungen im Münchner Wissenschafts- 3,38 0,73 299,4 netz Bayerische Akademie der Wissenschaften 0,77 0,17 152,5 Sonstige 8,8 0,72 783,6

Gesamt 86,67 21,13 7362,7

Tabelle 8: Monatliche Zugriffe auf die Webserver am LRZ

Ende 2012 unterhielt das LRZ 18 Webserver für eigene Zwecke. Für Hochschulen und hochschulnahe Einrichtungen wurden insgesamt 1.142 (Vorjahr: 921) Webserver betrieben.

Einrichtung Webserver Webserver 2012 2011

Leibniz-Rechenzentrum 18 14

Ludwig-Maximilians-Universität München 105 127

Technische Universität München 863 615

Bayerische Akademie der Wissenschaften 28 30

Einrichtungen aus dem Münchner Hochschulnetz 21 29 (z.B. Stiftung Maximilianeum)

Einrichtungen aus dem Münchner Wissenschaftsnetz 35 35 (z.B. Zoologische Staatssammlung München)

62 Internetdienste

Andere (z.B. Bayerisches Nationalmuseum) 72 71

Gesamt 1142 921

Tabelle 9: Anzahl gehosteter Webserver

5.5 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 und Anpassung des erforderlichen Betriebssystemumfangs, je nach den Vorausset- zungen der geplanten Anwendungen,  die Deaktivierung von nicht benötigten Netzdiensten aus Sicherheitsgründen und weitere Sicher- heitsmaßnahmen wie Zugangsbeschränkungen, OS-Hardening und Security-Patches,  die Überwachung der Verfügbarkeit, der Performance und der Funktion auf System- und Appli- kationsebene,  die Messung und geeignete Aufzeichnung der Systemauslastung unter Berücksichtigung der Er- fordernisse der Applikationen zum Tuning und zur proaktiven Ressourcenplanung,  die Erstellung von Betriebs- und Notfallanleitungen für Anwender, Operateure, Dienst- und Sys- temadministratoren,  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 (Inbetriebnahme und sichere Außerbetriebnahme von Systemen, Installation und Update des Betriebssystems, Firmwareupdates, An- bindung ans Rechnernetz, hardware- und netznahe Funktionsüberwachung) als auch mit der Applikati- onsadministration 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 Rechner- betrieb bietet sich an, wenn die Applikationen von den Endbenutzern oder von den Kunden des LRZ eingebracht werden, wenn eine hohe Anzahl gleichartiger Systeme vorliegt oder wenn die Applikationsad- ministratoren dem Betrieb organisatorisch benachbart sind. Bei den Internetdiensten mit ihrem eher indi- viduellen Applikationsprofil hat es sich bewährt, die Systemadministration organisatorisch im Umfeld der Applikationen anzusiedeln.

5.5.1 Serveradministration in BDS Der Abteilung BDS oblag Ende 2012 die Administration folgender Serversysteme:  62 (Vorjahr 52) virtuelle Maschinen mit Linux-Betriebssystem  33 (Vorjahr 35) physische Maschinen mit Linux-Betriebssystem  7 (Vorjahr 11) physische Maschinen mit Solaris-Betriebssystem  73 (Vorjahr 81) physische Serversysteme für die IT-Infrastruktur des Bibliotheksverbundes Bay- ern  100 Systeme mit Windows-Betriebssystem Diese Maschinen wirken im Umfeld der Webservices (Webserver, Content-Management, verschiedene Backendserver), der Datenbanken, der Lizenzverwaltung und weiterer Netzdienste (FTP, Radius, Groupware). Sie beherbergen auch einige Dienste der Rechnerüberwachung und -steuerung (Nagios, Zu- gangsgateways) 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.

Jahresbericht 2012 des Leibniz-Rechenzentrums 63

Im Jahr 2012 sind neben den oben erwähnten permanenten Aufgaben im Rahmen des Systemmanagement auch viele Einzelprojekte durchgeführt worden. Im Folgenden eine Auswahl von Einzelprojekten aus dem Jahr 2012 im Kontext des Serverbetriebs.

 MySQL Server Inbetriebnahme von weiteren virtuellen Maschinen für MySQL Server, u.a. für Content Ma- nagement, Accounting und als DB-Server im LAMP Stack. Einige bereits vorhandene MySQL Server VMs wurden grundlegend überarbeitet und an geänderte Erfordernisse angepasst.

 Maßnahmen zur Außerbetriebnahme von AFS Inbetriebnahme neuer Maschinen als Nachfolgesysteme für Maschinen die stark mit AFS verbunden sind. Bei dem Austausch der Systeme war in vielen Fällen auch eine weitgehende Ände- rung des Betriebskonzepts der betroffenen Dienste notwendig um den Dienst im geänderten En- vironment sinnvoll zu betreiben.

 FTP-Server Durch die Außerbetriebnahme von AFS gewinnt der FTP-Server des LRZ als Schnittstelle zu den Daten auf den diversen Filesystemen wieder mehr Bedeutung. Der FTP-Server wurde deshalb passend zu den laufend dazukommenden Anforderungen schrittweise weiter optimiert.

 Server Zugangskonzept Das Server Zugangskonzept, das zuvor hauptsächlich auf AFS gestützt war, wurde auf das LRZ- SIM Environment umgestellt und vereinheitlicht. Durch die Änderung des Zugangskonzepts wurden auch einige Voraussetzungen zur Erfüllung der LRZ Sicherheitspolicies geschaffen.

 Verlagerung von Diensten auf virtuelle Maschinen Wie bereits in früheren Jahren wurden weitere Dienste von realer Hardware auf virtuelle Maschi- nen unter VMWare verlagert. Im Rahmen der Verlagerung fand teilweise auch ein Wechsel des Betriebssystems von Solaris nach Linux statt.

5.6 Streamingserver Das LRZ betreibt seit 2001 einen Streamingserver. Die Nutzung dieses Servers hat in den letzten Jahren kontinuierlich zugenommen. Dies gilt insbesondere für die Menge des dafür speziell aufbereiteten Video- materials. Insgesamt liegen derzeit auf dem Streamingserver mehrere tausend Filmbeiträge mit einem kumulierten Datenvolumen von 2,3 Terabyte. Die einzelnen Filme sind meist Aufzeichnungen von Vorlesungen oder Vorträgen mit einer Länge von 60-90 Minuten, aber auch kürzere Lehrvideos, die zum Beispiel die Ausbildung in der Medizin unter- stützen. Je nach Dauer und gewählter Auflösung bzw. Bildgröße ist ein typischer Filmbeitrag zwischen 200 und 700 MByte groß. Der ursprüngliche Streamingserver basiert auf QuickTime und für die Wiedergabe der Medieninhalte ist das QuickTime-Plugin notwendig. Für eine spezielle Anwendung, die für das Videoonline-Angebot der LMU entwickelt wurde und die mit Flash realisiert wurde, wird ein Flash-Streamingserver benötigt. Ende 2010 wurde deshalb zusätzlich ein Flash-Streamingserver von Wowza Media Systems aufgebaut, der seit dem Wintersemester 2010/2011 in Produktionsbetrieb ist. Mittlerweile ist die Nutzung des Flash- Streamingservers stark angewachsen. Nahezu zu jeder Tageszeit sind am Server zwischen 50 und 150 gleichzeitige Streams zu beobachten. Der Wowza-Server kann neben Flash-Videos (flv) auch MPEG-4- Videos (mp4) ausliefern, die für den QuickTime-Streamingserver erstellt wurden. Dadurch brauchen Aufzeichnungen nur einmal geeignet kodiert und können über beide Streamingserver verteilt werden.

64 Netzdienste für Institutionen

6 Netzdienste für Institutionen 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 Hochschule Weihenstephan- Triesdorf miteinander. Es wird aber auch von anderen wissenschaftlichen Einrichtungen (u. a. Max- Planck-Gesellschaft, Fraunhofer-Gesellschaft, Kunst-Hochschulen, Museen) mit genutzt. Das Münchner Wissenschaftsnetz bildet die Grundlage für die Kommunikation und Kooperation innerhalb und zwischen den angeschlossenen Institutionen sowie mit Kooperationspartnern in Deutschland, Europa und auch international. Auf Basis der Infrastruktur des MWN werden Dienste sowohl für Institutionen als auch für Endanwender erbracht. In diesem Kapitel werden neben der Struktur und den wesentlichen Änderungen im MWN die Netzdienste für Institutionen (DNS, DHCP, Radius, Netzkomponenten-Beratuung) sowie unterstützende Infrastrukturdienste (Netzmanagement, Telefonie, SLB, IPv6, Multiplexer, etc.) sowie wissenschaftliche Projekte im Bereich KOM vorgestellt. Die Netzdienste für Endanwender werden im nächsten Kapitel präsentiert.

6.1 Struktur und Betrieb des Münchner Wissenschaftsnetzes (MWN) Die Standorte der angeschlossenen Institutionen 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. Abbildung 36 gibt einen Überblick über die räumliche Ausdehnung des MWN. 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. Derzeit sind an das MWN mehr als 440 als Unterbezirke bezeichnete Gebäudegruppen angebunden und es werden mehr als 100.000 Geräte über das MWN versorgt, wobei während des Semesters die Anzahl der mobilen Geräte überwiegt. 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, Weihenstephan) mit mehr als 30 Gebäuden und mehr als 12.500 angeschlossenen Endgeräten. Derzeit sind bereits 57 Stu- dentenwohnheime mit insgesamt mehr als 12.600 Wohnheimplätzen am MWN angeschlossen. Abbildung 37 zeigt die Ausdehnung und Größe des MWN auf einer Karte. Die Nadeln repräsentieren dabei die Unterbezirke. Sind mehere Unterbezirke an einem Ort so werden diese in einem Kreis zusammengefasst und die Zahl gibt an wie viele Unterbezirke zusammengefasst wurden. Weitere Informationen zu dieser Darstellung finden sich in Abschnitt 6.9.2.1. Das LRZ ist für das gesamte Backbone-Netz und einen Großteil der angeschlossenen Institutsnetze zu- ständig. Eine Ausnahme bilden die internen Netze der Medizinischen Fakultäten der Münchner Universi- tä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 Ge- bä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.

Jahresbericht 2012 des Leibniz-Rechenzentrums 65

Abbildung 36 Räumliche Ausdehnung des Münchner Wissenschaftsnetzes (nicht maßstabsgerecht)

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 mehrere Ringe bilden (vgl. Abbildung 40). Netze mit einer geringen Zahl von Endgeräten werden überwiegend mit SDSL-Verbindungen (bis zu 20 Mbit/s) von M-net oder der Telekom oder über WLAN-Verbindungen auf Basis von IEEE 802.11a, g oder n (bis zu 150 Mbit/s) angebunden. Das Backbone-Netz wird genauer im folgenden Abschnitt beschrieben.

66 Netzdienste für Institutionen

 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.

Abbildung 37 MWN Unterbezirke und Ausdehnung

 In den Gebäuden geschieht die Anbindung von Datenendgeräten über Ethernet. Die Anbindung wird entweder über „Twisted-Pair“-Kupferkabel (100/1.000 Mbit/s) und Lichtwellenleiter (100 Mbit/s oder zum Teil 1.000 Mbit/s) oder zu einem sehr geringen Teil noch über Koaxial-Kabel (10 Mbit/s) realisiert. Server-Rechner werden in der Regel mit 1 Gbit/s zum Teil auch mit 10 Gbit/s angeschlossen. Die Gebäudenetze werden in Abschnitt 6.1.3 erläutert.  Die zentralen Rechner im LRZ (der Höchstleistungsrechner SuperMUC, die Linux-Cluster, die Server des Backup- und Archivsystems und die zahlreichen Server-Systeme) sind untereinander mit mehrfach 10 Gbit/s mittels Switches verbunden. Diese Netzstruktur der zentralen Rechner ist über einen Router (10 Gbit/s) mit dem MWN-Backbone verbunden. Die Struktur des Rechenzen- trumsnetzes beschreibt Abschnitt 6.1.4.  Im MWN wird ausschließlich das Protokoll IP benutzt. Abbildung 38 und 39 zeigen die für das Backbone-Netz verwendeten Strecken, deren Übertragungsge- schwindigkeiten und Endpunkte. Hieraus lässt sich die Ausdehnung des Netzes ablesen. Die Areale des MWN werden zu Dokumentationszwecken auch mit Kürzeln aus ein oder zwei Zeichen (Unterbezirke) benannt (eine Liste der in der Abbildung verwendeten Unterbezirke findet sich im MWN-Netzkonzept (s. https://www.lrz.de/services/netz/mwn-netzkonzept/mwn-netzkonzept.pdf).

Jahresbericht 2012 des Leibniz-Rechenzentrums 67

Abbildung 38 Standorte und Verbindungen im MWN

68 Netzdienste für Institutionen

Abbildung 39 Standorte und Verbindungen (Fortsetzung)

Jahresbericht 2012 des Leibniz-Rechenzentrums 69

6.1.1 Struktur des Backbone Netzes Während die Abbildungen 38 und 39 die topologische Struktur, die Standorte und deren Verbindungen zeigen, stellt Abbildung 40 die technische Struktur des Kernnetzes dar. 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 Cisco Catalyst 6509) an das Backbone angebunden. Die meisten Telekom-Glasfasern enden im zentralen Netz Raum des TUM-Stammgeländes. Die M-net Glasfasern enden im zentralen Netz- raum des LMU-Stammgeländes.

Abbildung 40 Struktur des Kernnetzes

Das Router-Backbone bildet mehrere Zyklen, die der Redundanz dienen. Bis auf den Router an der Hoch- schule München haben alle eine mindestens doppelte Anbindung an das Backbone. Im Jahr 2012 konnte auch der Standort Weihenstephan über eine Glasfaser redundant erschlossen werden. Diese Anbindung konnte nur durch eine enge Kooperation mit dem Deutschen Forschungsnetz (DFN) und Gasline realisiert werden. Gasline baute in Freising für die wegeredundante Faser eine neue Trasse von insgesamt 9 km Länge zu einem Verstärkerstandort des DFN, von dort konnte die Faserinfrastruktur des DFN mitgenutzt werden. Die redundante Faser endet in Garching. Mit einer Gesamtlänge von 52 km ist dies die längste LWL-Verbindung im MWN. Im Jahr 2013 ist geplant auch die Hochschule München redundant ans MWN anzubinden. 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). Ausnahmen zu dieser generellen Regel bilden der über „Policy-Based-Routing“ geführte Verkehr, der in einem eigenen VLAN (Virtual 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, Staats- bibliothek, etc.) zu erfüllen.

70 Netzdienste für Institutionen

Auch die Internet-Anbindung ist redundant ausgelegt. Es gibt eine Anbindung an das X-WiN über einen sog. Port-Trunk mit zweimal 10 GBit/s (vom DFN beschränkt auf zweimal 5,5 Gbit/s) und eine an M-net mit 1 GBit/s. Dabei ist die Hierarchie so gewählt, dass die höchste Priorität die Internet-Anbindung zum DFN X-WiN (siehe Abbildung 40) hat. Fällt diese aus, so wird der Weg über M-net gewählt. Die Um- schaltung zwischen den Internet-Anbindungen wird automatisch über ein Routing-Protokoll (BGP, Bor- der Gateway Protocol) gesteuert.

6.1.2 Router Auswahl Das MWN zeichnet sich aus durch ein erhebliches Wachstum sowohl bei den versorgten Geräten, bei den Nutzern, den angebotenen Diensten und damit auch bei den Bandbreiten und übertragenen Datenvolumi- na. Um künftig weiter steigende Anforderungen insbesodere auch im Hinblick auf die Bandbreite erfüllen zu können, bedarf es einer Erneuerung der Backbone-Router.

Die bestehenden Backbone-Router im MWN (Cisco Catalyst 6509) wurden im Jahr 2000 beschafft und in mehreren Aktualisierungsrunden technologisch modernisiert. Die Supervisor-Engines, die die eigentliche Verarbeitung der Pakete durchführen, wurden 2004 und die Policy Forwarding Cards (PFC), die TODO, 2007 aktualisiert. Allerdings ist die Plattform technologisch auf 10 bzw. 20 Gbit/s beschränkt und stößt damit aber in immer mehr Bereichen sichtlich an ihre Grenzen. Ein Migrationspfad zu Bandbreiten von 40 Gbit/s oder gar 100 Gbit/s ist mit dieser Harware-Plattform nicht möglich. Gleichzeitig steigt der Bandbreitenbedarf im MWN kontinuierlich an. Deshalb wurden bereits im Jahr 2011 erste Überlegungen getroffen, wie die bestehende Router-Generation durch moderne und leistungsfähigere Systeme abgelöst werden kann.

Zur Bestimmung und Bewertung geeigneter Komponenten für die neue Router-Plattform wurde von Au- gust 2011 bis Februar 2012 ein vierstufiges Auswahlverfahren durchgeführt:

1. Auswahl potentieller Hersteller 2. Auswahl konkreter Testkandidaten 3. Durchführung von Tests 4. Auswahlentscheidung

Zu Beginn des Verfahrens wurde eine für das MWN spezifische Anforderungsmatrix erstellt und potenti- elle Lieferanten auf Basis eines Fragebogens, um konkrete Produktvorschläge aus ihrem Portfolio gebeten, mit dem nach Meinung der Hersteller die Anforderungen umgesetzt werden könnten. Die Firmen mußten ihre Vorschläge mit technischen Spezifikationen und Datenblättern belegen. Acht Firmen gaben entsprechende Vorschläge und Unterlagen ab.

Auf Basis der von den Herstellern gelieferten technischen Dokumentation wurden die Produkte im Hin- blick auf die Anforderungsmatrix analysiert und bewertet. Da die wichtigste Anforderung bei der Router- Auswahl die Migrationsfähigkeit auf 40 bzw. 100 Gbit/s war, ist vor allem eine hohe Bandbreite zwischen den verschiedenen Slots der Geräte (> 300 Gbit/s) entscheidend für die Auswahl der Testkandida- ten gewesen und es wurden Alcatel, Cisco und HP gebeten, Geräte zum Test zur Verfügung zu stellen.

Nach Auswahl der Testkandidaten wurde im Herbst 2011 ein Testplan erstellt und die von den Herstellern gelieferten Geräte (Testkandidaten) wurden von November 2011 bis Februar 2012 gemäß diesem Test- plan evaluiert. Jeder Testkandidat wurde sowohl im Testlabor untersucht als auch im Münchner Wissen- schaftsnetz am Standort Garching produktiv über eine Woche eingesetzt. Dabei wurden jeweils der Test- plan abgearbeitet und die erreichten Ergebnisse dokumentiert und bewertet. Für den Feldtest (Live-Test) im MWN wurden von den Herstellern jeweils vergleichbare Hardware-Konfigurationen zum Test angefordert. Die Geräte sollten jeweils einen repräsentativen MWN-Kern-Router am Campus Garching ersetzen. Von Alcatel wurde der OmniSwitch 10k und von Cisco der Nexus 7009 und von HP der A12508 getestet.

Die Tests wurden zu Gruppen zusammengefasst und diese Gruppen relativ zueinander bewertet. Konnte eine Anforderung mit dem entsprechenden Gerät umgesetzt werden, wurde dieses Gerät mit „0“ bewertet, falls dies nicht möglich war mit „-1“. Im Falle dass ein Gerät die Anforderung besser als die Konkurenz

Jahresbericht 2012 des Leibniz-Rechenzentrums 71 erfüllt wurde eine „+1“ vergeben. Die Berwertungen wurden am Ende für jedes Gerät aufaddiert. Der klare Gewinner dieser Auswahl waren die Geräte von Cisco.

Parallel zu den Tests wurde ein Antrag nach Art. 143 c Grundgesetz, ein sogenannter „Großgeräte der Länder“-Antrag für den Ausbau des Münchner Wissenschaftsnetzes gestellt. Der Antrag konnte im Mai bei der DFG eingereicht werden und wurde Anfang August 2012 ohne Einschränkungen bewilligt. Da- raufhin wurde am 24. August eine EU-weite Ausschreibung für die Ersetzung der Backbone-Router im MWN veröffentlicht und am 5.11.2012 wurde der Zuschlag an den Gewinner der Ausschreibung, die Firma T-Systems, erteilt.

6.1.3 Struktur der Gebäude-Netze im MWN In den Gebäuden, die durch das MWN verbunden werden, existiert grundsätzlich eine strukturierte Ver- kabelung, bestehend aus Kupferkabeln (Kategorie 5/6, Twisted Pair (TP)) oder Multimode- Lichtwellenleiter-Kabeln (50/125µm). In einigen Bereichen ist allerdings nur eine alte Vier-Draht- Verkabelung verfügbar, welche keine Verbindungen mit Gigabit-Ethernet gestattet und beim Betrieb mit modernen Switches Probleme bereitet. Inzwischen wurden Mittel zur Ersetzung durch eine Verkabelung nach Kategorie 6a genehmigt. Zu einem sehr geringen Anteil ist in sehr wenigen Gebäuden auch noch Ethernet-Koax-Kabel (yellow cable) verlegt. Als aktive Komponenten zur Verbindung mit den Endgeräten werden (Layer-2-) Switches eingesetzt. 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 Pro- Curve 2910 für Serveranschlüsse bei Instituten und im Rechnerwürfel des LRZ in Betrieb. Auch 2012 wurden HP ProCurve-Switches der Serie 5400 aufgebaut. Kennzeichen dieser Netzkomponenten sind 10GE-Ports und Features wie QoS und Meshing. Alle diese Geräte sind modular aufgebaut und bieten über einzubauende Schnittstellenkarten Anschluss von bis zu 288 Geräten. Im Jahr 2012 wurden 54 HP 4100 mit ca. 5.000 Ports ersetzt. Zum Jahresende 2012 wurden vom LRZ insgesamt 1.310 Switches betrieben. Einen Vergleich zu den Vorjahren zeigt Tabelle 10:

Ende 2012 Ende 2011 Ende 2010 Ende 2009 Ende 2008 Ende 2007 Anzahl Switches 1.310 1.247 1.126 990 914 843 davon HP-Switches 1.309 1.246 1.125 989 914 843 davon Cisco-Switches 1 1 1 1 - - Anzahl TP-Ports 81.090 77.562 67.040 60.363 53.591 47.212 Anzahl Glasfaser-Ports 7.687 7.599 6.842 6.493 6.245 5.302 Tabelle 10: Anzahl der im MWN eingesetzten Switches

Die Verteilung nach Switch-Typen ist im Kapitel 17 „Technische Ausstattung“ des LRZ zu finden.

Abbildung 41 Entwicklung bei der Anzahl der Switchports

72 Netzdienste für Institutionen

6.1.4 Struktur des Rechenzentrumsnetzes (RZ-Netz) Ein wichtiger Punkt für eine möglichst nahtlose und störungsfreie Diensterbringung durch das LRZ sind geeignete Redundanzmechanismen, die sich natürlich auch im zugrundeliegenden Netz widerspiegeln müssen. Abbildung 42 stellt die Struktur des Kernnetzes im Rechnerwürfel des LRZ dar. Das Grundprinzip hierbei ist, dass jede kritische Komponente und jede Verbindung doppelt vorhanden sind. Über geeignete Me- chanismen ist dafür zu sorgen, dass bei Ausfall einer Komponente oder einer Verbindung der Datenver- kehr vollautomatisch über redundante Wege und Komponenten abgewickelt werden kann.

Abbildung 42 Struktur des RZ-Netzes

Das Zentrum des Rechenzentrums-Netzes bilden eine Reihe von Switches (HP) mit einer Bandbreite von 2x10 GBit/s (2x10 GE) und ein VSS (Virtual Switching System) von Cisco. Das VSS besteht aus zwei Cisco Catalyst 6509 die, räumlich getrennt, in zwei verschiedenen Brandabschnitten des Rechnergebäu- des untergebracht wurden. Das VSS wirkt für den Nutzer wie ein einzelnes Gerät. So können z.B. Ver- bindungen (sog. Port-Channels) geschaltet werden, die auch beim vollständigen Ausfall eines der beiden Chassis weiterhin funktionieren. Über das VSS wird in dieser Technik eine redundante Anbindung ans MWN-Backbone und ans Internet realisiert. Auch Sicherheitssysteme wie z.B. Firewalls sind doppelt ausgelegt. Die Anbindung der Systeme und Dienste erfolgt über den Verbund von Zentralswitches. Das VSS und die zentralen HP Switches sind mehrfach redundant miteinander verbunden (siehe Abbildung 42). Die dadurch entstehenden Schleifen werden durch den Einsatz des Spanning-Tree-Protokols (STP) verhindert. STP schaltet beim Ausfall einer Verbindung automatisch im Bereich von Millisekunden auf eine andere Leitung um. Die verschiedenen physischen, aber auch die virtualisierten Server sind dann auch wieder

Jahresbericht 2012 des Leibniz-Rechenzentrums 73 jeweils redundant über zwei verschiedenen Zentralswitches und über zwei auch räumlich getrennte Ver- bindungen am Netz angeschlossen. Der SuperMUC und das SuperNAS sind über zwei dedizierte Cisco Catalyst 6509 redundant angebunden (siehe Abbildung 42). Das Linux-Cluster und das Migrationssystem SuperMIG sind über einen Cisco Nexus 7018 Switch angebunden. Für diese Systeme ist derzeit keine netztechnische Redundanz erforderlich bzw. wäre in der Realisierung zu teuer.

6.2 Anschluss ans MWN; Wesentliche Änderungen im Netz Das MWN zeichnet sich, ebenso wie die angeschlossenen Institutionen, durch eine recht hohe Dynamik aus. Neue Gebäude und Anmietungen müssen ans MWN angeschlossen werden und mit neuen Gebäude- netzen versorgt werden. Aber auch Sanierungen und Umbaumaßnahmen erfordern eine Anpassung auch der Datennetze. Steigende Anforderungen führen oft zu gestiegenem Bandbreitenbedarf aber auch die Aufgabe von Gebäuden oder Gebäudeteilen hat Auswirkungen auf das Netz. Der folgende Abschnitt beschreibt diese Netzänderungen. Besonders erwähnenswert ist hier die im letzten Jahr realisierte redundante Anbindung des Campus Wei- henstephan. Diese Anbindung konnte nur durch eine enge Kooperation mit dem Deutschen Forschungs- netz (DFN) und Gasline realisiert werden. Gasline baute in Freising für die wegeredundante Faser eine neue Trasse von insgesamt 9 km Länge zu einem Verstärkerstandort des DFN, von dort konnte die Faser- infrastruktur des DFN mitgenutzt werden. Die redundante Faser endet in Garching. Mit einer Gesamtlän- ge von 52 km ist dies die längste LWL-Verbindung im MWN. An beiden Universitäten gibt es Investitionsprogramme zur Erneuerung der passiven Netzinfrastruktur, dies wird in Abschnitt 6.2.2 beschrieben. Auch Studentenwohnheime sind in erheblicher Zahl über das MWN angebunden und mit Netzdiensten versorgt. Abschnitt 6.2.3 gibt einen Überblick über die angebundenen Wohnheime.

6.2.1 Wesentliche Netzänderungen im Jahr 2012 Im Jahr 2012 gab es folgende in chronologischer Reihenfolge aufgeführte wesentliche Netzveränderun- gen:

09.01.12 Neuanschluss des Studentenwohnheims Garching Living Center (GLC) in Garching per privat verlegter LWL 11.01.12 Rückbau der Netzkomponenten der Hochschule für Fernsehen und Film in der Frankentalstraße wegen Aufgabe des Standortes 30.01.12 Neuanschluss des Neubaus Dachauer Str. 100 a der Hochschule München per LWL 09.02.12 Neuanschluss der Forschungsstation Mülverstedt, Türingen der TUM per LTE 28.02.12 Rückbau der Netzkomponenten am Olympiagelände, ZHS wegen Generalsanierung 01.04.12 Erhöhung der Bandbreite für das Gate in Garching auf 1 Gbit/s 11.04.12 Erhöhung der Bandbreite des Wohnheims Freising II auf 1 Gbit/s 12.04.12 Redundante Anbindung des Campus Freising-Weihenstephan über eine zweite LWL 30.04.12 Neuanschluss des Center for Advanced Laser Applications (CALA) der TUM am Campus Garching per LWL 04.05.12 Änderung der Anbindung der TUM Geodäsie Außenstelle Eichenau von WiNShuttle auf DSL mit gleichzeitiger Bandbreitenerhöhung auf 16 Mbit/s 15.05.12 Umstellung der Anbindung Thalhausen von Satelliten-DSL auf DSL mit gleichzeitiger Band- breitenerhöhung auf 6 Mbit/s 05.06.12 Neuanschluss des Wohnheims Enzianstr. 3-5 in Garching per privat verlegter LWL 11.06.12 Aufgabe des Versuchsgutes Hirschau der TUM 10.07.12 Neuanschluss des Neubaus der Reptilienklinik in Oberschleißheim

74 Netzdienste für Institutionen

13.07.12 Neuanschluss des Erweiterungsbaus des Zentrums für angewandte Energieforschung (ZAE) in Garching 01.09.12 Mitnutzung des MWN durch den Verein Munich Creative Networks (Spin-Offs der Hochschule München) 24.09.12 Neuanschluss der Containerburg der Hochschule Weihenstephan-Triesdorf in Freising- Weihenstephan per LWL 24.09.12 Studentenwohnheim Georg-Lanzenstiel-Haus nicht mehr über MWN angebunden 25.09.12 Studentenwohnheim Geschwister-Scholl nicht mehr über MWN angebunden 28.09.12 Redundante Anbindung der TUM Informatik / Mathematik in Garching per LWL 02.10.12 Umstellung der Anbindung des LMU Seniorenstudiums von DSL auf FibreDSL mit gleichzeitiger Bandbreitenerhöhung auf 10 Mbit/s 08.10.12 Neuanschluss des Business Campus Garching II der TUM per LWL 11.10.12 Bandbreitenerhöhung der Staatsbibliothek auf 10 Gbit/s 22.10.12 Aufgabe des Studentenwohnheims im Maschinenwesen; ehemalige Hausmeisterwohnung 13.11.12 Datennetzsanierung im 2. OG im Flügel 6 im Maschinenwesen in Garching 16.11.12 Erhöhung der Bandbreite des FRM II auf 1 Gbit/s 20.11.12 Anbindung des Business Campus in Garching mittels LWL 22.11.12 Neuanschluss des Studentenwohnheims Freimann (Josef-Wirth-Weg 21) 28.11.12 Bandbreitenerhöhung des Wohnheims Studentenstadt auf 2 Gbit/s 05.12.12 Erhöhung der Funkbrücke des Staatsinstitut für Schulqualität und Bildungsforschung auf 150 Mbit/s 31.12.12 Aufgabe des Gutshofes Grünschweige der TUM

6.2.2 Netzausbau (Verkabelung); Netzinvestitionsprogramm 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 sehr geringen Teil in Koax ausge- fü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 sein wird.

6.2.2.1 TU München Im Bereich der TU München (ohne Weihenstephan) konnten die im Folgenden aufgeführten Gebäude im Jahr 2012 mit einer strukturierten Verkabelung versehen werden.

Innenstadt Stammgelände Gebäude 0505 - 2.Bauabschnitt Gabelsbergerstraße 49 Cam Derzeit gibt es noch Koax in Bau 0503, 0106 (N6) und zum Teil in Gebäude 5402 (CH2); hier soll aber Koax im Rahmen anderer Maßnahmen ersetzt werden.

6.2.2.2 LMU 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 vier-drahtiger Anschluss (Cable-sharing) oder Installation von Kategorie 5 - Kabeln bzw. Anschlusskomponenten). Dies betrifft noch 20 Gebäude (NIP V–2.Bauabschnitt). Die Kosten für die Sanierung dieser Gebäude in Höhe von 6,6 Mio. € wurden vom Landtag freigegeben. Im Rahmen des Konjunkturprogramms wurden im 1. Bauab- schnitt bis Anfang 2012 nachgerüstet:

Jahresbericht 2012 des Leibniz-Rechenzentrums 75

M-Bogenhausen Universitäts-Sternwarte (Neuverkabelung bereits 2009 abgeschlossen)

M-Lehel Oettingenstr. 67 (Informatik, Kommunikationswissenschaft, etc.)

M-Schwabing Leopoldstr. 13 - Haus 1 – 3 (Psychologie+Pädagogik)

M-Maxvorstadt Theresienstr. 37 (Physik, Meteorologie) Theresienstr. 39 (Mathematik) Theresienstr. 41 (Geo- und Umweltwissenschaften)

Die verbleibenden 20 Gebäude werden ab 2013 im Rahmen des 2. Bauabschnittes der NIP V-Maßnahme mit einer Verkabelung der Kategorie 6a modernisiert. Außerhalb der NIP V-Maßnahme wird seit Ende 2012 eine Neuanmietung der LMU mit einer strukturierten Verkabelung der Kategorie 6a ertüchtigt:

M-Schwabing Leopoldstraße 44

6.2.2.3 Weihenstephan (TU München) Im Campus Weihenstephan der TU München sind alle Gebäude mit einer strukturierten Verkabelung versehen, entweder Kupfer (Kategorie 6-Kabel) oder Glasfaser (Multimode).

6.2.2.4 LWL-Netze auf den Campus-Geländen Auf den Campusgelände 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/OM4, Monomode) nicht vorhanden sind, diese aber aufgrund der gestiegenen Übertragungsraten notwendig sind.

6.2.3 Anbindung Studentenwohnheime Das LRZ ermöglicht Wohnheimen eine feste Anbindung über Standleitung, DSL-Technik oder WLAN 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. Drei Heime sind nicht mehr am MWN angeschlossen (Georg-Lanzenstiel-Haus, Geschwister-Scholl und Maschinenwesen), die Träger wechselten zu einem kommerziellen Internetanbieter. Zum Jahresende 2012 sind 12.642 Wohnheimplätze in 57 Heimen an das MWN angeschlossen, davon 39 über eine Glasfaserleitung (LWL) mit 100 Mbit/s oder 1 Gbit/s, 10 über Funkstrecken, 5 über DSL, 2 über Mikrowellenfunk und 1 Heim über 100 MBit/s Laserlink. Die nachfolgende Tabelle zeigt die Wohnheime, die Ende 2012 am MWN angeschlossen sind:

Name Adresse Träger Plätze Anschluss

Studentenstadt Christoph-Probst- Studentenwerk 2.440 LWL zu MPI Freimann Freimann Straße 10

Studentenviertel auf dem Ober- Helene-Mayer-Ring 9 Studentenwerk 1.853 LWL zu ZHS wiesenfeld

Kreittmayrstraße Kreittmayrstraße 14 Studentenwerk 45 LWL zu TUM

Adelheidstraße Adelheidstraße 13 Studentenwerk 301 LWL zu TUM (mit Deutschkurse für Ausländer)

John-Mott-Haus Theo-Prosel-Weg 16 CVJM München e.V. 67 Funk zu Winzererstr.

Oberschleißheim Oberschleißheim Studentenwerk 171 LWL zu Rinderklinik

76 Netzdienste für Institutionen

Am Schäferanger 9-15

Verein evangelischer Öekumenisches Studentenheim Steinickeweg 4 78 Funk zu TUM-Uhrenturm Studentenwohnheime

Verein evangelischer Hugo-Maser-Haus Arcisstr. 31 72 Funk zu TUM-Uhrenturm Studentenwohnheime

Avenariusstraße 15 St. Albertus Magnus-Stiftung St. Albertus Magnus Haus 108 SDSL M-net (Pasing) (Kath.)

Wohnheimsiedlung Funk zu HM Dachauerstra- Wohnheimsiedlung Maßmannplatz Heß-Straße 77 124 Maßmannplatz e.V. ße

Jakob Balde Haus Theresienstraße 100 Studienseminar Neuburg-Donau 110 LWL zu TUM

über Adelheidstr. 13 Internationales Haus Adelheidstraße 17 Studentenwerk 93 angeschlossen

Hedwig Dransfeld 100 MBit/s Mikrowellen- Hedwig Dransfeld Allee Studentenwerk 109 Allee 7 funk

Stettenkaserne Schwere Reiter Str. 35 Studentenwerk 242 M-net LWL

Heidemannstraße Paul-Hindemith-Allee 4 Studentenwerk 310 M-net LWL

Felsennelkenanger Felsennelkenanger 7-21 Studentenwerk 531 M-net LWL

Heiglhofstraße Heiglhofstraße 64/66 Studentenwerk 415 Telekom LWL

Sauerbruchstraße Sauerbruchstraße Studentenwerk 259 M-net LWL

Garching Garching I Studentenwerk 110 Telekom LWL Jochbergweg 1-7

Garching Garching II Studentenwerk 114 LWL zu TU-Heizkraftwerk Enzianstraße 1, 3

Garching Dominohaus Dominobau 82 LWL zu TU-Heizkraftwerk Unterer Strassäcker 21

LWL zu Theresienstraße Türkenstraße Türkenstraße 58 Studentenwerk 97 Intern mit Funk vernetzt

Giggenhauser Str. 25 LWL über Weihenstephan Weihenstephan II Studentenwerk 226 85354 Freising IV

Lange Point Lange Point 1-35 Studentenwerk 384 LWL zu FH Heizhaus (Weihenstephan III) 85354 Freising

Giggenhauserstraße 27- Weihenstephan IV Studentenwerk 237 LWL zur Telefonzentrale 33

Vöttinger Straße Vöttinger Straße 49 Studentenwerk 113 LWL zu alter DVS (Weihenstephan I) 85354 Freising

Stiftung Maximilianeum Max-Planck-Str. 1 Stiftung Maximilianeum 26 Funk zu KH Rechts der Isar

Rambergstraße 6 Studentenwohnheim Paulinum e.V. Studentenheim "Paulinum" 58 Funk zu TUM-Uhrenturm 80799 München (Kath.)

Stud.-Verbindungen Funk zu Richard Wagner Albertia, Ottonia, Erwinia Gabelsbergerstr. 24 25 Albertia, Ottonia, Erwinia Str. 18

Wohnheim Richard Wagner-Str. LWL zu Richard Wagner- Richard-Wagner-Str. 16 Ingeborg van-Calker Stiftung 33 16 Str. 18

Hochschulhaus Garching Enzianstr. 5 Evangelische Studentenwohnheime 95 Funk zu TU-Feuerwehr

Spanisches Kolleg Dachauerstraße 145 Katholische Kirche 34 Funk 802.11a zur HM

Chiemgaustraße Traunsteiner Straße 1-13 Studentenwerk 436 Telekom-LWL zu TUM

Am Anger I Unterer Anger 2 Orden der Armen Schulschwestern 50 M-net SDSL

Am Anger II Unterer Anger 17 Orden der Armen Schulschwestern 85 M-net SDSL

LWL zu Campus Großha- Wohnheim Stiftsbogen Schröfelhofstraße 4 Studentenwerk 588 dern

Jahresbericht 2012 des Leibniz-Rechenzentrums 77

Priesterseminar St. Johannes der Georgenstraße 14 Katholisches Ordinariat 28 Funk zu Georgenstr. 11 Täufer

Johannes-Hanselmann-Haus Kaulbachstr. 25 Ev. Waisenhausverein 117 LWL zu Staatsbibliothek

Marie-Antonie-Haus Kaulbachstr. 49 Studentenwerk 96 LWL zu Ludwigstr. 28

Freisinger Landstraße 47 Student Living Center 1 Fa. Melampus 93 LWL zu TUM Heizhaus Garching

Freisinger Landstr. 47a Student Living Center 2 Fa. Melampus 107 LWL zu TUM Heizhaus Garching

Freisinger Landstr. 45a Student Living Center 3 Fa. Melampus 72 LWL zu TUM Heizhaus Garching

Schleißheimer Str. Garching Living Center GLC GmbH 70 LWL zu TUM Heizhaus Garching

Studentenwohnanlage Biedersteiner Str. 24-30a Studentenwerk 168 LWL zu Amalienstr. 17 Biederstein

Sophie-Barat-Haus Franz-Josef-Str. 4 Katholisches Ordinariat 106 LWL zu Ordinariat

Johann-Michael-Sailer-Haus Preysingstr. 93a Katholisches Ordinariat 26 LWL zu Ordinariat

Heinrich-Groh-Str. Heinrich-Groh-Str. 17 Studentenwerk 59 LML zu Amalienstr. 17

Moosacher Straße Moosacher Str. 81 Studentenwerk 160 100 MBit/s Laserlink

100 MBit/s Mikrowellen- Josef-Wirth-Weg 19 Josef-Wirth-Weg 19 Studentenwerk 190 funk

Gästeappartment Hochschule für Barer Str. 34 1 ADSL mit VPN-Tunnel Musikhochschule Musik und Theater

Oskar von Miller Ring Oskar von Miller Forum Oskar von Miller Forum 80 LWL zu Amalienstr. 17 25

Herzogliches Georgianum Prof. Huber Platz 1 Erzdiözese München-Freising 45 ADSL, intern WLAN

Marienberger Str. 36-38 Rosenheim I Studentenwerk 113 über Tunnel und Secomat Rosenheim

Westendorfer Str. 47a-m Rosenheim II Studentenwerk 342 über Tunnel und Secomat Rosenheim

Frauendorfer Haus Notburgastr. 19-23 Studentenwerk 137 LWL zu Amalienstr. 17

Lothstraße Lothstr. 62 Studentenwerk 62 LWL zu Dachauer Str. 98b

Studentenwohnheim Freimann Josef-Wirth-Weg 21 Grammer Immobilien 449 LWL zu Amalien 17

57 Wohnheime Summe insgesamt 12.642

6.3 DNS und Sicherheit im DNS

Der Domain Name Service (DNS) im Internet dient dazu, lesbare Namen anstelle von IP-Adressen verwenden zu können. Im weltweiten Verbund dienen die Domain-Nameserver zur Auflösung (Resolving) der Domainnamen, d.h. sie liefern für einen Verbindungsaufbau die IP-Adresse zum verwendeten Do- mainnamen. Die Namen sind hierarchisch strukturiert, wobei die einzelnen Stufen durch Punkte getrennt geschrieben werden. Die höchste Ebene (Top Level Domain) steht dabei ganz rechts und bezeichnet häu- fig das Land (z.B. "de" für Deutschland). Die zweite Stufe steht dann für die Organisation bzw. Firma (z.B. lrz.de).

Im Bereich des MWN bietet das LRZ die Möglichkeit, über seine Nameserver den DNS-Dienst zu erbringen. Daneben betreiben einige Fakultäten und Institute für ihre Bereiche auch eigene Nameserver. Ziel ist aber die weitgehende Zentralisierung des Dienstes über die hochverfügbaren und gut gepflegten Server des LRZ. Der DNS-Dienst wird Mandanten-fähig angeboten. Über eine Webschnittstelle (Webdns) können Netzverantwortliche die Ihnen zugewiesenen Namensräume selbstständig verwalten.

78 Netzdienste für Institutionen

Der Webdns-Dienst wird inzwischen von 306 Nutzern zur Pflege der DNS-Einträge verwendet. Die An- zahl der über Webdns verwalteten DNS-Zonen stieg von 2.054 auf 2.339. Es wurden 67 neue Domains unter verschiedenen Toplevel-Domains (z.B. de, org, eu) für Institute und Organisationen registriert, 23 wurden von anderen Providern transferiert.

Die folgenden Bilder zeigen die Frequenz der Anfragen für den authoritativen und den Resolving-Dienst.

Abbildung 43 Statistik für alle DNS-Server (Autoritativ)

Abbildung 44 Statistik für alle DNS-Resolver

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 Instituts-Server keine Auflistungs-Abfragen beantworten. Die Spalte A-Records bezeichnet die IPv4 Einträge, AAAA-Records die für IPv6 und MX-Records beinhaltet die Mail-Server.

Sub- A- AAAA- MX- Mail- WWW- Zone Zonen Domains Records Records Aliase Records Domains Records uni-muenchen.de 376 2.011 30.127 2.117 4.889 3.464 1.557 1.081 lmu.de 112 1.084 4.528 898 2.071 2.852 1.337 816 tu-muenchen.de 274 1.951 20.498 1.204 1.936 7.219 6.763 289 tum.de 343 4.883 15.456 2.423 3.445 2.077 1.648 991 fh-muenchen.de 49 115 3.681 0 232 547 225 30 hm.edu 73 317 9.234 0 254 256 95 77 fh-weihenstephan.de 2 29 64 0 37 2 2 5 hswt.de 0 32 113 0 62 2 2 7 badw-muenchen.de 24 69 38 0 27 104 48 57 badw.de 24 79 1 0 87 88 43 32 lrz-muenchen.de 24 253 747 53 260 44 27 8 lrz.de 74 193 28.050 2.770 1.404 30 17 10

Jahresbericht 2012 des Leibniz-Rechenzentrums 79

mhn.de 63 989 92.175 65 1.259 24.873 12.404 154 mwn.de 49 613 32.720 153 574 31 16 266 Sonstige (637 Zonen) 12 427 2.636 79 981 593 335 638 Gesamt 1.499 13.045 240.068 9.762 17.518 42.182 24.519 4.461

In den WLAN-Netzen mit öffentlichen IP-Adressen (eduroam- und Konferenznetz) wurde von dynami- schen aus der MAC-Adresse abgeleiteten DNS-Einträgen auf statische Einträge der Form dhcp-138-246- 47-12.dynamic.eduroam.mwn.de (Beispiel für den Client mit der IP-Adresse 138.246.47.12) umgestellt, wodurch einerseits die Anonymität der Clients erhöht, und andererseits die Fehleranfälligkeit stark verringert wurde.

6.3.1 DNS-Amplifikation-Attacks und offene Resolver Eine sogenannte DNS-Reflection-Attack bzw. DNS-Amplification-Attack (Reflection-Attack mit Ver- stärkung) dient dazu, das Angriffsziel durch enormes IP-Verkehrsaufkommen zu überlasten. Der Angrei- fer verschickt dazu DNS-Anfragen (viele, bevorzugt klein und verteilt) mit gefälschter Absenderadresse (der Adresse des Angriffsziels) an einen oder mehrere offene Resolver, d.h. an DNS-Server, die rekursive Anfragen aus dem Internet beantworten. Der Resolver antwortet auf die Anfragen an die gefälschte Ab- senderadresse (das Angriffsziel) und speichert die Daten in seinem Cache. Diese (möglichst großen) Ein- träge können auf autoritativen Servern des Angreifers oder auf kompromittierten autoritativen Servern liegen, es können aber auch beliebige „normale“ Einträge (z.B. DNSKEY) sein, die der Angreifer vorher ausfindig gemacht hat. Sowohl große DNS-Records als auch viele Anfragen von einer Adresse (z.B. durch NAT) können legitim sein. Der Angreifer kann den Effekt noch dadurch verstärken, dass er von vielen Rechner (einem sog. Botnet) aus die Anfragen mit der gefälschten Absenderadresse startet. Abbil- dung 45 stellt das Prinzip des Angriffs dar. Selbst wenn Heuristiken zur Angriffserkennung greifen, kann der Angreifer den Angriff verfeinern (mehr unterschiedliche Records, mehr offene Resolver etc.).

Abbildung 45 Funktionsweise der DNS-Amplification-Attack

Solange IP-Spoofing nicht verhindert wird, gibt es keine grundsätzliche Lösung für das Problem, die Wirkung von Gegenmaßnahmen beschränkt sich darauf, den Angriff abzuschwächen oder den Aufwand für den Angreifer zu erhöhen. Offene Resolver sind ein essentieller Bestandteil des Angriffs, gleichzeitig gibt es fast nie gute Gründe für den Betrieb eines offenen Resolvers, verständlicherweise sind offene Re- solver daher nicht gern gesehen.

80 Netzdienste für Institutionen

Die Zunahme der DNS-Amplification-Attacks im letzten Jahr war für das LRZ Anlass, Maßnahmen zur Verringerung der Anzahl der offenen Resolver im MWN zu ergreifen. Als Teil der Maßnahmen wurde auch der (bis Mitte Dezember offene) Resolver resolver2.lrz.de auf Anfragen aus dem MWN einge- schränkt. Auf Anfragen aus dem Internet antwortet der resolver nicht mehr. Gleichzeitig wurde versucht, durch Verkehrsanalyse und Scans offene Resolver im MWN zu finden und sie, in Zusammenarbeit mit deren Betreibern, nach Möglichkeit zu schließen. Die Bemühungen werden 2013 fortgesetzt.

6.4 DHCP Seit ca. 9 Jahren betreibt das LRZ einen DHCP-Dienst, der von allen Münchner Hochschulen für die automatische IP-Konfiguration von institutseigenen 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 184 Instituten genutzt und verwaltet dabei 825 Subnetze mit über 150.000 IP-Adressen. Falls gewünscht, tragen die DHCP-Server die Namen der Clients auch automatisch in die zugeordnete Zone auf den zuständigen DNS-Servern ein (Dynamic DNS). In diesem Jahr wurde der DHCP-Dienst von alten physischen Servern auf vier DNS-Server migriert (Standorte: LMU-Stammgelände, TU-Stammgelände, LRZ Garching und Weihenstephan). Gleichzeitig wurde eine neue Architektur eingeführt: Jeden größeren Router-Standort bedient ein eigenes Failover- Paar, wobei die Paare je auf 2 DNS-Server verteilt werden. Die DNS-Server sind räumlich getrennt und über mehrere Routen erreichbar, sollte also einer der Server oder eine Route zum Server ausfallen, über- nimmt ein anderer Server bzw. eine andere Route. Die Konfiguration der Server wird zentral in einem Subversion-Repository verwaltet und automatisch auf Fehler überprüft und auf die Server übertragen. Das Monitoring wurde dahingehend erweitert, dass nicht nur Ausfälle eines Servers erkannt werden, sondern u.a. auch ein Synchronisationsausfall der Failover-Peers und Netze ohne verfügbare IP-Adressen.

Abbildung 46 DHCP-Infrastrkutur auf den DNS-Servern

Der DHCPv6-Dienst wurde ebenfalls auf die DNS-Server migriert. Da das LRZ den DHCPv6-Dienst stateless betreibt, kann der Dienst über Anycast erreicht werden. Fällt einer der Server aus, schwenkt die Anycast-Route automatisch zu einem anderen Server, der DHCP-Dienst ist also mehrfach redundant.

6.5 Radius Über Radiuszonen können einzelne Institutionen für ihre Beschäftigten bzw. Studierenden die Berechti- gung für den Wählzugang und andere Netzdienste, wie VPN, Eduroam oder Authentifizierung am Netz- rand, selbst verwalten. RADIUS steht für „Remote Authentication Dial-In User Service“. Ein Schema der physischen Struktur des RADIUS-Dienstes zeigt die folgende Abbildung. Die Funktionsweise ist folgende:

Jahresbericht 2012 des Leibniz-Rechenzentrums 81

Nutzer verbinden sich zu einem RAS (Remote Access Server), das kann ein VPN-Server, ein Einwahl- Server, ein WLAN-Access-Point, ein Access-Switch, etc. sein. Diese RAS-Geräte schicken die Authenti- fizierungs-Anfragen an den RADIUS-Proxy-Dienst weiter der über eine virtuelle IP-Adresse an unseren SLBs (Server-Load-Balancer) erreichbar ist. Der RADIUS-Proxy seinerseits wählt anhand der Zonenbe- zeichnung (siehe weiter unten) den eigentlichen Authentifizierungs-Service aus, der die eigentliche Be- nutzerauthentifizierung durchführt. Das kann ein weiterer RADIUS-Server, eine lokale User-Datei, ein LDAP-Server oder ähnliches sein. War die Authentifizierung erfolgreich wird eine entsprechende Freiga- be an den RAS geschickt, andernfalls wird die Zugangsanfrage abgeleht. Die von uns eingsetzte RADIUS Software (FreeRADIUS) unterscheidet zwischen Authorisierung und Authentifizierung. So hat nicht jeder Nutzer der authentifiziert wird auch automatisch Zugang zu allen RAS Geräten.

Abbildung 47 Radius-Strukur im MWN

Zum Jahresende 2012 waren 49 Radiuszonen konfiguriert.

Eine Auflistung der Radiuszonen zeigt folgende Tabelle:

Zonenbezeichnung Zonenbezeichnung aci.ch.tum Lehrstuhl für Anorganische Chemie TUM binfo.wzw.tum.de Genome oriented Bioinformatics bl.lmu Beschleunigerlabor der TU und der LMU München bmo.lmu Lehrstuhl für BioMolekulare Optik, LMU campus.lmu.de Internet und virtuelle Hochschule (LMU) cicum.lmu Department Chemie LMU cip.informatik.lmu Institut für Informatik der LMU

82 Netzdienste für Institutionen

cipmath.lmu Mathematisches Institut LMU cipmath.lmu.de Mathematisches Institut LMU eduroam.mwn.de Eduroam-Nutzer edv.agrar.tum Datenverarbeitungsstelle der TU in Weihenstephan fhm.de Hochschule München fhm.edu Hochschule München fh-weihenstephan.de Hochschule Weihenstephan-Triesdorf forst.tum Forstwissenschaftliche Fakultät frm2.tum Forschungsreaktor fsei.tum Fachschaft Elektro- & Informationstechnik fsmpi.tum Fachschaften MPI hm.edu Hochschule München hswt.de Hochschule Weihenstephan-Triesdorf ibe.lmu Institut für med. Informationsverarbeitung, Biometrie und Epidemiologie ikom.tum Fachschaft Elektro- & Informationstechnik info.tum Informatik TUM lkn.tum Lehrstuhl für Kommunikationsnetze lmu.de Verwaltung LMU lpr.tum Lehrstuhl für Prozessrechner lrz.de LRZ-Mitarbeiter math.lmu Mathematisches Institut LMU math.lmu.de Mathematisches Institut LMU math.tum Zentrum Mathematik TU München med.lmu Medizin der LMU, Großhadern med.lmu.de Medizin der LMU, Großhadern meteo.lmu Meteorologisches Institut LMU mytum.de Mitarbeiter und Studenten der TUM phy.lmu Fakultät für Physik der LMU physik.lmu.de Fakultät für Physik der LMU radius.wzw.tum Informationstechnologie Weihenstephan (ITW) rcs.tum Lehrstuhl für Realzeit-Computersysteme rz.fhm Rechenzentrum der FH München (Studenten) sec.in.tum.de Chair for IT Security, TUM sec.in.tum.gaeste Chair for IT Security, TUM staff.fhm Rechenzentrum der FH München (Mitarbeiter) studext Studentenrechner LRZ (andere) studlmu Studentenrechner LRZ (LMU) tum.de Mitarbeiter und Studenten der TUM usm LMU Sternwarte usm.lmu LMU Sternwarte vm08.fhm Fachbereich 08, FH München wzw.tum Informations-Technologie Weihenstephan

6.6 Netzkomponenten-Beratung Im Edge- und Distribution-Bereich werden seit dem Jahr 2000 Switches der Firma HP eingesetzt. Da der Markt in diesem Gerätebereich sehr dynamisch ist, werden in regelmäßigen Abständen (ca. alle 3 Jahre)

Jahresbericht 2012 des Leibniz-Rechenzentrums 83

Marktuntersuchungen durchgeführt, um die getroffene Switch-Auswahl zu überprüfen. Nachdem die letzte Auswahl im Jahr 2009 stattgefunden hat, war es 2012 an der Zeit, diese zu wiederholen. Ein weiterer Grund für die neue Switch-Auswahl war der Umstand, dass der bestehende Rahmenvertrag zur Be- schaffung von Netzkomponenten im April 2013 ausläuft und daher neu ausgeschrieben werden muss. Über diesen Rahmenvertrag, an dem auch andere bayerischen Hochschulen teilnehmen, können HP- Netzkomponenten zu besonders günstigen Konditionen beschafft werden.

6.6.1 Switch-Auswahl Für die neue Switch-Auswahl wurde zunächst ein Anforderungskatalog erstellt, in dem die Mindestvo- raussetzungen hinsichtlich Hard- und Software definiert sind. Anhand dieser Kriterien wurden dann die Produkte der in Frage kommenden Hersteller auf Basis der Papierform beurteilt. Schließlich wurden daraus 3 Hersteller ausgewählt, deren Switches dann in einem Labortest und einem anschließenden Praxis- test genauer untersucht wurden. Auf Grund dieser Ergebnisse wurde dann entschieden, dass auch weiterhin Switches der Firma HP zum Einsatz kommen sollen, da diese bei gleicher Funktionalität deutlich kostengünstiger und energieeffizienter sind als die Geräte der Mitbewerber.

6.7 Telefonie Die seit dem Umzug des LRZ nach Garching installierte VoIP-Telekommunikations-Anlage auf Basis der offenen Software Asterisk unter Linux arbeitet weiterhin zufriedenstellend. Der erneute Test der verschlüsselten Kommunikation zum DFN hat aus Zeitmangel leider nicht stattgefunden. Langfristig soll die Verschlüsselung für Gespräche innerhalb der VoIP-Anlage und zum DFN aktiviert werden. Durch die Ergebnisse des Tests aus 2011 ist zuerst die Einrichtung eines Gateways geplant, um damit langfristige Erfahrungen sammeln zu können. Insgesamt wurden durch die VoIP-Telefonanlage 2012 ca. 180.000 (2. Halbjahr 2011 ca. 121.000) Ge- spräche mit einer durchschnittlichen Länge von 3:24 Minuten oder insgesamt ca. 610.000 (2. Halbjahr 2011 ca. 270.000, 2010 ca. 590.000) Gesprächsminuten vermittelt. Es konnten ca. 400 Gesprächsminuten direkt über SIP zu externen Teilnehmern abgewickelt werden. Der Wert hat sich damit wieder auf das Niveau von 2010 erhöht. Zu den über SIP erreichbaren Zielen gehören die Universitäten Eichstätt, Regensburg, Würzburg, Ulm, Chemnitz, Wien und Innsbruck. Weitere Informationen zur VoIP-Telefonanlage, wie z.B. Aufbau und Vermittlungsstatistik, können den Jahresberichten ab 2006 entnommen werden.

6.7.1 Zugang über UMTS Nach dem Ende des Sponsorings durch Vodafone wurde die Finanzierung des UMTS Zugangspunkts durch das LRZ übernommen, wodurch die Nutzer der migrierten Verträge weiterhin den gewohnten Weg ins Internet mit MWN IP-Adressen nutzen können. Eine Statistik über das übertragene Datenvolumen liegt leider nicht vor.

6.8 Unterstützende Infrastruktur-Dienste Im Folgenden werden die Infrastrukturdienste beschrieben, die mittels Service Load Balancer, für IPv6 und auf Basis von Multiplexern erbracht werden.

6.8.1 Service Load Balancer (SLB) Zur Zeit verarbeitet der Server Load Balancer mehr als 35.000 Verbindungen (diese entspricht gegenüber dem Vorjahr einer Steigerung von 40 %). Daneben wird das System auch als IPv6 to IPv4 Gateway genutzt.

84 Netzdienste für Institutionen

Übersicht über den Loadbalancer:

2013 2012 Virtuelle Server 280 212 Gruppen (Pools ) 177 182 Pool members 482 292

Virtuelle Server stellen Dienste nach außen bereit, die Anzahl der konfigurierten Server ist angegeben, die Anzahl der aktiven Server ist deutlich kleiner. Bei den Pools handelt es sich um Zusammenfassungen von Rechnern zu einem Pool. Da die Rechner auf verschiedenen Ports mehrere Dienste anbieten können, weicht diese Zahl deutlich von der Anzahl der konfigurierten Nodes (insgesamt 124) ab. Als eines der zentralen Geräte stellt der Loadbalancer Dienste für das gesamte MWN und darüber hinaus bereit. Insbesondere wird dieser für den Mail, Webserver und andere Dienste LRZ-intern, MWN-weit und weltweit genutzt. Dienststörungen sind extrem selten und im gesamten letzten Jahr nur auf geplante War- tung zurückzuführen (ca. 4 Minuten). Der Server Load Balancer wurde im Jahr 2012 auf zwei seperate Brandabschnitte verteilt, um die Redundanz zu erhöhen.

Jahresbericht 2012 des Leibniz-Rechenzentrums 85

Abbildung 48 Anzahl der Verbindungen am Server Load Balancer 1

6.8.2 IPv6 Die Aktivitäten im Bereich IPv6 waren auch im Jahr 2012 vielfältig. So wird das TSM Backup-System seit Februar 2012 auch über IPv6 angeboten. Seit Mai des Jahres 2012 haben die Nutzer bei Einwahl über das VPN-System neben den IPv4-Adressen die Möglichkeit IPv6-Adressen zu beziehen. Im WLAN ist ein erfolgreicher Testbetrieb mit einer SSID "eduroam-IPv6only", die ausschließlich IPv6 Adressen verwendet, durchgeführt worden. An mehreren Außenstandorten (Wendelstein, Triesdorf, Straubing) wurde IPv6 ebenfalls verfügbar gemacht. Viele Dienste aller Abteilungen wurden ebenfalls IPv6-fähig gemacht, ohne sie hier spezifisch zu erwähnen. Die Endsystemanzahl mit nativem IPv6 in der Datenbank von Nyx, kumulativ über eine Woche, stieg deutlich von 16.500 auf 25.100. Jahr 2010 2011 2012 Anzahl der IPv6 Endgeräte in der Nyx-Datenbank 4.800 16.500 25.100

86 Netzdienste für Institutionen

Das LRZ hat am World-IPv6 Day als Netz-Operator teilgenommen. Die Messdaten von http://www.worldipv6launch.org/measurements/ (abgerufen am 22.02.2013) zeigen, dass das LRZ auch im internationalen Vergleich bereits anteilsmäßig viel IPv6 Verkehr hat und weltweit auf Platz 13 liegt.

Im Jahr 2013 ist geplant, die Sicherheitsfunktionen des Secomat-Systems (vgl. Abschnitt 14.4.1) auch für IPv6 bereitzustellen. Dies dient vor allem dazu, den Nutzern von privaten IPv4-Adressen ohne den auf- wändigen Einsatz von virtuellen Firewalls ein analoges Schutzniveau bieten zu können. Der bereits in den letzten Jahren begonnene forcierte Rollout von IPv6 auf den Institutsnetzen wird damit in diesem Jahr abgeschlossen werden können, so dass nur noch Netze mit einem expliziten Einspruch des Netzverant- wortlichen kein IPv6 haben werden. Dabei können nach einer erfolgreichen Testphase auch die über SDSL angebundenen Standorte bedacht werden. Des Weiteren werden in Kooperation mit den anderen Abteilungen im LRZ die verbleibenden nicht IPv6- fähigen Dienste untersucht und migriert. Bereits umgesetzt wurde der Flash-Medienserver, in der näheren Untersuchung befinden sich die verbleibenden großen Verkehrsverursacher SuperMUC und MWN- Speicher.

6.8.3 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. Max-Planck-Gesellschaft, Verwaltung)

Jahresbericht 2012 des Leibniz-Rechenzentrums 87

 Realisierung von Testnetzen parallel (ATM-Pilotprojekte, Fiber-Channel-Kopplung von Speichernet- zen usw.) Im MWN werden vom LRZ aktuell auf 4 Verbindungen WDM-Systeme eingesetzt (vgl. Tabelle 11).

Verbindung WDM-Typ Zweck TU-Nordgelände – MRV LambdaDriver Verbindung der Backbone-Router (1 x 10 LMU-Stammgelände 800 Gbit/s) ATM-Testnetz Erlangen -- IRT (1 x 2,4 Gbit/s (OC48)) TU-Nordgelände – MRV LambdaDriver Verbindung der Backbone-Router (1 x 10 Garching 800 Gbit/s) Intranet der Max-Planck-Gesellschaft (1 x 10 Gbit/s) TU-Nordgelände – MRV LambdaDriver Verbindung der Backbone-Router (1 x 10 Großhadern 800 Gbit/s) Intranet der Max-Planck-Gesellschaft (1 x 10 Gbit/s) LMU-Stammgelände – Pan Dacom T-3009-LC Anbindung des Gebäudes Martiusstr. 4 ans Martiusstraße 4 (passiver WDM) MWN (1 x 1 Gbit/s) Intranet der LMU-Verwaltung ( 1 x 1 Gbit/s) Fiber-Channel-Kopplung der LMU- Verwaltung ( 2 x 4 Gbit/s) Tabelle 11: WDM-Verbindungen

Die Hochschule München setzt darüber hinaus noch auf einigen internen Verbindungen WDMs zur Kopplung von TK-Anlagen ein. Die Telefonanlagen sowie deren abgesetzten Telefonanlagenteile der Technischen Universität und der Ludwig-Maximilians-Universität werden zum größten Teil mittels IP, d.h. über das Standardprotokoll im MWN, miteinander gekoppelt.

6.8.4 IP-Multiplexer IP-Multiplexer dienen zur Verbindung von Telefonanlagen über ein LAN. Sie wandeln die Daten einer S2m-Schnittstelle (30 Sprachkanäle) in einen konstanten Strom von IP-Paketen und schicken diese an einen anderen IP-Multiplexer, der die Rückumwandlung in S2m-Signale übernimmt. Auf diese Art und Weise kann ein bestehendes Datennetz für die Telefonie mitverwendet werden und erbringt somit eine deutliche Kostenersparnis, da keine dedizierten Leitungen mehr für die Kopplung von Telefonanlagen angemietet werden müssen. Im Münchner Wissenschaftsnetz (MWN) werden IP-Multiplexer seit dem Jahr 2005 eingesetzt. Zu-nächst wurden sie dazu verwendet Unteranlagen innerhalb der TU und der LMU mit den zentralen Telefonanla- gen zu verbinden. Im Zuge der Ersetzung bzw. der Erneuerung der Telefonanlagen wurden IP- Multiplexer dort aber weitgehend überflüssig, da die neuen Anlagen selbst eine direkte Kopplung über das IP-Protokoll ermöglichen. Lediglich die Backup-Verbindung der Telefonanlagen in Großhadern und Oberschleißheim wird auch weiterhin mit IP-Multiplexern realisiert. Die freigewordenen IP-Multiplexer wurden im Jahr 2006 dazu verwendet, um das sog. Querverbindungs- netz aufzubauen. Dieses verbindet die Telefonanlagen der verschiedenen Münchner Universitäten untereinander, so dass Telefongespräche zwischen den Hochschulen nicht mehr über das öffentliche Telefon- netz geführt werden müssen, sondern hierfür das MWN genutzt werden kann und damit Kosten einge- spart werden. Eine direkte Kopplung der Anlagen über das IP-Protokoll (ohne IP-Multiplexer) ist nicht möglich, da in den Universitäten Telefonanlagen verschiedener Hersteller eingesetzt werden und diese keine einheitliche IP-Schnittstelle zur Verfügung stellen. Die Struktur der Querverbindungsnetzes zeigt die folgende Abbildung:

88 Netzdienste für Institutionen

Abbildung 49 Struktur des Querverbindungsnetzes

Den zentralen Mittelpunkt des Querverbindungsnetzes bildet die Telefonanlage in der Obersten Baube- hörde. Dort gibt es neben den Verbindungen zu den Hochschulen auch noch eine ganze Reihe weiterer Kopplungen zu Telefonanlagen staatlicher Einrichtungen, wie z.B. Ministerien, Finanz- und Polizeibe- hörden, Theater usw. Auch diese Verbindungen erfolgen nicht über das öffentliche Telefonnetz, sondern über eigene Leitungen.

6.9 Netzmanagement und –monitoring Zur Verwaltung und zum Betrieb des Münchner Wissenschaftsnetzes und seiner Subnetze setzt das LRZ eine Reihe von Standard-Softwaresystemen und komplementäre Eigenentwicklungen ein. In den folgenden Abschnitten wird auf die Werkzeuge zum Netzmanagement, die LRZ-Netzdokumentation und das mandantenfähige Netz-Performancemanagement eingegangen.

6.9.1 Netzmanagement Das Netzmanagement bildet die Basis für die Qualität der Netzdienstleistungen des LRZ im MWN. We- sentliche Komponenten des Netzmanagements sind das Konfigurations-, das Fehler- und das Perfor- mance-Management. Die Aufgaben des Konfigurations- und Fehler-Managements werden im MWN durch den Netzmanagement-Server und der auf dem Server eingesetzten Netzmanagement-Software er- füllt. Die Aufgaben des Performance-Managements werden im Service Level Management Werkzeug InfoVista umgesetzt (siehe Abschnitt Überwachung der Dienstqualität).

6.9.1.1 Netzmanagement-Software und Netzmanagement-Server Im Jahr 2008 wurde der IBM Tivoli Network Manager IP (ITNM) als neue Netzmanagement-Software ausgewählt. Der Auswahlprozess und die Gründe für die Wahl von ITNM sind im Jahresbericht 2008 zusammengefasst. Anfang 2009 war die Version 3.8 des IBM Tivoli Network Manager verfügbar. Mit dieser Version wurde mit der Einführung des Tools am LRZ begonnen. Die Produktivführung des IBM Tivoli Network Manager wurde 2010 durchgeführt. Seitdem übernimmt ITNM die Überwachung des MWN und wird laufend an Änderungen im MWN angepasst. Die wichtigsten in 2012 an ITNM durchgeführten Arbeiten sind:  Mehrere Fixpacks wurden eingespielt, die viele kleinere Fehler behoben haben.

Jahresbericht 2012 des Leibniz-Rechenzentrums 89

 Das "Out of Memory" Problem bei der Discovery, das schon Ende 2011 aufgetreten ist, ist Ende 2012 wieder aufgetreten. Durch die stark gestiegene Zahl von MAC Adressen in den Forwarding Tabellen der Switches bei Semesterbeginn (viele neue Studenten mit Notebooks und/oder Smart- phones und WLAN Verbindung) stürzt der Discovery-Prozess mit einem "Out of Memory"- Fehler ab. Das Problem ließ sich durch eine Vorverlegung des Starts der Discovery von 9:15 auf 8:15 vorerst beheben. Zukünftig kann es notwendig werden die Discovery komplett in die Nacht zu verschieben.  Zusätzlich zur CPU Auslastung (siehe 2011) wird jetzt auch noch die Last aller WLAN- Accesspoints überwacht und eine E-Mail an die WLAN Administratoren verschickt, wenn ein WLAN-AP über längere Zeit eine erhöhte Last hat.  Webcams am Rechnerwürfel und am Wetterturm wurden in die Überwachung mit aufgenommen.  Die Regeln für das Eventmanagement der USVs wurden aktualisiert. Außerdem wird die Batterie Restlaufzeit der USVs überwacht. Alle USVs mit einer Batterie Restlaufzeit von kleiner einer Stunde können abgerufen werden.  Das Erstellen und Einspielen von Zertifikaten für den Web-Server von ITNM wurde am Testsys- tem erprobt. Auf dem Produktionssystem wird ein Zertifikat in 2013 eingespielt.  Verschiedene kleinere Fehler in den SNMP-MIBs der Geräte machen es immer wieder nötig, die von ITNM nicht vollständig richtig erkannte Layer 2 Netz-Topologie des MWN durch manuelle Eingriffe zu korrigieren.  Die Router-, Switch- und WLAN-Accesspoint-Auswahl wurde durch begleitende Tests bzgl. Konformität zu den IETF SNMP Standards unterstützt. Ende 2012 wurden vom IBM Tivoli Network Manager ca. 3.700 Netzkomponenten und Server (mit netz- relevanten Diensten) überwacht. Das ist eine Steigerung von ca. 350 Geräten gegenüber 2011. Der Netzmanagement-Server (nm2.netz.lrz.de), auf dem der IBM Tivoli Network Manager installiert ist, hat außerdem noch folgende Funktionen:  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.

6.9.1.2 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 http://wwwmwn.lrz.de/ werden Performance-Daten zu den wichtigsten Elementen des MWN (Backbone, X-WiN Anbindung, IPv6 Verkehr, Secomat, 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 http://www.mrtg.org) 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. 2012 gab es hier keine wesentlichen Änderun- gen.

6.9.2 Netzdokumentation In der LRZ-Netzdokumentation werden für den Betrieb des MWN relevante Informationen (Netzkompo- nenten, Subnetze, Ansprechpartner, Räume, ...) gespeichert. Die Netzdokumentation basiert auf einer relationalen Datenbank, auf die über ein Web-Interface zugegriffen werden kann. 2012 wurde die Netzdokumentation auf die zum damaligen Zeitpunkt aktuellste Version 2.13.13 des zu- grunde liegenden Anwendungsservers Zope migriert. Im Zuge der Migration wurden außerdem alle Zope Datenbank-Treiber (für die Oracle-, Postgres- und ODBC-Datenbank-Schnittstellen) auf den Datenbank Treiber SQLAlchemy umgestellt. SQLAlchemy ist Open Source und wird (im Gegensatz zu den alten Datenbank Treibern) aktiv von einer Community gepflegt. Daneben wurde noch die Subnetz- und Subnetzbereichsverwaltung erweitert. Bisher konnte zu jedem Subnetzbereich nur ein zugehöriger Unterbezirk gespeichert werden. In manchen Fällen erstreckt sich ein

90 Netzdienste für Institutionen

Subnetzbereich aber über mehrere Unterbezirke. Das konnte aber nicht adäquat in der Netzdokumentation abgebildet werden. Deshalb wurden die Datenbank und das Web-Interface der Netzdokumentation so erweitert, dass zu jedem Subnetzbereich jetzt mehrere Unterbezirke abgespeichert werden können.

6.9.2.1 MWN Visualisierung mit OpenStreetMap und Google Earth Die Unterbezirke des MWN wurden bereits vor einigen Jahren in die Karten von Google Maps mittels Icon integriert und aus der Netzdokumentation wird auf den jeweiligen Kartenausschnitt in Google Maps verlinkt. Eine direkte Integration der Google-Maps-Karten in die Netzdokumentation ist aus Lizenz- Gründen nicht möglich bzw. würde eine kostenpflichtige Lizenz für die Google Maps API von Google erfordern. Deshalb ist es ein Ziel, die Visualisierung der Unterbezirke im MWN von Google Maps auf OpenStreet- Map umzustellen. In einem ersten Schritt wurden in 2012 die Standort-Koordinaten (Längen- und Brei- tengrad) und die Art des Unterbezirk (das Icon in Google Maps) per Skript aus Google Maps ausgelesen, auf unterschiedliche Arten aufbereitet und in verschiedenen KML (Keyhole Markup Language) Files abgespeichert. Mittels dieser KML Files kann dann eine direkte Visualisierung des MWN in der Netzdo- kumentation mit den Karten von OpenStreetMap erfolgen. Die technische Umsetzung dieser Visualisie- rung beruht wesentlich auf der Javascript Bibliothek OpenLayers (http://openlayers.org/). OpenLayers erlaubt die Visualisierung von beliebigen Overlays über den Kartendaten von OpenStreetMap (wobei auch andere Kartenquellen benutzt werden können, unter anderem auch Google Maps). Mit einem Plugin bzw. einer Ergänzung zu OpenLayers konnte auch eine animierte Cluster Darstellung realisiert werden. Neben der Visualisierung der Unterbezirke wurde auch noch eine Visualisierung der Verbindungen zwischen den Unterbezirken realisiert, indem aus der Netzdokumentation die Verbindungsdaten (Anfang, Ende, Bandbreite, ...) ausgelesen werden und zu den KML Files hinzugefügt werden. Außerdem wurde noch eine Darstellung der WLAN Standorte erstellt. Diese soll auch außerhalb der Netzdokumentation für alle Nutzer im MWN zugänglich gemacht werden, so dass die Standorte mit WLAN Zugang im MWN einfach ersichtlich sind. In den folgenden Abbildungen werden die verschiedenen Ansichten der Visualisierung des MWN in OpenStreetMap dargestellt. In der Abbildung "Visualisierung des MWN in OpenStreetMap" ist eine Übersicht über das MWN zu sehen. Die meisten Unterbezirke sind hier zu Clustern (gelbe Kreise) zusammengefasst. Die Cluster Darstellung hat dann Vorteile, wenn zu viele einzelne Icons zu unübersicht- lich wären. Die Zahlen in den Clustern entsprechen der Anzahl der Unterbezirke die durch das Cluster repräsentiert werden. Es ist möglich auf die Cluster-Icons zu klicken, dann wird ein Fenster mit allen Standorten des Clusters angezeigt. In dem Auswahlfenster rechts oben kann sowohl die Grundkarte als auch das gewünschte Overlay aus- gewählt werden, wobei auch mehrere Overlays gleichzeitig dargestellt werden können.

Jahresbericht 2012 des Leibniz-Rechenzentrums 91

Abbildung 50 Visualisierung des MWN in OpenStreetMap

In der Abbildung "Unterbezirke und Verbindungen am Campus Garching" ist ein Ausschnitt zu sehen, der den Campus in Garching zeigt. Hier sind alle Cluster aufgrund des höheren Zoom-Faktors aufgelöst. Die Farben der Icons repräsentieren die Organisations-Zugehörigkeit der Standorte (blau für TU Mün- chen, grün für LMU München, andere Farben für sonstige Standorte z.B. rot für Max-Planck-Institute). Die LRZ-Standorte sind mit dem LRZ-Logo versehen. Verbindungen können auch angeklickt werden, dann wird eine Information zu der Verbindung angezeigt. Die Farben der Verbindungen repräsentieren die Bandbreite der Verbindung, blau steht z.B. für Verbindungen mit größer gleich 10 Gbit/s und rot für Verbindungen mit größer gleich 1 Gbit/s und kleiner 10 Gbit/s. Alle anderen Farben von Verbindungen repräsentieren Verbindungen mit kleineren Bandbreiten.

92 Netzdienste für Institutionen

Abbildung 51 Unterbezirke und Verbindungen am Campus Garching

In der Abbildung "WLAN Standorte in der Münchner Innenstadt" ist eine Übersicht der WLAN- Standorte in der Innenstadt von München zu sehen. Eng zusammen liegende Standorte werden hier ebenfalls zu Clustern (blaue Kreise) zusammengefasst. Die Zahlen in den Clustern entsprechen hier aber nicht der Zahl der Standorte, sondern der Anzahl der WLAN-Accesspoints. Die Zahlen über den ungeclusterten WLAN-Symbolen entsprechen ebenso der Anzahl der WLAN-Accesspoints an diesem Standort. Ein Cluster kann wieder angeklickt werden, dann erscheint ein Fenster mit einer Übersicht der Standorte des Clusters und der WLAN-APs pro Standort.

Jahresbericht 2012 des Leibniz-Rechenzentrums 93

Abbildung 52 WLAN-Standorte in der Münchner Innenstadt

Im Gegensatz zu obiger Abbildung entspricht die Abbildung "WLAN-Standorte im MWN (Benutzer- Sicht)" einer Ansicht, wie sie für Benutzer im MWN angeboten werden soll. Hier wird ein anderes WLAN-Symbol mit Schattenzeichnung verwendet und die Zahlen entsprechen der Zahl der Standorte und nicht der Zahl der WLAN-APs. Ein einzelner Standort kann auch angeklickt werden, dann erscheinen genauere Information zu diesem Standort.

94 Netzdienste für Institutionen

Abbildung 53 WLAN-Standorte im MWN in OpenStreetMap (Benutzer-Sicht)

In allen Overlays kann über eine Eingabezeile nach beliebigen Informationen eines Unterbezirks gesucht werden, z.B. nach dem Unterbezirkskürzel oder der Straße. Bei einem Treffer wird der entsprechende Unterbezirk automatisch in der Karte angezeigt. Bei mehreren Treffern kann mit den Cursortasten oder der Returntaste durch die Treffer geblättert werden. Zusätzlich zu der Visualisierung des MWN in OpenStreetMap wurden auch noch KML-Files zu Visuali- sierung des MWN in Google Earth erstellt. Die KML-Files für Google Earth unterscheiden sich nur sehr geringfügig von denen für OpenStreetMap. Der Hauptunterschied ist, dass hier mehrere KML-Files zu einem KMZ-File zusammengefasst wurden, so dass die Nutzung mit Google Earth einfacher ist. Ein Vor- teil von Google Earth ist flexiblere Auswahl der dargestellten Informationen. Z.B. können nur alle Stand- orte der TU München angezeigt werden oder nur alle 10 Gbit/s Verbindungen. Die KML-Files für OpenStreetMap und das KMZ-File für Google Earth werden zweimal am Tag per Skript aktualisiert. Bis jetzt erfolgt die Pflege der Längen- und Breitengrade der Unterbezirke aber immer noch in Google Maps, da eine Editier-Schnittstelle für diese in der Netzdokumentation noch nicht existiert. Das muss erst noch in einem weiteren Schritt implementiert werden. Bis dahin wird weiterhin die Editier-Schnittstelle von Google Maps genutzt, die Daten per Skript ausgelesen und dann in KML Files abgespeichert.

6.9.2.2 Inhaltliche Aktualisierung der Netzdokumentation Um die Aktualität der Informationen zu den Netzverantwortlichen zu sichern, wurde 2012 wieder eine Benachrichtigung und Überprüfung der Kontaktinformationen durchgeführt. Jeder der 898 Netzverant- wortlichen erhielt per E-Mail die Liste der Subnetze und Subnetzbereiche für die er zuständig ist und die

Jahresbericht 2012 des Leibniz-Rechenzentrums 95 in der Netzdokumentation gespeicherten persönlichen Daten. Diese Daten sollten entweder bestätigt oder eventuelle Fehler korrigiert werden. In der E-Mail wurde auch wieder auf das neue NeSSI-Interface für Netzverantwortliche hingewiesen. An die Netzverantwortlichen, die auch nach drei Monaten noch nicht geantwortet hatten, wurde per Skript automatisiert eine E-Mail zur Erinnerung geschickt. Bei rund 260 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 Netzdoku- mentation übernommen.

6.9.3 Überwachung der Dienstqualität Das Service-Level-Management-Werkzeug InfoVista dient dazu, die Qualität von IT-Diensten zu über- wachen 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än- dig an die Entwicklungen im MWN angepasst bzw. Veränderungen im Netz werden in InfoVista über- nommen. Im Jahr 2012 wurde der InfoVista-Server auf die neue Version 4.2 und Windows 2008 (64 bit) migriert (bisher 4.0 bzw. Windows 2003). Die Migration wurde durchgeführt, indem der neue Server parallel aufgesetzt wurde und anschließend die InfoVista-Datenbank auf den neuen Server kopiert wurde. Als Ne- beneffekt dieser Migration konnte die InfoVista-Datenbank durch das dazu notwendige Backup und Res- tore von über 35 GB auf ca. 23 GB verkleinert werden. Die Verringerung des Platzbedarfs beruht darauf, dass der schon in 2011 durch eine Aufräumaktion als frei in der Datenbank markierte Platz, nun durch das Backup und Restore tatsächlich nicht mehr belegt wird. Durch die Umstellung auf Windows 2008 und der darin enthalten Firewall war außerdem eine bessere Absicherung des InfoVista-Servers möglich. Damit die Datenbankgröße der InfoVista-Datenbank weiter in etwa gleich bleibt, wurden die bestehenden InfoVista Reports bzgl. ihres Platzbedarfs in der Datenbank untersucht. Dabei wurde der "Switch Device Report" als der Report mit dem mit Abstand größtem Platzbedarf identifiziert. Um hier die Situation zu entschärfen und die Instantiierung weiterer Switch Reports zu ermöglichen, wurde in diesem Report das Abfrage Intervall für die Konfiguration des Switches von 5 Minuten auf eine Stunde erhöht und ein Teil der Konfigurations-Abfrage weggelassen, dadurch sinkt der Platzbedarf des Reports deutlich. Ein wesentlicher Teil der Überwachung der Dienstqualität mit InfoVista sind die stündlichen Mittelwerte der Verkehrsauslastung auf den Interfaces der Backbone-Router. Dabei wird eine wöchentliche Übersicht aller Router-Interfaces erstellt, deren Auslastung im Stundenmittel über 30 Prozent liegt. Um hier eine noch zuverlässigere Erkennung von Engpässen zu ermöglichen wurde schon in 2011 damit begonnen zusätzlich noch eine Überwachung der 15-Minuten-Mittelwerte der Router-Interfaces aufzubauen. In 2012 wurde die Überwachung der Router-Interfaces vollständig auf 15-Minuten-Mittelwerte umgestellt und die Überwachung der stündlichen Mittelwerte beendet. Desweiteren wurde die Router- und Switch-Auswahl in 2012 durch parallele Tests mit InfoVista unter- stützt.

6.9.4 Evaluation VistaFoundation Kit 4.3 Das VistaFoundation Kit (VFK) ist eine Erweiterung des im MWN eingesetzten InfoVista-Server um die Komponenten automatische Discovery des Netzes, eine (Last-)Verteilung der Statistik Abfrage auf mehrere Server, eine Administrations-Konsole und ein erweitertes Web-Interface. Das VistaFoundation Kit basiert dabei auf einer zentralen Oracle-Datenbank zusätzlich zu den ObjectStore Datenbanken auf den InfoVista-Servern (beim VFK können mehrere InfoVista Server zur Last-Verteilung betrieben werden). Die Entwicklung bei der Firma InfoVista scheint in die Richtung zu gehen, nur noch das VFK als Produkt anzubieten und zu unterstützen. Das kann bedeuten, dass in Zukunft kein Support mehr für die im MWN eingesetzte Lösung erhältlich ist (derzeit wird sie aber noch unterstützt). Insbesondere aus diesem Grund wurde in 2012 das VistaFoundation Kit in Version 4.3 getestet. Die Evaluation hat aber ergeben, dass der Einsatz des VFK im MWN derzeit viele Nachteile und Proble- me mit sich bringen würde. Diese Nachteile und Probleme sind:

96 Netzdienste für Institutionen

 Die weiteren Komponenten des VFK (Discovery, Last-Verteilung, erweitertes Web-Interface und zentrale Oracle Datenbank) bringen einen erheblichen Mehraufwand bei der Administration mit sich, der durch die spezielle Administrations-Konsole nicht ausgeglichen wird. Speziell die An- passung von Reports an das MWN bzw. die Neuentwicklung von Reports wird durch die neuen Komponenten erheblich komplexer.  Die Unterstützung der im MWN eingesetzten Netz-Geräte ist eher schlecht. Speziell die HP LAN Switches wurden während des Tests nur unzureichend erkannt und es konnten keinerlei Reports darauf aufgesetzt werden. Eine einfache Lösung dieses Problems war auch mit Unterstützung seitens der Firma InfoVista nicht möglich.  Eine Migration der bisher bestehenden selbst entwickelten Reports auf die neue Plattform müsste manuell gemacht werden und wäre wahrscheinlich relativ aufwendig.  Ein Migration der bisher gesammelten Daten auf die Plattform wäre wahrscheinlich gar nicht möglich oder nur mit unverhältnismäßig großem Aufwand.  Das erweiterte Web-Interface des VFK ist ziemlich unübersichtlich und nicht intuitiv benutzbar, da es aus verschiedenen und jeweils etwas anders zu benutzenden Teilen besteht. Z.B. ist ein Teil in Java und Javascript implementiert und ein anderer komplett mit der Flash-Technologie.  Die Lizenzkosten für das VFK wären deutlich höher als bisher (ca. 5 - 10 mal so hoch), insbesondere weil auf eine Device Anzahl basierte Lizenz umgestellt werden müsste (bisher ist die Lizenz unabhängig von der Anzahl der Devices). Aus diesen Gründen wird das VFK im MWN vorerst nicht eingesetzt. Eventuell wird es nochmals getestet, falls eine Konsolidierung beim Web-Interface erfolgt.

6.9.5 Reporting für Netzverantwortliche Die Institute im MWN haben mit den Switch-Reports für Netzverantwortliche über die WWW- Schnittstelle VistaPortal (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 2003 – 2011 instantiierten Reports für Netzverantwortliche kamen 2012 noch Reports für das Department für Geo- und Umweltwissenschaften und die Rechtsinformatik an der LMU hinzu. Die Überwachung des Verkehrsvolumens der Firmen im Garchinger Gründerzentrum GATE wurde eingestellt, weil kein Bedarf mehr dafür bestand. Um die Aktualität der hier bereitgestellten Daten sicherzustellen wurden alle konfigurierten Reports und Instanzen für Switche überprüft und falls notwendig korrigiert bzw. durch neue Reports und Switch In- stanzen ersetzt. Beim Web-Interface VistaPortal selbst gab es 2012 keine Änderungen. Es wurde aber die Version 4.2 von VistaPortal (derzeit 4.0) in einer Testumgebung aufgesetzt, um speziell die Anbindung an LRZ-SIM zur Benutzer-Authentifizierung zu erproben.

6.10 Projekte im Bereich Netze Auch 2012 wurden die Projektarbeiten im Bereich Netze erfolgreich fortgesetzt. In den folgenden Ab- schnitten werden die aktuellen Arbeiten am D-Grid-Projekt GIDS, am CELTIC-BMBF-Projekt SASER, am Customer Network Management und im Rahmen des europäischen Forschungsnetzverbunds Géant beschrieben.

6.10.1 D-Grid GIDS Zur Sicherung der Nachhaltigkeit der 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.

Jahresbericht 2012 des Leibniz-Rechenzentrums 97

Das Projekt, das zum 01.07.2009 begonnen und planmäßig zum 30.06.2012 abgeschlossen wurde, wurde als GAP-Projekt im Rahmen des D-Grids vom Bundesministerium für Bildung und Forschung gefördert. Die Projektlaufzeit betrug 36 Monate und wurde neben dem LRZ vom Regionalen 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 lag. Details zur Problemstellung, zu den Zielen und den bisher abgeschlossenen Arbeitspaketen des Projektes sind in den Jahresberichten 2009, 2010 und 2011 zu finden. Im Projekt wurden im Jahr 2012 folgende Arbeitspakete bearbeitet, deren Ergebnisse nachfolgend näher beschrieben werden:  Kalibrierung des GIDS in Bezug auf das D-Grid Umfeld  Tragfähigkeitsnachweis / Tests der Leistungsfähigkeit  Produktivführung des GIDS

6.10.1.1 Kalibrierung des GIDS in Bezug auf das D-Grid Umfeld Die Aufgabe in diesem Arbeitspaket bestand darin, die Angriffserkennung an die im D-Grid vorher- schenden Gegebenheiten anzupassen. Dafür wurden die bereits im LRZ betriebenen Regelsätze des netz- basierten IDS Snort um Grid-spezifische Programme und Protokolle erweitert (z.B. GSISSH statt SSH, GridFTP statt FTP). Diese Anpassung ist nötig, da die herkömmlichen Erkennungsmuster bei Grid- spezifischen Programmen nicht mehr greifen, da beispielsweise durch Nutzung von GSISSH nicht der Standard-SSH-Port 22 verwendet wird. Diese Regelsätze wurden im praktischen Einsatz getestet, evaluiert und stetig verbessert, um die Erkennungsrate zu maximieren und die False-Positiv-Rate zu minimieren. Dabei hat sich gezeigt, dass die Erweiterung der Regelsätze in produktiven Umgebungen ohne Sei- teneffekte durchgeführt werden konnte. Zusätzlich wurde mit der Integration von OSSEC in die GIDS- Sensorikstruktur eine Host-basierte Erkennung von Rootkits realisiert, die auf Gridknoten lauffähig ist.

6.10.1.2 Tragfähigkeitsnachweis / Tests der Leistungsfähigkeit In diesem Arbeitspaket bestand die Aufgabe darin, einen Nachweis für die Leistungsfähigkeit des GIDS- Systems zu erbringen, wobei neben dem Nachweis, dass die zu erwartende Grundlast für die Komponen- ten zu bewältigen ist, auch ein Nachweis für die Erkennungsleistung des Gesamtsystems zu führen war. Für die D-Grid-Ergebniskonferenz wurde von allen Projektpartnern die Realisierung einer vollständigen GIDS-Instanz durchgeführt, die mit Interaktion der Workshop-Teilnehmer auf dem dortigen GIDS- Workshop vorgestellt und nach und nach in Betrieb genommen wurde. Insbesondere für die Vorbereitung der Ergebniskonferenz wurden die mitgebrachten virtuellen Maschinen vom LRZ konfiguriert und die benötigte Hardware organisiert. In diesem Zuge wurde die vorhandene Dokumentation deutlich erweitert und präzisiert, um den Aufwand für die nötigen Schulungen und den Betrieb der Komponenten zu reduzieren. Insbesondere wurde eine detailierte Installationsanleitung erstellt, die auch in den Anhang von Meilenstein 36 (http://www.grid-ids.de/documents/GIDS_MS36.pdf ; Juni 2012) mit eingeflossen ist. Um die Erkennungsraten von GIDS reproduzierbar nachzuweisen, wurden in enger Kooperation mit den anderen Projektpartnern diverse Wurmausbreitungen wohlerforschter Wurminstanzen simuliert, unter anderem  Scalper  Code Red v2  Code Red II Dabei waren die Ziele die Bewertung der Qualität des kooperativen GIDS-Ansatzes und die empirische Beurteilung der Skalierbarkeit von GIDS. Ergebnis dieser Simulationen war, dass auch das Verarbeiten großer Datenmengen von der Infrastruktur ohne Probleme bewältigt wird. Die Leistungsfähigkeit wurde durch mehrere Lasttests mit künstlich erzeugten Events geprüft. Dadurch wurde zum einen die Leistungsfähigkeit der GIDS-Bus-Kommunikationsinfrastruktur gezeigt; zum anderen wurde nachgewiesen, dass zur Teilnahme an GIDS keine besonders leistungsfähige Hardware eingesetzt werden muss: Im Gegenteil wurde z.B. beim Hands-On-Workshop im Rahmen der Abschlusskonfe- renz gezeigt, dass eine einzige physische Maschine mehr als eine Handvoll virtuelle Maschinen hosten kann, die D-Grid-Ressourcen mit installierten GIDS-Sensoren und den weiteren GIDS-Komponenten betreiben.

98 Netzdienste für Institutionen

6.10.1.3 Produktivführung des GIDS Neben der am RRZN, den am DFN-CERT vorhandenen Sensoriken und den aus der prototypischen Ent- wicklung noch vorhandenen Senoriken am LRZ sind nun mehrere Standorte produktiv mit dem GIDS verbunden. Die Meldungen, die innerhalb von GIDS ausgetauscht werden, können über das GIDS-Portal, das unter https://www.grid-ids.de/index.php?id=3 bzw. unter https://gidsportal.dfn-cert.de/ zur Verfügung steht, eingesehen werden. Es wurde während der Projektlaufzeit ein Konzept zum Betrieb und zur Pflege der GIDS-Komponenten über die Laufzeit von GIDS hinaus erarbeitet, das als Anhang zum Meilenstein 36 (http://www.grid- ids.de/documents/GIDS_MS36.pdf ; Juni 2012) veröffentlicht wurde. Weiterhin wurden innerhalb von diesem eine Anleitung zur Benutzung des Portals und eine Anleitung zum Anbinden einer administrativen Domäne an das GIDS fertiggestellt. Übergabe des Produktivsystems ans DFN-CERT. Dabei wurde die Portalsoftware, die während der Pro- jektlaufzeit zu Entwicklungszwecken auf einem virtuellen Server am LRZ gehostet wurde, für die DFN- CERT-Infrastruktur angepasst und die Übertragung der nötigen Daten durchgeführt. Der Betrieb der Kor- relationsinfrastruktur wird weiterhin über die Projektförderphase hinaus durch das LRZ aufrechterhalten.

6.10.2 SASER Das Verbundprojekt Safe and Secure European Routing (SASER-SIEGFRIED), das zum 01.08.2012 begonnen wurde, wird vom Bundesministerium für Bildung und Forschung gefördert. Die Projektlaufzeit beträgt 36 Monate und wird neben dem LRZ von der Nokia Siemens Networks Management International GmbH (NSN), von der Nokia Siemens Networks Optical GmbH, der Technischen Universität München, der Technischen Universität Berlin, der Fraunhofer Gesellschaft HHI, der Ruhr-Universität Bochum, dem Zuse Institut Berlin (ZIB), der Technischen Universität Braunschweig, der Universität Tübingen, der Universität Würzburg, der FH Potsdam (IxDS GmbH), dem Fraunhofer AISEC und der Technischen Universität Dortmund durchgeführt. Das Internet wurde zu einem unverzichtbaren Teil der Infrastruktur für die meisten Aspekte des täglichen Lebens und hat sich zu einer grundlegenden Infrastruktur für Europa entwickelt. Der ununterbrochene, zuverlässige und sichere Zugriff auf das Internet wird als ein Grundbedürfnis für alle Bürger und als ein signifikanter wirtschaftlicher Faktor gesehen. Der heutigen Infrastruktur Internet fehlen im aktuellen Zustand viele der Merkmale, die ein vertrauens- würdiges, sicheres und geschütztes Kommunikationsmedium in Verbindung gebracht werden. Die Anzahl der Angriffe auf Internet-verbundenen Systemen wachsen und die Angriffe werden im Laufe der Zeit immer technisch komplexer als in der Vergangenheit, so dass die Erkennung und Verhinderung von Schadensfällen immer schwerer ist. Mit der zunehmenden Anzahl von Anwendungen in sensiblen Berei- chen, wie beispielsweise E-Government oder E-Commerce, gewinnen insbesondere die folgenden kritischen Fragen und Problemstellungen an Bedeutung: Sicherheit und Datenschutz, Service-Qualität und Zuverlässigkeit, sofortiger und geschützter Zugang zu Systemen und Diensten und Skalierbarkeit. Innerhalb des BMBF-geförderten CELTIC-Projekts SASER-SIEGFRIED werden von allen Projektpart- nern in enger Zusammenarbeit Netz-Architekturen und Technologien für sichere zukünftige Netze entwickelt. Das Ziel ist es, Sicherheitslücken der heutigen IP-Schicht-Netze im Zeitrahmen bis etwa 2020 zu korrigieren. Zur Erreichung des Ziels werden die folgenden Aktivitäten durchgeführt: Zum einen wird die Datenübertragung so weit wie möglich in die tieferen Netzwerk-Layer (Physical Lay- er und Data Layer) zu verlagern, um die Notwendigkeit von IP-Routern zu reduzieren, die in der Vergan- genheit als sicherheitskritisch aufgefallen sind. Dies kann erreicht werden, wenn Technologien wie beispielsweise die Netz-Virtualisierung und effiziente Redundanzkonzepte umgesetzt werden, die auf flexib- len und hoch verfügbaren optischen Systemen basiert realisiert werden. Zweitens werden Mechanismen der Sicherheit für zukünftige Netze entwickelt, die auf einer Analyse der verbleibenden Sicherheitsprobleme in der IP-Schicht (zum Beispiel Backdoor- und Anomalie-Detection) basieren. Im Jahr 2012 wurde das Teilprojekt TP-1 („Komponentenkopplung an Netzmanagementsysteme“) durch- geführt, welches noch planmäßig in Arbeit ist. TP-1 umfasst die Abstimmung der zusätzlichen technischen Schnittstellen in Zusammenarbeit mit den anderen Projektpartnern, die Modellierung der neu zu verwaltenden sicherheitsspezifischen Informationen in einem auf die Aufgaben von Managementsyste-

Jahresbericht 2012 des Leibniz-Rechenzentrums 99 men abgestimmten Datenformat, die Festlegung der Kommunikation, die zum Auslesen und zum Schrei- ben über diese zusätzlichen Schnittstellen erforderlich ist, und eine Implementierung dieser Konzepte. Im Jahr 2012 lag der Schwerpunkt der Arbeiten auf Seiten des Monitoring, das heißt auf dem Auslesen sicherheitsrelevanter Kennzahlen aus aktiven Netzkomponenten durch Netzmanagementsysteme; die Rück- richtung, das heißt die Steuerung und Beeinflussung einzelner Netzkomponenten durch zentrale Netzma- nagementsysteme, ist Gegenstand der weiteren Arbeiten. Bei der Analyse der möglichen technischen Schnittstellen zur Übertragung sicherheitsrelevanter Informa- tionen zwischen Netzkomponenten und -managementsystemen wurde zunächst die Problematik identifiziert, dass sich eine allgemeinverbindliche Definition von Sicherheitskennzahlen (engl. meist als security metrics bezeichnet) bisher noch weder in der Praxis noch in wissenschaftlichen Abhandlungen hinrei- chend durchgesetzt hat. Die Ermittlung und Auswertung von Sicherheitskennzahlen ist für SASER- SIEGFRIED jedoch essentiell, da auf diesen basierend Routingentscheidungen getroffen werden sollen. Somit ist eine allgemeinverbindliche Definition von Sicherheitskennzahlen für die weiteren Schritte in diesem Teilprojekt nötig, da sowohl die Modellierung der Informationen als auch die Implementierung von der Definition dieser abhängen. Um Sicherheitskennzahlen unter Berücksichtigung des State-of-the-Art exakt definieren zu können, wurde im Jahr 2012 eingangs eine breite Literaturrecherche durchgeführt, deren Ziel es war, die aktuellen wissenschaftlichen Arbeiten und praktischen Umsetzungen zu diesem Thema zusammenzusuchen und zu bewerten. Dabei wurden in einem ersten Schritt die Zielsetzungen und Herausforderungen beim Einsatz von Sicherheitskennzahlen herausgestellt; dabei wurde gezeigt, dass einige weit verbreitete sog. „Sicher- heitsmetriken“ die mathematischen Grundanforderungen an Metriken, insbesondere die Dreiecksunglei- chung, nicht erfüllen, so dass der unmittelbare Einbezug derart quantifizierter Sicherheitseigenschaften zum Beispiel in Routingprotokollen zwangsweise zu verfälschten Ergebnissen führen würde. Auf dieser Basis wurden Kriterien erstellt, die Sicherheitskennzahlen erfüllen müssen, um im Rahmen von SASER- SIEGFRIED eingesetzt werden zu können. Neben der Spezifikation eines automatisierenden Messverfahrens zur regelmäßigen Akquisition der Si- cherheitskennzahlen wurde damit begonnen, eine Reihe von Sicherheitskennzahlen zu definieren, die projektweit zur Diskussion gestellt werden sollen. Die Koordination mit den Projektpartnern in diesem Bereich ist etwas verzögert, da das SASER-Gesamtarchitektur-Referenzmodell, in das auch die Sicher- heitskennzahlen eingebettet werden müssen, erst später als erwartet zur Verfügung stand. Ein Teilziel von TP-1 besteht darin, aus den entwickelten Sicherheitskennzahlen auch einige sog. Security Key Perfor- mance Indicators (SKPIs) auszuwählen, die bei der weiteren Konzeption projektpartner-übergreifend immer berücksichtigt werden sollen. Zudem ist noch abzustimmen, wie die in anderen Teilprojektenvon SASER-SIEGFRIED ermittelten Ergebnisse quantitativ in den Netzmanagementsystemen ausgewertet werden sollen. Weiterhin wurde eine Zusammenarbeit mit der Fachhochschule Potsdam (IxDS GmbH) angestoßen. Die Fachhochschule Potsdam ist innerhalb von SASER-SIEGFRIED für das Design und graphische Interface einer Benutzeroberfläche zur Angriffserkennung beteiligt. Das LRZ stand im Rahmen von Interviews und Ideenaustausch auf Basis der langjährigen betrieblichen Erfahrung im Netzmanagement und dem Betrieb großer Netze beratend zur Seite. Auf dieser Basis wurde auch eine im Jahr 2012 noch nicht abgeschlossene Diskussion mit der Universität Würzburg und NSN angestoßen, in der es um die Wahl des Protokolls zum Ansteuern des Netzmanagements geht. Da die zu entwickelnde Lösung auf Software defined networking (SDN) basieren soll, wird voraussichtlich OpenFlow das Mittel der Wahl sein; für Legacy- Umgebungen, in denen unsere Prototypen evaluiert werden sollen, ist jedoch auch das langjährig bewähr- te SNMP (Simple Network Management Protocol) zu unterstützen. Die vom zum Netzmanagement eingesetzten Protokoll unabhängige Integration in die Control Plane der Netzkomponenten wird parallel dazu mit den Projektpartnern diskutiert.

6.10.3 Customer Network Management (CNM) Das Customer Network Management (CNM) wurde ursprünglich für das MWN (Münchner Wissen- schaftsnetz) entwickelt, dann innerhalb mehrerer DFN-Projekte für das B-WiN, G-WiN und schließlich das X-WiN erweitert. Customer Network Management (CNM) bezeichnet allgemein die kontrollierte Weitergabe von Ma- nagementinformationen durch den Anbieter eines Kommunikationsdienstes an die Dienstnehmer sowie

100 Netzdienste für Institutionen das Bereitstellen von Interaktionsschnittstellen zwischen Dienstnehmer und Diensterbringer. CNM er- möglicht es den Dienstnehmern, sich über den Zustand und die Qualität der abonnierten Dienste zu informieren und diese in eingeschränktem Maße selbst zu managen. CNM trägt dem Paradigmenwechsel vom komponentenorientierten zum dienstorientierten Management dadurch Rechnung, dass nicht mehr ausschließlich Low-level-Daten - wie z.B. Management Information Base (MIB)-Variablen der Kompo- nenten - betrachtet werden, sondern kundenorientiert aufbereiteten Informationen über die Einhaltung der vertraglich ausgehandelten Dienstvereinbarungen. Die CNM-Anwendung für das X-WiN ist unterteilt in die zwei Anwendungen Topologie und Datenvolu- men:  Die CNM-Anwendung Topologie dient der Visualisierung der X-WiN-Topologie/des Zustands der IP-Infrastruktur (siehe Abbildung 54).

Abbildung 54 Die CNM-Anwendung "Topologie"

Anhand dieser Anwendung wird den DFN-Kunden (Anwendern) ein Überblick über den aktuellen und historischen Zustand und Qualität der IP-Infrastruktur gegeben. Für jede im X-WiN bestehende Verbindung werden Bandbreite, Auslastung und Durchsatz graphisch dargestellt; für jeden Knoten (Router) die Rate der weitergeleiteten Pakete. Auf der Netzebene gibt es derzeit 57 Standorte, die jeweils einen Router enthalten. Diese Router sind direkt mit den Kundeninfrastruk- turen verbunden und enthalten auch verschiedene Verbindungen zu kommerziellen Netzbetrei- bern sowie dem europäischen Wissenschaftsnetz Géant. Die mit hierarchischen Karten arbeitende Anwendung wurde im April 2004 für alle X-WiN-Anwender freigegeben und ist seitdem im Be- trieb. Die Topologie-Anwendung gibt es zusätzlich auch für das MWN und für Géant, jeweils als getrennte CNM-Server-Instanzen laufend.  Die CNM-Anwendung Datenvolumen dient der Bereitstellung von dienstorientierten IP- Interfacestatistiken für die DFN-Anwender. Die DFN-Anwender können mit Hilfe der CNM-Anwendung Datenvolumen die Verkehrsvolu- mina, die sie aus dem X-WiN empfangen bzw. gesendet haben, abrufen. Für jeden bestellten IP- Dienst wird für den Anwender ein eigenes CNM-Auswahlfenster für IP-Interfacestatistiken bereitgestellt. Es werden Tages-, Wochen-, Monats- und Jahresstatistiken bereitgestellt.

Jahresbericht 2012 des Leibniz-Rechenzentrums 101

Bei der CNM-Anwendung handelt es sich um eine verteilte Client/Server-Architektur. Der Client ist als Java-Applet erhältlich. Der Server ist in C++ implementiert. Der Server bedient sich einer XML- Datenbank, GIS2 (Globale X-WiN-Informationssystem), die alle X-WiN-Kunden/Dienst-Daten verwaltet. Als Kommunikationsmiddleware sowohl zwischen dem Client und dem Server als auch zwischen dem Server und GIS2 dient CORBA. Da am LRZ alle Server nach Möglichkeit als virtuelle Server in der VMware-Infrastruktur laufen sollen und diese unter der vorherigen Sparc-Solaris Architektur mit VMware nicht virtualisiert werden konnten, wurde eine Portierung des CNM-Systems auf Linux-x86 gewünscht. 2010 wurde bereits ein Portierungs- plan erstellt für die schrittweise Portierung des kompletten CNM von Sparc-Solaris mit dem kommerziellen CORBA ORB auf Linux-x86 mit einem auszuwählenden frei verfügbaren ORB. Die 2012 auf Intel x86-Linux portierte CNM-Architektur wurde seit Anfang des Jahres vom DFN und von den Anwendern pilotiert. Durch kontinuierliche Verbesserungen konnte die Architektur im Juli 2012 vollständig umgeschaltet werden.

6.10.4 Projekte im Rahmen von Géant Das LRZ ist im GN3-Projekt des europäischen Forschungsnetzverbunds Géant an zwei Tasks der Service Activity 2 beteiligt, in denen drei Software-Werkzeuge für das länderübergreifende Netzmanagement erarbeitet werden. Neben der Implementierung von WebCNM umfasst dies das Design des Planungs- werkzeugs I-SHARe und die Entwicklung des End-to-End-Link-Monitoringwerkzeugs E2EMon.

6.10.4.1 Géant-Visualisierungswerkzeuge und Performance Monitoring Das bereits aus dem MWN und X-WiN bekannte CNM wird seit 2004 im europäischen Forschungsum- feld als Visualisierungswerkzeug eingesetzt, im Géant2-Projekt von 2004 bis 2009 und in dessen Nach- folger Géant3 seit 04/2009. Mit der CNM-Anwendung Topologie werden die Topologie und aktuelle bzw. historische Kennzahlen vom Géant-Kernnetz sowie einigen der 34 angeschlossenen nationalen For- schungsnetze in hierarchischen Netzkarten visualisiert. Auf Basis des im MWN prototypisch entwickelten WebCNM und der LHCOPN-Wetterkarte, wurde 2011 mit der Entwicklung eines allgemeinen WebCNM-Konzepts begonnen (siehe LRZ-Jahresbericht 2011). Das Ziel dabei war eine flexible, integrierbare, anpassbare Web-Anwendung, die die vollständige Funkti- onalität der bisherigen JavaWebStart-Applikation und darüber hinausgehende Features bietet. Das CGI- Backend, das auf dem CNM-Server läuft und den Zugriff auf Topologie- und Metrikdaten mit Autorisie- rung bereitstellt, ist in Perl geschrieben. Das Front-End ist in Java-GWT programmiert und wird mittels Java GWT-Compiler in eine JavaScript-Webseite übersetzt. 2012 wurden weitere Funktionen hinzugefügt und die Anwendung verbessert. Beispielsweise wurde die Statistikgraphenfunktionalität entwickelt, das GUI flexibler und generischer gestaltet sowie diverse spezielle Karten und Datenquellen angebunden.

102 Netzdienste für Institutionen

Abbildung 55 Darstellung der perfSONAR BUOY OWAMP Daten in WebCNM

Abbildung 55 zeigt perfSONAR BUOY OWAMP Daten, die 2012 in WebCNM angebunden wurden.

Abbildung 56 Management-Interface

Ferner wurde mit der Implementierung des Management-Interfaces (siehe Abbildung 56) begonnen, um WebCNM per Web-Interface zu konfigurieren. Neu eingebaute graphdateibasierte Karten können online editiert werden (siehe Abbildung 57). Zusätzlich wurden die interne Hilfe und Tooltips testweise implementiert.

Jahresbericht 2012 des Leibniz-Rechenzentrums 103

Abbildung 57 Editiermöglichkeit der graphdateibasierten Karten

Für weitere Informationen zum Géant-Projekt siehe http://www.geant.net .

6.10.5 Projekte im Rahmen von Geant3 Auch 2012 wurden die beiden GN3-Teilprojekt I-SHARe und E2EMon bearbeitet; die aktuellen Projekt- ergebnisse werden nachfolgend dargelegt.

6.10.5.1 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. In GN3 werden diese insbesondere im Zusammenhang mit den 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 Wissen- schaftsnetze. 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, 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. Diese Entwicklung wurde Mitte 2010 abgeschlossen, woraufhin eine fundierte und detaillierte Qualitätssicherungsphase folgte, die auf Basis der Spezifikation durchgeführt wurde. Nach erfolgreichem Test konnte das Release für die Pi- lotphase freigegeben werden. Während der letzten Vorbereitungen für die Pilotphase wurde I-SHARe allen beteiligten und interessierten Partnern auf der TERENA-Konferenz vorgestellt. Die Pilotphase wurde dann mit einer Benutzerschulung eingeleitet, die federführend vom LRZ vorbereitet und durchgeführt wurde. I-SHARe wird derzeit von mehreren NRENs für die Planung neuer End-to-End Links genutzt (siehe Abbildung 58).

104 Netzdienste für Institutionen

Abbildung 58 I-SHARe

Das ISHARe-Team am LRZ bereitet derzeit die Integration der Anwendung in ein standardisiertes Netz- management-Framework vor, wie es die GEANT Network Management Architecture (NMA) vorsieht. Dazu wurden die in I-SHARe implementierten Prozesse 2012 als eTOM-konformes Geschäftsprozess- Modell abgebildet und somit die Voraussetzung für die Zusammenführung mit verwandten Netzwerkma- nagement-Anwendungen geschaffen.

6.10.5.2 E2E-Link und Dynamisches Circuit-Monitoring mit CMon Neben klassischen IP-Verbindungen können im Rahmen des Géant-Verbundes auch End-to-End (E2E) Links statisch sowie dynamisch eingerichtet werden. Das LRZ arbeitet seit Jahren aktiv in Projektteilen mit, die Konzepte, Verfahren und Tools zum Management dieser Ende-zu-Ende Links bereitzustellen. Ein wesentlicher Bestandteil dieses Projekts ist das E2E Link Monitoring System (E2Emon), das unter Feder- führung des LRZ konzipiert und entwickelt wurde. Nach jahrelang erfolgreichem Betrieb des E2Emon- Systems im Projekt werden nun neue Anforderungen aufgenommen und das System wird in einer neuen Projektphase unter der Projektname CMon (Circuit Monitoring) weiter entwickelt. Das CMon-System soll dazu in der Lage sein, nicht nur statisch eingerichtete Links, sondern auch dynamisch angelegte Verbindungen zu überwachen. Verglichen mit statischen Links haben die dynamisch eingerichteten Links i.A. kürzere Lebensdauer und sind mit häufigen Veränderungen verbunden. Deshalb ist es notwendig, für das zukünftige CMon-System diese Dynamik eines Links bei Monitoring zu berück- sichtigen. Da das Einrichten dynamischer Verbindungen in Géant durch AutoBAHN (Automated Band- width Allocation across Heterogeneous Networks) realisiert wird, ist eine Kooperation auf Systemebene zwischen CMon und AutoBAHN vorgesehen.

Jahresbericht 2012 des Leibniz-Rechenzentrums 105

Abbildung 59 Hauptanwendungsfall des CMon-Systems als UML Use Case

Abbildung 59 zeigt den primären Use Case von CMon. Design und Entwicklung des Systems werden in einer Kooperation zwischen LRZ und NORDUNET durchgeführt, wobei das LRZ die federführende Rol- le übernimmt. Ein Prototyp ist in der Endphase der Entwicklung und wird bereits für Tests eingesetzt. Das betriebsbereite System wird in der nachfolgenden Projektphase Géant 3+ entwickelt werden und letztendlich das bisjetzige E2Emon ablösen.

106 Netzdienste für Endanwender

7 Netzdienste für Endanwender Für die Endanwender (Studenten und Mitarbeiter der verschiedenen Institutionen) steht der Zugang zum MWN und damit zum Internet im Vordergrund. Die Netzdienste richten sich nach diesen Anforderungen aus. Im Jahr 2012 hat die Zahl der Endanwender weiter zugenommen. Insbesondere die mobile Nutzung von Netzdiensten zeichnete sich durch exteme Wachstumsraten aus. Dies wirkt sich insbesondere auf WLAN und Eduroam aus (vgl. Kap. 7.2). Um einen sicheren Zugang ins MWN über unsichere Netze zu ermöglichen, betreibt das LRZ VPN-Dienste die im Kap. 7.3 beschrieben werden.

7.1 Internetzugang und LAN Der Zugang zum weltweiten Internet wird über das Deutsche Wissenschaftsnetz (WiN) realisiert. Im Jahr 2012 war das MWN technisch mit einem Trunk aus zwei 10 Gbit/s-Schnittstellen am WiN angeschlossen. Dieser Zugang wird vom DFN auf eine Bandbreite von 11 Gbit/s (zweimal 5,5 Gbit/s) beschränkt. Der- zeit ist ein zweistufiges Ausfallkonzept mit Backups für den Internetzugang umgesetzt (s.u). Die monatliche Nutzung (übertragene Datenmenge) des WiN-Anschlusses seit Januar 2000 zeigt Abbil- dung 60. Die Datenmenge pro Monat nähert sich einem Petabyte.

Abbildung 60 Entwicklung der Nutzung des WiN-Anschlusses des Münchner Wissenschaftsnetzes

Die Steigerungsraten - bezogen auf die jeweils im Vorjahr transportierte Datenmenge - sind in Abbildung 61 graphisch dargestellt. Seit dem Jahr 2000 hat die Datenmenge auf die 100-fache Menge zugenommen

Jahresbericht 2012 des Leibniz-Rechenzentrums 107

Abbildung 61 Steigerungsraten beim übertragenen Datenvolumen

Seit September 2003 ist der X-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 Dezember 2012) zeigt Tabelle 12:

Institution Total Bytes % LRZ und BAdW 75,6% TUM 6,3% LMU 5,6% Hochschule München 0,9% Sonstige 11,4% Hochschule Weihenstephan 0,1% Gate 0,1% Tabelle 12: Prozentuale Verteilung des Datenverkehrs am WiN-Zugang

Die prozentuale Verteilung des gesamten Verkehrs gegenüber den Werten des Vorjahres hat beim LRZ um 5% zugenommen abgenommen. In etwa im gleichen Verhältnis hat der Verkehr bei LMU und TUM abgenommen. Die technische Realisierung der Anbindung des MWN an das Internet zeigt Abbildung 62.

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 Anschlußbanbreite von 11 Gbit/s. Dort wurde vom DFN der zugehörige WiN-Kernnetz-Router installiert. Im Jahr 2011 wurde die beiden Glasfasern zum X-WiN Router zu einem Trunk zusammengefasst. Damit ließ sich eine höhere Bandbreite (2 x 5,5 Gbit/s) realisieren. Derzeit ist ein zweistufiges Ausfallkonzept für den Internetzugang umgesetzt. 1. Falls eine Glasfaser zwischen dem LRZ-Router und IPP oder eines der entsprechenden Interfaces an den beiden Routern ausfallen sollte, funktioniert der Trunk zwischen Maschinenwesen und IPP weiterhin, allerdings nur mit halber Bandbreite.

108 Netzdienste für Endanwender

Abbildung 62 Anbindung des MWN ans Internet

2. Sollten beide Leitungen oder aber der Kernnetzrouter des DFN oder der Router des LRZ in Gar- ching 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 Verbrauch berechnet. Die Backup-Konzepte funktionieren für alle Systeme mit Provider-unabhängigen IP-Adressen (Standard- fall im MWN). Das LRZ-Netz kann nämlich mit einem Großteil seiner IP-Adressen als autonomes Sys- tem im Internet agieren. Einige Standorte (Rechts der Isar, Hochschule München, Beschleunigerlabor, Zoologische Staaatsammlung, kath. Stiftungsfachhochschule) bzw. Systeme (Bibliotheksverbund Bay- ern), die aus historischen Gründen noch providerabhängig IP-Adressen (i.d.R. vom DFN vergeben) verwenden, können die Backup-Strecken nicht nutzen. Im Jahr 2012 wurde die Backup-Strecke in 12 Fällen aktiv. In der Regel handelte es sich dabei um sehr kleine Störungen (z.B. im Routing oder bei IPv6) und der Backup war nur für wenige Minuten aktiv. Am 11.11.2012 und am 29.11.11 kam es Probleme mit dem DFN-Router im X-WiN. Bei diesen Vorfällen, wäre es ohne den Backup zu einer Unterbrechung der Internet-Konnektivität gekommen.

7.2 WLAN und Eduroam Das LRZ versorgt primär öffentliche Bereiche (Seminarräume, Hörsäle, Bibliotheken, Foyers, Uni- Lounges) mit Wireless LAN, eine Flächendeckung für Bürobereiche kann bis auf weiteres nicht realisiert werden. Trotzdem sind Ende 2012 bereits 2.053 Accesspoints in Betrieb. Im Berichtsjahr 2012 wurden mit 312 noch mehr Accesspoints als 2011 installiert. 350 300 250 200 150 100 50 0 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012

Abbildung 63 Anzahl der jährlich installierten Accesspoints

Jahresbericht 2012 des Leibniz-Rechenzentrums 109

Die Nutzung stieg rasant an, insbesondere bedingt durch die stark zunehmende Anzahl von Smartphones und Tablets. Die im letzten Jahr gemessene Zahl von 7.064 gleichzeitigen Verbindungen stieg 2012 auf maximal 11.732 an, insgesamt wurden dabei über 300.000 verschiedene Geräte beobachtet. Sehr nachgefragt wurde das WLAN auch bei 348 Kongressen und Tagungen innerhalb des Jahres 2012.

Abbildung 64 Anzahl aktiver WLAN-Verbindungen am 27.11.2012 (5-Minuten-Mittel)

Abbildung 65 Entwicklung der Belegung über das Jahr 2012 (Tagesmittel)

In den Bildern zeigt der blaue bzw. dunklere Bereich den Anteil von Verbindungen mit IEEE 802.11g (54 Mbit/s). Die am stärksten frequentierten Accesspoints waren mit bis zu 234 gleichzeitigen Verbindungen belegt. Ältere hoch belastete Accesspoints wurden durch die aktuellste Geräte-Generation ersetzt. Als Zugangskomponenten werden Accesspoints der Typen MSM310, MSM320, MSM422, MSM460 und MSM466 der Firma HP eingesetzt. Bei den ab 2011 eingesetzten MSM460 und MSM466 werden Daten- raten bis zu 450 Mbit/s (IEEE802.11n) unterstützt. Bei geschickter Wahl der Frequenzen und Verzicht auf die Unterstützung des veralteten Standards 802.11b kann diese Übertragungsgeschwindigkeit auch im 2,4 GHz-Band erreicht werden. Aus diesem Grund wurde 802.11b auf allen Accesspoints abgeschaltet. Durch den Anstieg der Benutzerzahlen wurden die Adressen für die verschiedenen SSIDs an manchen Router-Standorten knapp. Bei einer einfachen Vergrößerung des Adressbereichs wären dabei die Broadcast-Domains so groß geworden, dass die Teilnetze keinen guten Durchsatz mehr geboten hätten. Deshalb wurde bereits 2011 damit begonnen, für jede SSID/Router mehrere Teilnetze einzurichten. We- gen der Roaming-Problematik (gleiche SSID über unterschiedliche Accesspoints) kann die Netz- Zuordnung dabei nicht automatisch erfolgen, durch den hohen Konfigurationsaufwand wird die Umstel- lung erst im Laufe des Jahres 2013 abgeschlossen werden.

110 Netzdienste für Endanwender

Im Laufe des Jahre 2012 wurden folgende Bereiche neu mit WLAN ausgestattet:

Hochschule Weihenstephan-Triesdorf, 3 neue Gebäude HM Dachauer Str. 100b, Bau T LMU Garching, Laserhalle LMU Leopoldstraße 13a, Mensa Musikhochschule, Wilhelmstr. 19 Studentenstadt Freimann, Christoph-Probst-Str. 10 TUM Arcisstr. 19 TUM Augustenstr. 44 TUM Gabelsberger Str. 43 TUM Garching Hochschulreferat 6, Geb. 5203 TUM Garching Physikdepartment Containerbau TUM Ingolstadt, Marie-Curie-Str. 8 TUM Nordgelände N6, Bauingenieur und Vermessungswesen TUM Stammgelände Elektrische Antriebssysteme TUM Stammgelände Elektrotechnik und Informationstechnik TUM Stammgelände Gebäude 0505 TUM Stammgelände Holzbau TUM Stammgelände Informatik 6 TUM Stammgelände Ingenieurgeologie TUM Stammgelände IT-Service-Zentrum TUM Stammgelände Zentrale Verwaltung TUM Weihenstephan Alte Akademie, Geb. 4108 TUM Weihenstephan Gebäude 4309 TUM Weihenstephan Verwaltung, Geb. 4321 TUM ZHS Ausweichquartier Campus C

Die nachfolgenden Bereiche sind weggefallen bzw. werden nicht mehr vom LRZ betreut:

Hochschule für Fernsehen und Film (Altbau) Pinakotheken Freifläche Nord TUM Nymphenburger Str. 39 TUM Versuchsgut Grünschwaige TUM Weihenstephan Altes Molkereigebäude

7.2.1 WLAN-Ausbau im Gebäude der Fakultät Maschinenwesen Die Studienbeitragskommission der Fakultät Maschinenwesen der TU München hat knapp 70.000 Euro für die Verbesserung der WLAN-Versorgung bereitgestellt. Gemeinsam mit dem LRZ wurde ein entspre- chendes Konzept erarbeitet und in sehr kurzer Zeit auch umgesetzt. Da die Zahl der Studierenden und der mobilen Geräte stark gestiegen ist, reichte sowohl die Bandbreite der bestehenden WLAN-Accesspoints als auch die Zahl der gleichzeitig unterstützten Nutzer pro Acces- spoint im Gebäude der Fakultät Maschinenwesen in Garching nicht mehr aus. In einem ersten Schritt wurden deshalb in allen öffentlichen Bereichen die bestehenden Accesspoints durch neueste Modelle mit einer Bandbreite von bis zu 450 Mbit/s ersetzt. In den Hörsälen, in denen die Anzahl gleichzeitiger Nut- zer naturgemäß noch höher ist, wurden zusätzliche Accesspoints zur Verstärkung installiert. Insgesamt wurden im Rahmen dieser Maßnahme 67 Accesspoints verbaut.

Jahresbericht 2012 des Leibniz-Rechenzentrums 111

Damit sich alle Nutzer mit ihren Geräten auch weiterhin anmelden können und ihr Gerät eine Adresse zugewiesen bekommt, mussten außerdem zusätzliche Netze zur Verfügung gestellt werden. Da die Swit- ches in den Gebäudehauptverteilern nur eine begrenzte Anzahl verschiedener Netze unterstützen, wurden in den acht Gebäudehauptverteilern die Zentralswitches erneuert. Aus Brandschutzgründen dürfen in der Magistrale des Maschinenwesens keine zusätzlichen Accesspoints installiert werden, daher ist die Versorgung dort noch nicht optimal. Das LRZ hat jedoch, in enger Ab- stimmung mit dem zuständigen Bauamt, eine Lösung erarbeitet, die nur passive Antennen im Fluchtweg- bereich vorsieht. Wegen aufwändiger Leitungsinstallationen ist die Umsetzung aber erst 2013 möglich. Der Zeitplan für das Projekt war sehr ambitioniert. Die Mittel wurden Mitte Februar bewilligt, die Arbei- ten konnten komplett in der vorlesungsfreien Zeit bis zum 15. April abgewickelt werden. Dies war auch nur deshalb möglich, weil neben den verantwortlichen Mitarbeitern drei Auszubildende maßgeblich für das Projekt gearbeitet haben. Einer von ihnen entwickelte auch seine praktische Abschlussarbeit aus dem Projekt.

7.2.2 WLAN-Auswahl Zur Überprüfung der für das MWN optimalen WLAN-Lösung wurde von Juni bis Oktober 2012 eine ausführliche Auswahl von in Frage kommenden Produkten durchgeführt. Nach einer Marktuntersuchung wurde 15 Herstellern eine 50 Fragen umfassende Anforderungsliste zuge- sandt, welche von 11 Firmen beantwortet wurde. Die essentiellen Kernanforderungen konnten nur von Aruba, Cisco und Hewlett Packard erfüllt werden. Von August bis Oktober wurden die Lösungen von Aruba und Cisco durch Testinstallationen ausführlich geprüft, die Lösung von HP war durch den produktiven Einsatz bereits bekannt. Aufgrund der vorgelegten Angebote und der Testergebnisse wurde entschieden, dass für den künftigen Ausbau des WLANs im MWN die Lösung von Aruba eingesetzt werden soll. Nur Aruba bietet beim Ein- satz von Controllern die notwendige Flexibilität, eine Weiterführung bzw. sanfte Migration der eingeführ- ten Prozesse beim Betrieb des WLANs im MWN zu ermöglichen.

7.2.3 Eduroam Das LRZ nimmt seit Anfang 2005 am Eduroam (früher DFN-Roaming) teil. Damit ist es Wissenschaft- lern 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. Die SSID eduroam wird auf fast allen Accesspoints im MWN zur Verfügung gestellt. Nur an zwei Stand- orten mit je einem Accesspoint, die über DSL-Leitungen angeschlossen sind, ist es aus technischen Grün- den nicht möglich, Eduroam anzubieten. Die frühere SSID 802.1X wurde 2012 abgeschaltet. Da einige Clients Probleme haben, wenn eine SSID sowohl im 2.4GHz-Band als auch im 5GHz-Band angeboten wird und dann ständig zwischen beiden Bändern wechseln, wurde eine spezielle SSID eduroam-a eingeführt, die dann von solchen Clients verwendet werden kann.

Abbildung 66 Benutzungs-Statistik für die SSID eduroam

112 Netzdienste für Endanwender

Da die SSID eduroam als Standard-SSID für die Nutzung im MWN angeboten wird, sind die Benutzer- Zahlen sehr stark gestiegen. Aus diesem Grund wurde noch im Jahre 2012 mit der Implementierung der SSID eduroam-IPv6only begonnen. Verbindungen zu dieser SSID bekommen keine offizielle IPv4- Adresse mehr, sondern arbeiten nur mit IPv6.

7.2.4 Unterstützung von Veranstaltungen Das LRZ richtet für Veranstaltungen im Münchner Wissenschaftsnetz (MWN) bei Bedarf ein spezielles Netz ein, welches die Tagungsteilnehmer ohne besondere Authentifizierung nutzen können. Hierbei wird davon ausgegangen, dass die Nutzer dieses Netzes nicht immer aus dem Wissenschaftbereich stammen, sondern auch Mitarbeiter von Firmen und anderer Organisationen Netzdienste ohne spezielle Vorkehrun- gen (ohne VPN-Client-Installation, ohne Validierung) nutzen wollen. Eine Anmeldung und die bei frei zugänglichen Netzanschlüssen ansonsten obligatorische Verwendung eines VPN-Zugangs werden hier nicht gefordert. Diese "offene" Konfiguration bleibt auf den Zeitraum und den Ort der Veranstaltung begrenzt. Der Zu- gang ist drahtlos (WLAN nach IEEE 802.11a/g/n) möglich. Nur in Ausnahmefällen werden feste Netzan- schlussdosen (100 Mbit/s oder 1 Gbit/s LAN) zur Verfügung gestellt. Für Geräte, die keine eingebaute Funkschnittstelle haben, werden vom LRZ Wireless-Client-Bridges (WCB) bereitgestellt. Die Realisier- barkeit des Dienstes hängt aber von der vorhandenen Infrastruktur ab, nicht in allen Gebäuden und Räu- men sind die Voraussetzungen erfüllt. Allerdings ist dies meistens der Fall. Der Netzname (SSID) ist dabei con. Es wird keine Verschlüsselung verwendet, um Probleme mit der Weitergabe und Einstellung der Schlüssel zu vermeiden. Für länger dauernde Kurse oder auf Wunsch des Veranstalters werden aber auch verschlüsselte Netze eingerichtet. Mitarbeiter von wissenschaftlichen Einrichtungen, die am Eduroam teilnehmen, kommen mit diesem Netz aber nicht in Berührung, da sich deren Geräte automatisch mit der SSID eduroam verbinden. 2012 wurden 348 Veranstaltungen (+44 gegenüber dem Vorjahr) unterstützt. Auch im Jahr 2012 wurden für die Unterstützung der Konferenzen teilweise schon vorhandene Access- points gegen neuere ausgetauscht, um den erhöhten Bedarf abdecken zu können. Damit können Konfe- renz-Teilnehmer mit neueren Laptops Transfer-Raten bis zu 450Mbit/s erreichen und geben dadurch den Funkkanal schneller wieder für andere Teilnehmer frei. Außerdem wurden öfters Accesspoints 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 die folgende Statistik. Erwartungsgemäß werden die Hörsäle vor allem in vorlesungsfreien Zeiten für Konferenzen genutzt.

Abbildung 67 WLAN-Freischaltungen für Veranstaltungen 2012

Betrachtet man die Anzahl der freigeschalteten Accesspoints multipliziert mit der Anzahl der Tage (AP- Tage), dann ergibt sich die folgende Verteilung auf die einzelnen Institutionen:

Jahresbericht 2012 des Leibniz-Rechenzentrums 113

TUM LMU HM BadW LRZ Sonstige Gesamt 1.221 651 384 52 212 70 2.590

7.3 VPN Im MWN werden Virtual-Private-Networks in folgenden Szenarien eingesetzt:

 Zugang über vom LRZ betreute WLANs.  Zugang über öffentliche Anschlussdosen für mobile Rechner.  Zugang zu internen MWN-Diensten (z.B. Online-Zeitschriftenangebot der Universitätsbibliotheken) für Bewohner von Studentenwohnheimen.  Zugang zu internen MWN-Diensten über das Internet.

7.3.1 Technik Die VPN-Hardware besteht aus zwei Appliances vom Typ „Adaptive Security Appliance ASA5585-X“, vier Appliances vom Typ „Adaptive Security Appliance ASA5540“ und einer Appliance vom Typ „VPN- Concentrator 3030“ der Firma Cisco. Der VPN-Concentrator 3030 dient für die Anbindung von einigen externen Einrichtungen außerhalb des MWN über IPsec LAN-to-LAN Tunnel. Die vier der sechs ASA- Appliances sind zu einem VPN-Cluster zusammengefasst, zwei werden für Tests und für Beta-Software verwendet. 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) angeschlossen. Die zwei ASA5585-X sind mit jeweils 10GBits/s angeschlossen, die vier ASA5540 mit jeweils 1GBit/s. Die verfügbare Bandbreite für verschlüsselte Verbin- dungen (AES/3DES) beträgt 50MBit/s beim VPN-Concentrator 3030 350MBit/s pro ASA5540 und 1GBit/s bei den ASA5585-X. Authentifizierung, Autorisierung der Nutzer sowie Accounting werden über das RADIUS-Protokoll abgehandelt.

7.3.2 VPN-Software Berechtigte Nutzer können die aktuellen Versionen der VPN-Software vom Web- oder VPN-Server des LRZ herunterladen. Für Linux und Mac OS X stehen neben den Cisco-IPsec und AnyConnect-Client der „Open Source“ 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. Debian, SuSE und Ubuntu enthalten.

7.3.3 Telearbeitsplätze von LRZ-Mitarbeitern Mitarbeiter, die Telearbeit machen, nutzen die internen Ressourcen des LRZ während ihrer Arbeit zu Hause. Dazu erhalten sie einen VPN-Router, an den sie Rechner und VoIP-Telefon anschließen können. Der VPN-Router ist so konfiguriert, dass er automatisch eine Verbindung zum VPN-Server im LRZ auf- baut. Über diese Verbindung, einen verschlüsselten IPsec LAN-to-LAN Tunnel, wird ein Subnetz mit der Subnetzmaske 255.255.255.248 geroutet. Damit stehen sechs IP-Adressen für Router, Rechner, ggf. Lap- top und IP-Telefon zur Verfügung. Bei dem VPN-Router handelt es sich um das Modell WRV54G von Linksys. Das 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.

7.3.4 Entwicklung des Datenverkehrs über die VPN-Server Im Mittel stieg der Durchsatz im Vergleich zum Vorjahr um 33%. In Spitzenzeiten waren bis zu 5.500 Nutzer parallel angemeldet. Im Monat November, dem Monat mit dem höchsten Datenaufkommen wur-

114 Netzdienste für Endanwender den 700.000 Verbindungen aufgebaut. Der im Jahr 2009 eingeführte SSL-VPN Client (Cisco AnyConnect) hat inwischen einen Anteil von 75% aller Verbindungen erreicht.

Jahr Ausgehend Eingehend Gesamt 2005 0,7 3,2 3,9 2006 1,7 6,2 7,9 2007 3,1 11,4 14,5 2008 3,8 12,7 16,5 2009 4,6 20,7 25,3 2010 8,0 28,8 36,7 2011 11,4 44,9 56,3 2012 12,0 51,6 63,6

Tabelle 13: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November

60 Ausgehend 50 Eingehend 40 Gesamt 30

0 2005 2006 2007 2008 2009 2010 2011 2012

Abbildung 68 Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November

Jahresbericht 2012 des Leibniz-Rechenzentrums 115

6000

5000

4000

3000

2000

1000

0 Jan Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez

Abbildung 69 Anzahl der gleichzeitig an den VPN-Servern angemeldeten Nutzer

70.000 Eingehend 60.000 Ausgehend Summe 50.000

40.000

30.000

20.000

10.000

0 Jan Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez

Abbildung 70 VPN-Datenverkehr pro Monat

7.4 Modem / ISDN Die Anzahl der Wählverbindungen hat sich im Laufe des Jahres 2012 weiter verringert. Die Anzahl der Telekom-Kunden ging auf ca. 20 (2011: 40), die der M-net-Kunden auf ca. 25 (2011: 35) zurück. Da für den Dienst so gut wie keine Arbeit anfällt, wird er trotz der geringen Nutzung weiter zur Verfü- gung gestellt. Unterstützung bei Problemen wird aber keine mehr angeboten. Das folgende Diagramm zeigt für das 2. Halbjahr 2012 die maximale Anzahl gleichzeitig aktiver Verbin- dungen pro Woche, aufgeschlüsselt nach den jeweiligen Rufnummern.

116 Netzdienste für Endanwender

Abbildung 71 Maximale Anzahl von Verbindungen pro Rufnummer

Abbildung 72 Verteilung der Modem/ISDN-Verbindungen im Wochenverlauf

Jahresbericht 2012 des Leibniz-Rechenzentrums 117

8 Virtual Reality und Visualisierung Im Januar 2012 wurde mit den Baumaßnahmen zum Innenausbau und der Medientechnik des Zentrums für Virtuelle Realität und Visualisierung (V2C) begonnen. Das Gerüst für die 5-seitige Projektionsinstal- lation und der Zwischenboden wurden zuerst eingebracht. Somit konnte parallel in dem nun entstandenen Untergeschoss und Obergeschoss gearbeitet werden. Der Innenausbau konnte im Mai fertiggestellt werden und die Installation frühzeitig am 20.07. geladenen Gästen demonstriert werden.

Abbildung 73 Das V2C mit seinen einzelnen Komponenten

Am 25. Oktober fand die feierliche Einweihung des V2C statt. Hierüber berichteten die Süddeutsche (27.10.2012) und das Linux Magazin (26.10.2012). Deutschlandradio Kultur strahlte in der Sendereihe Elektronische Welten am 10.12.2012 einen Bericht zum V2C aus.

8.1 Sichtbarkeit und Öffentlichkeitsarbeit Es wurde ein geladener Vortrag mit dem Thema „Developing Immersive Games with the inVRs Frame- work“ an der FH Hagenberg in Österreich sowie ein Vortrag mit dem Titel „Virtual Reality and Visuali- sation at the Leibniz Supercomputing Centre“ an der Ho Chi Minh City University of Technology in Vi- etnam gehalten. Das V2C beteiligte sich an zwei größeren Veranstaltungen, der Feier zum 50-jährigen Bestehen des LRZ und dem Tag der offenen Tür mit Führungen. Im Rahmen dieser beiden Veranstaltungen bekamen ca. 400 Gäste einen ersten Eindruck des Zentrums für virtuelle Realität und Visualisierung. Insgesamt fanden in der zweiten Jahreshälfte 27 Führungstermine statt, an denen ca. 800 Besucher das V2C besichtigten. Es wurde eine hochwertige Broschüre von 24 Seiten erstellt (Auflage 1.000 Stück), welche den Hinter- grund, die Technologien und die ersten erfolgreichen Projekte vorstellt.

118 Virtual Reality und Visualisierung

Die Onlinepräsenz des VR und Visualisierungsteams (V2T) wurde konstant mit Informationen zum Zent- rum aktualisiert und hat während der Bauphase mit dem Produktionstagebuch einen Überblick über den aktuellen Bauzustand gegeben.

8.2 Kooperationen Mit interessierten Instituten der LMU und TUM wurde der Kontakt hergestellt und die ersten Projekte konnten erfolgreich realisiert werden. Hierzu zählt beispielsweise die Darstellung und Rekonstruktion der Grabkammer von Karaburun in Zusammenarbeit mit dem Institut für Klassische Archäologie der LMU, oder die Zusammenarbeit mit dem Institut für Fördertechnik Materialfluss und Logistik, TUM, wo virtuelle Kranmodelle mit realer Steuerung kontrolliert werden. Weitere Projekte stammen aus den Bereichen der Architekturinformatik, Kunstpädagogik, Informationsvisualisierung und der Geoingenieurswissen- schaften. Bei der Umsetzung eines weiteren Projekts der Klassischen Archäologie, welches bei der Analyse und beim Vergleich Antiker Statuten unterstützt, wurde erstmals auf internationaler Ebene mit der University of Tokyo und der Tohoku University in Japan sowie der University of California in Berkeley, USA, zu- sammengearbeitet. Viele weitere Projekte und Forschungsanträge befinden sich in der Planungs- und Umsetzungsphase. Insgesamt wurden 2012 Kooperationsgespräche mit über 20 Instituten der Münchner Universitäten ge- führt.

Abbildung 74 Die Rekonstruktion der Grabkammer von Karaburun auf der Powerwall (links) und in der 5-seitigen Projektionsinstallation (rechts)

8.3 Forschung und Lehre Im Bereich Virtuelle Realität und Visualisierung wurde in Zusammenarbeit mit der LMU ein Masterar- beitsthema erfolgreich bearbeitet. Eine Bachelorarbeit wurde abgeschlossen und zwei weitere begonnen, welche voraussichtlich 2013 abgeschlossen werden. In Zusammenarbeit mit der Johannes Kepler Univer- sität Linz in Österreich wurde ein Praktikumsthema bearbeitet. Eine Lehrveranstaltung „Virtual Reality“ wurde im Sommersemester an der LMU abgehalten.

Jahresbericht 2012 des Leibniz-Rechenzentrums 119

Im Bereich der Forschung wurde in Zusammenarbeit mit dem Institut für Architekturinformatik der TUM eine Publikation bei der 12th International Conference on Construction Applications of Virtual Reality (CONVER’12) im November in Taipeh präsentiert. Des Weiteren hat sich das LRZ bei der Einreichung eines Europäischen Forschungsprojekts beteiligt. Dieses Projekt trägt den Titel Mr.SymBioMath und wurde positiv begutachtet. Der Projektstart ist für Februar 2013 geplant. Die allgemeine Aufgabenstellung des Projekts ist die Analyse von Gendaten, wobei sich das V2C hierbei mit der Visualisierung der Datensätze beschäftigt. Im Rahmen des Arbeitskreises Visualisierung, einer wissenschaftlichen Vortragsreihe rund um das Feld Virtuelle Realität und Visualisierung, fanden vier Veranstaltungen statt, in welchen internationale Gäste aus Österreich, Großbritannien und Japan von ihren aktuellen Forschungsergebnissen aus den Bereichen VR und Visualisierung berichteten.

120 IT-Service-Management

9 IT-Service-Management

9.1 IT-Service-Management: Einführung von ISO/IEC 20000 Die Zuverlässigkeit und Verfügbarkeit von IT-Services ist in erheblichem Maß von der effektiven Kom- munikation, Kooperation und Koordination zwischen den Mitarbeitern eines IT-Service-Providers abhän- gig. Ein optimales Management von IT-Diensten muss folglich über die Überwachung und Steuerung der technischen Komponenten hinausgehen 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 verschiedener so genannter ITSM-Rahmenwerke wie der IT Infrastructure Library (ITIL) oder des internationalen Standards ISO/IEC 20000. Das LRZ ist bemüht, ein Managementsystem nach ISO/IEC 20000 zu etablieren.

9.1.1 Incident-Management Für das im Vorjahr eingeführte Incident Management nach ISO/IEC 20000 lag der Fokus für das Jahr 2012 in der Etablierung eines kontinuierlichen Verbesserungsprozesses. Die mittlerweile durchschnittlich 700 erfassten Incidents pro Monat werden nun nicht mehr nur hinsichtlich der Zeit bis zur Lösung sondern auch in Bezug auf die Erstreaktionszeit überwacht. Zusätzlich werden weitere Kennzahlen erfasst und es kann mit Hilfe eines neu eingeführten standardisierten Berichtes nachgewiesen werden, dass sich die Einhaltung der Ziele für die Lösung von Incidents im Vergleich zum Vorjahr signifikant verbessert hat. Im gesamten Jahr 2012 wurden 8.605 Incidents (Falschmeldungen und Major Incidents nicht mitgerech- net) erfasst. Im Schnitt waren es also über 700 Incidents pro Monat, siehe Abbildung 75 (Zum Vergleich: 2011 wurden durchschnittlich etwas mehr als 500 Incidents pro Monat erfasst.). Diese Steigerung des Incident Aufkommens bedeutet nicht, dass sich die Servicequalität des LRZ verschlechtert hat. Die Stei- gerung hängt damit zusammen, dass durch einen einheitlichen Incident Management Prozess nun viele Incidents überhaupt erst erfasst werden und nicht am Prozess vorbei laufen. Dies wiederum gestattet eine wesentlich bessere Analyse der aufgetretenen Störungen und macht eine Verbesserung der Servicequalität wesentlich einfacher.

Abbildung 75 Verteilung des Incidentaufkommens über die Monate 2012

Jahresbericht 2012 des Leibniz-Rechenzentrums 121

Abbildung 76 Verteilung der Incident-Prioritäten

Ein weiterer Schritt zur Verbesserung der Servicequalität des LRZ wurde mit einer verstärkten Einbin- dung des Servicedesks in den Incident Management Prozess erreicht. Gezielte Schulungen sowohl im Prozess wie auch im Tool selbst hatten zur Folge, dass die Incidents durch das Servicedesk besser bewertet und auch umfassend koordiniert werden können. Die Mitarbeiter des LRZ selbst konnten dadurch entlastet werden und sich verstärkt ihren Kernaufgaben widmen. Abbildung 76 zeigt hierbei die Vertei- lung der Priorität der Incidents. Dadurch, dass die Priorität der Incidents bereits von dem Servicedesk korrekt bestimmt werden kann, ist es den Mitarbeitern möglich, ihre Zeit besser einzuteilen und nicht bei jedem Eintreffen eines Incidents sofort ihre Arbeit unterbrechen zu müssen.

9.1.2 Weitere ITSM-Prozesse Ein Großteil der Personalkapazitäten wurden 2012 für die Einführung eines Configuration Managements und für die Vereinheitlichung des Change Managements beansprucht. Diese beiden Prozesse wurden forciert vorangetrieben, so dass diese nun kurz vor dem „Go-Live“ stehen. Kernaufgabe hierbei ist zum einen die Einführung einer zentralen CMDB. Da die Integration bestehender Informationssysteme sich aufwändiger erwies als erwartet, musste ein wesentlicher Aufwand hierfür investiert werden. Aber auch im Change Management mussten große Anstrengungen unternommen werden, um das Tool iET-ITSM anzupassen und für die Anforderungen der existierenden Verfahren am LRZ vor- zubereiten. Weitere Aktivitäten, welche die Bemühungen im Bereich IT Service Management seit Ende 2009 ergän- zen, finden im Informationsmanagement statt. Hier wurde ein Arbeitskreis gebildet, welcher sich zur Aufgabe gemacht hat, das Management der Informationen - im Speziellen der Dokumentationen - im LRZ zu verbessern. Abteilungs- und Tool-übergreifende Strukturen sollen eingeführt werden, so dass eine einheitliche und übersichtliche Informationslandschaft entstehen kann. Hierfür wurde 2012 der „Dienstleistungsbaum“, welcher als zentrale Struktur für die Informationslandschaft dient und einen ge- steigerten Wiedererkennungswert für die Kunden des LRZ bietet, kontinuierlich verbessert und auf zentrale Informationsquellen angewendet. Ein weiterer Meilenstein in Richtung „Abteilungsübergreifende Strukturen“ wurde mit der Einführung eines zentralen Wiki-Systems erreicht. Eine Vielzahl an bisherigen Wikis, die nur innerhalb einzelner Gruppen oder Abteilungen verwendet wurden, konnten durch ein zentral verwaltetes „LRZ-Wiki“ abgelöst werden.

9.1.3 Sonstige Aktivitäten Parallel zu den Einführungsprojekten wird am LRZ auch weiterhin das Zertifizierungs- und Lehrgangs- konzept für IT-Service-Management nach ISO/IEC 20000 erfolgreich fortgesetzt. Nachdem in den letzten Jahren das Schulungsprogramm sehr erfolgreich gelaufen ist, beschränkt sich mittlerweile die Ausbildung zum Foundation-Zertifikat nach ISO/IEC 20000 größtenteils auf neu hinzu gekommene Mitarbeiter.

122 IT-Service-Management

9.2 Service-Management-Plattform Action Request System Das Action Request System (ARS) von BMC wird am LRZ seit 18 Jahren eingesetzt. Für das Change Management, Beschaffungswesen, Asset-Management und die IP-Adressverwaltung wird weiterhin ARS eingesetzt. Die Webschnittstelle zum ARS wurde Ende August mangels Nutzung und aus Sicherheitsgründen abgeschaltet. Die User-Lizenzen wurden von 20 auf 15 reduziert, da die Incidents jetzt in iET-Solutions bearbeitet werden und die Nutzung von ARS aus diesem Grunde abgenommen hat. Das KOM-Change-Record Formular unterstützt den Change-Management-Prozess in der Abteilung Kommunikationsnetze. 2012 wurden insgesamt 1.275 (2011: 1.132) KOM-Change-Record-Tickets abgeschlossen.

9.3 Servicedesk Der Servicedesk ist die Schittstelle zu Kunden und Anwendern der IT-Dienste des LRZ. Aufgabe des Servicedesk ist es, die Serviceverantwortlichen, Administratoren und Fachleute am LRZ von 1st Level Support-Anfragen soweit wie möglich zu entlasten und die Anfragen so aufzubereiten, dass der 2nd Level Support umgehend mit der Problemlösung beginnen kann. Das gilt für die bestehenden Services, als auch für alle neu aufzubauenden Dienste mit neuen Kundenkreisen. Der Servicdesk ist auch der primäre Integ- rationspunkt für die Incident-Management-Prozesse im Rahmen von ISO 20000. Er sorgt als Eigentümer eines Großteils der Tickets für eine kontinuierliche Bearbeitung. In einem Team von studentischen Hilfkräften mit hoher Fluktuationsrate sind diese hoch gesteckten Ziele nur durch permanente interne Schulungen zu erreichen. Als Hilfsmittel für das Wissensmanagement und den KnowHow-Transfer wird ein Sharepoint-basiertes Portal eingesetzt, in dem die Servicedesk-Mitarbeiter wichtige Informationen sammeln, strukturiert hin- terlegen und pflegen. Unterstützend kommen laufend Schulungen zu den Services, den ITSM-Prozessen und den ITSM-Werkzeugen hinzu. Insgesamt ist das große Interesse und Engagement aller Beteiligten, insbesondere auch unserer studentischen Hilfskräfte, sich mit neuen Themen auseinanderzusetzen und essentielle Rollen im Rahmen der IT- Serivcemanagement-Prozesse zu übernehmen, sehr erfreulich und die Basis aller Verbesserungsmöglich- keiten.

Jahresbericht 2012 des Leibniz-Rechenzentrums 123

10 Informationen und Weiterbildung

10.1 Kurse und Veranstaltungen Das LRZ bietet seinen Kunden regelmäßig an die 20 Kurse an, die sich in die Bereiche PC-Software, Hochleistungsrechnen und weitere Veranstaltungen einteilen lassen. Die in Tabelle 14 bis 16 aufgeführten Veranstaltungen wurden von mehr als 1.000 Teilnehmern besucht. Zusätzlich haben externe Anbieter weitere Kurse angeboten.

10.1.1 Kursübersicht, Statistik 2012 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 Kur- sen zu PC-Software ist der Unterschied zwischen der Zahl der Anmeldungen und der Zahl der Teilneh- mer nach wie vor groß. Es zeigte sich, dass das Interesse an Kursen zu den aktuellen Microsoft Office-Produkten nach wie vor groß war. Dabei wird vom Kursprogramm des LRZ 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 „über- sprungen“. 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. Viele PC-Kurse verwenden als Kursunterlage Handbücher vom RRZN in Hannover. Diese Schriften sind oftmals verbilligte Nachdrucke der Schulungsunterlagen vom Herdt-Verlag. Die Ersparnis ist besonders für Studenten von Bedeutung. Eine regelmäßig aktualisierte Liste der verfügbaren Schriften ist ebenfalls im Internet vorhanden.

Kurse zu PC-Software 2012 Dauer Anzahl Teilnehmer Kurstitel Stunden Kurse angemeldet Word 2010 (Kompaktkurs) 9 3 77 Excel 2010 (Kompaktkurs) 9 3 228 Excel 2010 (Fortsetzungskurs) 9 3 129 PowerPoint 2010 (Kompaktkurs) 9 3 88 Access 2010 (Kompaktkurs) 5 2 100 Photoshop Elements 10 Einführungskurs 9 3 68 Einführung in SPSS 6 2 38 Insgesamt: 56 19 728

Tabelle 14: Kurse zu PC-Software

124 Informationen und Weiterbildung

Hochleistungsrechnen 2012 Dauer Anzahl Teilnehmer Kurstitel Stunden Kurse angemeldet Amsterdam Density Functional 6 1 13 Accelrys MatScience Workshop 8 1 21 Big Data Analysis 7 1 9 Data Visualisation for Publications and Websites 7 1 19 Programming with Fortran 9 1 23 Advanced Fortran Topics 9 1 14 10th VI-HPS Workshop 9 1 27 Introduction to large scale program development and debugging on SuperMUC with DDT 7 1 8 Introduction to SuperMUC 9 1 29 Node-Level Performance Engineering 8 1 69 Parallel Programming on High Performance Systems 9 1 3 Insgesamt: 88 11 235

Tabelle 15: Hochleistungsrechnen

Weitere Veranstaltungen 2012 Dauer Anzahl Teilnehmer Kurstitel Stunden Kurse angemeldet Besichtigung von Rechner-Räumen des LRZ 3 1 39 Besichtigung des Zentrums für virtuelle Realität und Visualisierung 3 1 52 Insgesamt: 6 2 91

Tabelle 16: Weitere Veranstaltungen

Auch im Jahr 2012 wurde – zusätzlich zum regulären Kursprogramm – die vorhandene, moderne Infra- struktur 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.

10.1.2 Kurse und Ausbildung im Bereich Hochleistungsrechnen

10.2 Vorträge „Schattenseiten des Internet“ Die nach wie vor große Zahl der Missbrauchsfälle im Münchner Wissenschaftsnetz (v.a. mit Schädlingen infizierte Rechner) zeigt, 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 www.lrz.de/services/security/gefahren/).

Jahresbericht 2012 des Leibniz-Rechenzentrums 125

Abbildung 77 Themenbild des Vortrags

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. Dabei stehen für Eltern und Lehrer einerseits und Jugendliche ab 11 Jahren andererseits angepasste Varianten zur Verfügung. Die Schwerpunkte des Vortrags behandeln Problembe- reiche, die Kinder, Jugendliche und Erwachsene gleichermaßen betreffen: Alle Nutzer des Internet unterliegen mehr oder weniger umfangreichen rechtlichen Pflichten. Ein Verstoß dagegen (z.B. gegen das Recht am eigenen Bildnis oder das Urheber-Recht) kann empfindliche Konsequenzen haben (z.B. Ab- mahngebühren von mehreren Hundert Euro). Leider kennen praktisch keine Jugendlichen und nur wenige Erwachsene diese Art von Gefahren. Im Jahr 2012 wurden durch diesen Dienst des LRZ an der Allgemeinheit knapp 700 interessierte Zuhörer erreicht. Dabei wurden u.a. bei drei Gymnasien jeweils komplette Schülerjahrgänge informiert. Zwei Veranstaltungen wurden für Erwachsene (Eltern, Lehrer und Studenten) und ältere Jugendliche durchge- führt.

10.3 Öffentlichkeitsarbeit Das herausragende Ereignis am LRZ aus öffentlicher Sicht war die Feier anlässlich des fünfzigjährigen Bestehens des LRZ und der Inbetriebnahme des neuen Höchstleistungsrechners „SuperMUC“ am 20. Juli 2012, worauf bereits im Überblick eingegangen wurde. Darüber wurde in sehr vielen Medien z.T. sehr ausführlich berichtet. Allein fünf Fernsehteams berichteten direkt aus dem SuperMUC u.a. für den Bayerischen Rundfunk, die „heute“-Sendung des ZDF und die „Tagesschau“ der ARD. Die Aufnahmen eines Teams der Nachrichtenagentur Reuters fanden sich auf sehr vielen Webseiten wie spiegel online u.ä. Auch in Rundfunk und Printmedien wurde ausführlich über SuperMUC und LRZ berichtet, allen voran in der Süddeutschen Zeitung, die zusätzlich zur aktuellen Berichterstattung der Geschichte des LRZ eine ganze Seite widmete. Sogar Fernsehteams aus Österreich und Russland berichteten. Neben vielen Interviews verschiedenster Medien vor allem im Zusammenhang mit der Nominierung des SuperMUC als schnellstem Rechner Europas führte der Bayerische Rundfunk am 28. November ein sehr

126 Informationen und Weiterbildung ausführliches Gespräch mit dem Vorsitzenden des Direktoriums, Prof. Dr. Arndt Bode (Ausstrahlung in der Reihe BR-alpha Forum im Frühjahr 2013). Insgesamt kann man feststellen, dass das LRZ im Jahre 2012 so intensiv in der Öffentlichkeit präsent war wie nie zuvor. Besonders erfreulich ist die Tatsache, dass alle Berichte, Interviews usw. positiv waren. Anlässlich der Feier am 20. Juli widmete „Akademie aktuell“ die gesamte Ausgabe dem Höchstleistungs- rechnen, SuperMUC und dem LRZ. Am 22. Februar besuchte MdB Florian Hahn das LRZ. Am 15. April 2012 erschien in der Neuen Zürcher Zeitung (NZZ am Sonntag) die ausführliche und exzellente Reportage „Vorbild Gehirn“ von Andreas Hirstein über die Herausforderungen an Supercomputer im Vergleich zum menschlichen Gehirn. Auch über die Eröffnung des Zentrums für Virtuelle Realität und Visualisierung V2C (v2c.lrz.de) am 25. Oktober 2012 berichteten die Medien. Etliche Firmen erstellten „Success Stories“ über den Einsatz ihrer Produkte am LRZ, u.a. fertigten IBM und SUSE Videos für YouTube und andere öffentlich zugängliche Webseiten an. Auch im Rahmen eines europaweiten Videos für PRACE war SuperMUC am LRZ ein Hauptdrehort. Am 18. Oktober konnte das LRZ seine Dienstleistungen für Studenten wieder an einem Infostand bei der Erstsemesterbegrüßung der LMU vorstellen. Beim „Tag der offenen Tür“ am 27. Oktober 2012 besichtigten etwa 1.500 Besucherinnen und Besucher das LRZ und sein neues Zentrum für Virtuelle Realität und Visualisierung V2C. Erstmals wurden auch englischsprachige Führungen angeboten, die sehr gut angenommen wurden. Insgesamt nutzten im Be- richtsjahr über 3.500 Besucherinnen und Besucher bei ca. 85 Führungen die Gelegenheit, das LRZ kennen zu lernen. Das Erscheinungsbild der Webseiten des LRZ wurde komplett neu gestaltet. Der ständig wachsenden Zahl von Studenten aus dem Ausland an den Münchner Universitäten trägt das LRZ dadurch Rechnung, dass viele seiner Webseiten inzwischen auch auf Englisch verfügbar sind, vor allem die Seiten, die den Einstieg in das Studium und die Nutzung der Dienste des LRZ erst ermöglichen. Das LRZ gibt gemeinsam mit dem Jülich Supercomputing Centre und dem Hochleistungsrechenzentrum Stuttgart zweimal im Jahr anlässlich der Supercomputing-Konferenzen SC und ISC die Zeitschrift „inSi- DE – Innovatives Supercomputing in Deutschland“ mit Beiträgen über Projekte, die auf dem Höchstleis- tungsrechner des LRZ bearbeitet wurden, heraus. Zusätzlich liefert das LRZ Beiträge zum Infobrief der Gauß-Allianz e.V. Anlässlich der Außerbetriebnahme des vorherigen Höchstleistungsrechners SGI Altix 4700 erschien ein Berichtsband über die darauf bearbeiteten wissenschaftlichen Projekte. Darüber hinaus erschien monatlich der LRZ-Newsletter, in dem u.a. Termine, Veranstaltungen, Kurse und Stellenangebote mitgeteilt wurden und der über eine Mailingliste verteilt sowie im Web angeboten wird. Dort ist auch ein Newsletter-Archiv verfügbar. Ferner stehen Faltblätter zur Verfügung, die sich auf Deutsch und Englisch an die allgemeine Öffentlich- keit wenden oder speziell für Studenten die Dienstleistungen des LRZ vorstellen. Besonders die Faltblät- ter für Studierende in Deutsch und Englisch, die in den größeren Bibliotheken der Universitäten ausgelegt werden, fanden viele Abnehmer. Anlässlich der Einweihungsfeier wurde die Darstellung des LRZ in einer Postergalerie aktualisiert und überarbeitet. Auch diese ist auf dem Webserver des LRZ verfügbar (http://www.lrz.de/wir/postergalerie/). Für die Zusammenarbeit mit den Medien erwies es sich als unverzichtbar, ihnen einen festen Ansprech- partner (http://www.lrz.de/presse/) nennen zu können.

Jahresbericht 2012 des Leibniz-Rechenzentrums 127

11 Software-Bezug und Lizenzen Mit der Bündelung der Nachfrage über Instituts- und Hochschulgrenzen hinweg wird auch Verhand- lungsmacht gebündelt. So können oft wesentlich günstigere Konditionen für den Bezug von Lizenzen für Forschung und Lehre erreicht werden. Die Endkunden in den Instituten sparen dadurch nicht nur Zeit, sondern vor allem viel Geld. Das LRZ verhandelt deswegen, wo möglich, in Absprache oder in Koopera- tion mit Instituten und Hochschulen, teilweise aufs MWN beschränkt, teilweise überregional, geeignete Abkommen mit Händlern und Herstellern. Welche Software von welchen Nutzern zu welchen Konditio- nen über das LRZ bezogen werden kann, ist auf der Webseite www.lrz.de/services/swbezug dargestellt.

11.1 Bundesweiter Rahmenvertrag für Microsoft-Lizenzen Mit Microsoft Irland wurde zum 1. Mai 2012 erstmals ein bundesweit gültiger Rahmenvertrag über die Lizenzierung von Software auf Subskriptionsbasis abgeschlossen. Er wurde gemeinsam mit dem Arbeits- kreis Software-Lizenzen des ZKI vorbereitet. Alle deutschen Hochschulen können diesem bis April 2017 gültigen Vertrag eigenständig beitreten. Er räumt Einstiegshürden für kleinere Hochschulen aus dem Weg und enthält hohe Rabatte und nützliche Zusatzvereinbarungen. Bestehende Landesverträge werden nach und nach in diesen Bundesvertrag überführt. Der im Vorjahr abgeschlossene bayerische Landesvertrag, der in wesentlichen Punkten die Vorlage für den bundesweiten Vertrag bildete, läuft weiter, jeder teil- nehmende Hochschule kann selbst kalkulieren, ob sich für sie ein Umstieg während der Laufzeit lohnt. Beim Umstieg kann die Bindung an den für den Landesvertrag im Vorjahr ausgeschriebenen Handels- partner und an die seinerzeit festgelegte Preisliste erhalten bleiben.

11.2 Überregionaler Rahmenvertrag zum Bezug von Beratungs- und Supportdienstleistungen zu Microsoft-Produkten Im Dezember konnte zwischen dem LRZ und Microsoft Deutschland ein Vertrag, der den Universitäten und Hochschulen in Bayern günstigen Zugang zu Support- und Beratungsleistungen der Firma Microsoft verschafft („Premier Support“), abgeschlossen werden. Der Vertrag sieht den solidarischen Austausch von Knowhow und Erfahrungen zwischen den Hochschulen vor. So wird auch kleinen Standorten der ansonsten unerschwingliche Zugang zu Dienstleistungen des Premier-Support Programms von Microsoft ermöglicht. Teilnehmer sind zunächst bayersiche Hochschulen. Künftig kann jede Hochschule im Bun- desgebiet eigenständige Beitritte unter diesem Vertrag abschließen.

11.3 Bayernweiter Mietvertrag für Adobe-Lizenzen Mit Adobe Irland wurde im März 2012 ein Vertrag über die Lizenzierung von Acrobat Pro auf Subskrip- tionsbasis abgeschlossen („Adobe TSL“), über den sich bayerische Hochschulen versorgen können. Mit der Vergabestelle der Universität Würzburg wurde für die teilnehmenden Hochschulen ein Handels- partner ausgeschrieben, den Zuschlag bekam die Firma Cancom.

11.4 Vereinfachung der Versorgung mit ESRI-Lizenzen an der TU Mün- chen Die Versorgung der TU München mit Lizenzen aus dem ESRI-Landesvertrag des LRZ konnte vereinfacht werden: die Institute der TU müssen nun nicht mehr einzeln individuelle Bestellungen beim LRZ vornehmen, stattdessen wird eine flächendeckende Vollversorgung („Flatrate“) ermöglicht. Die TU beteiligt sich mit einem festen Betrag an den Kosten des Landesvertrages.

128 Software-Bezug und Lizenzen

11.5 Vereinfachung der Versorgung mit Mathematica-Lizenzen an der LMU München Auf ähnliche Weise konnte die Versorgung der Physik-Fakultät der LMU mit Mathematica-Lizenzen in ein Flatrate-Modell überführt werden (wobei in diesem Fall die Physik selbst direkt mit dem Handels- partner abrechnet).

11.6 Weitere laufende Verhandlungen und Planungen Für das erste Halbjahr 2013 geplante Aktivitäten, die schon 2012 begonnen wurden, beinhalten u.a. die Vorbereitung eines bundesweiten Rahmenvertrags für Adobe-Mietlizenzen nach dem Vorbild des Micro- soft-Bundesvertrags und des Adobe-Landesvertrags (beides siehe oben). Der Novell-Landesvertrag für Bayern endet im Oktober 2013 und muss sowohl mit dem Anbieter als auch im Innenverhältnis der bayerischen Hochschulen neu verhandelt werden.

11.7 Tagesgeschäft

11.7.1 Abläufe und Änderungen bei der Versorgung der Kunden des LRZ Das LRZ stellt den Münchner Hochschulen unter anderem Kauflizenzen aus den Bereichen  Microsoft-Lizenzen im Rahmen der Select-Plus-Verträge  Adobe- und Corel-Bestellungen im Rahmen des Adobe CLP-Vertrags zur Verfügung. Dies sind bisher die umsatzstärksten Bereiche. Wo es sinnvoll ist, eine flächendeckende Pauschalversorgung mit Mietlizenzen einzuführen, sollte das auch gemacht werden. Dadurch kann der anfallende Arbeitsaufwand sowohl in den Instituten als auch im LRZ reduziert werden. Der mit Kaufli- zenzen erzielte Umsatz ist also kein Erfolgsindikator, im Gegenteil sind etwa bei den Microsoft- Kauflizenzen sinkende Umsatzzahlen sogar Folge der Verbesserung der Versorgungssituation (die TUM ist im Sommer 2011 dem vom LRZ abgeschlossenen bayernweiten Mietvertrag für Microsoft-Lizenzen beigetreten und musste daher in 2012 nur noch Serverprodukte über das Select-Plus Programm kaufen). Bei Bestellungen zu Microsoft und Adobe/Corel-Kauflizenzen kümmert sich das LRZ im Tagesgeschäft lediglich um Authentifizierung/Autorisierung der Besteller, Verteilung der Software, Beratung und Un- terstützung bei der Bestellung, Lizenzierung und Aktivierung. Die kaufmännische Abwicklung erfolgt über Handelspartner. Dabei kommen jährliche Umsätze im sechsstelligen Bereich zustande. Die nachfolgende Tabelle listet die wertmäßig umsatzstärksten Softwarepakete (nur Kauflizenzen) auf. Miet- und Subskriptionsmodelle (SPSS, Matlab, Novell, SAS) sowie Flatrate Verträge (ESRI, Sophos) werden nicht in dieser Tabelle erfasst.

Hersteller / Beschreibung Lizenzzahlen 2012 Bruttowert der Name 2012 beschafften Lizenzen Microsoft Applikationen, Sys- 13.568 320.155 € tem- und Server- Software Adobe und Corel Acrobat, Photoshop, ca. 3.300 382.617 € GoLive, Illustrator, Premiere etc., Corel Grafiksoftware Endnote Literaturverarbeitung 99 8.079,- € Systat Datenanalyse und 48 14.246,- € Datenpräsentation

Jahresbericht 2012 des Leibniz-Rechenzentrums 129

Bei den meisten anderen Produkten tritt das LRZ in Vorleistung und beteiligt die Institute an den Kosten:  SPSS: im MWN im oberen fünfstelligen Bereich, bayernweit deutlich über 100.000 Euro  Matlab: der Umsatz im MWN erreichte 2012 einen niedrigen sechsstelligen Eurobereich.  Bei etlichen weiteren Produkten lagen die Umsätze im fünfstelligen Bereich. Für Einrichtungen mit zentralem Einkauf besteht die Möglichkeit, die am meisten nachgefragten Kaufli- zenzen beim LRZ online zu bestellen. Zu diesen Einrichtungen zählen die Münchner Universitätsklini- ken, die Universität Augsburg, einige Hochschulen aus dem südbayerischen Raum sowie einige kleinere Einrichtungen. Produkte aus Landesverträgen (Novell, Sophos, ESRI, Secunia) werden den bayerischen Universitäten und Hochschulen nach einem festen Kostenschlüssel bereitgestellt, daher gibt es an dieser Stelle keine Umsatzzahlen (ESRI-Produkte werden an der LMU teilweise noch mit den Instituten einzeln abgerech- net). Produkte aus Landesrahmenverträgen (Microsoft EES, Adobe TSL) werden direkt zwischen den ausgeschriebenen Händlern und den Lizenznehmern abgewickelt, ohne dass das LRZ involviert werden muss.

11.7.2 Routinemäßige Verlängerung und Ausbau bestehender Verträge 2012 wurden mehrere auslaufende Verträge abgelöst oder planmäßig verlängert (Labview, SAS, Ansys, Novell, NAG, Scientific Workplace). Die Verlängerung des Landesvertrags zu ArcGIS Geoinformations- system-Software mit der Firma ESRI und des Bundesvertrags über Adobe Kauflizenzen („CLP“) erfolgten zum Jahreswechsel 2012/2013.

11.7.3 Betrieb von Lizenzservern für Kunden des LRZ Das LRZ betreibt derzeit für ca. 30 unterschiedliche Softwarepakete Lizenzserver, die für die Benutzer im MWN Netzwerklizenen zur Verfügung stellen. Das angebotene Spektrum der Netzwerklizenzen beinhaltet vor allem technisch wissenschaftliche Software (Matlab, Mathematica, Ansys, Patran, etc). Für Kurse und Praktika in den CIP-Pools der berechtigten Einrichtungen im MWN werden die Teaching Lizenzen der FE-Software Ansys über den Lizenzserver vom LRZ kostenfrei zur Verfügung gestellt. Der zentrale Betrieb der Lizenzserver am LRZ erspart den Mitarbeitern an den Lehrstühlen und Instituten im MWN den redundanten Betrieb eigener Lizenzserver und damit viel Arbeit. Im Bedarfsfall unterstützt das LRZ die Anwender bei der Anbindung ihrer Rechner an die Lizenzserver am LRZ.

130 Benutzerverwaltung und Verzeichnisdienste

12 Benutzerverwaltung und Verzeichnisdienste

12.1 Benutzerverwaltung für LRZ-Dienste Im Zentrum der Benutzerverwaltung steht das LRZ-Identity-Managementsystem (LRZ-SIM) mit den LRZ-Verzeichnisdiensten als Basis. Nach einem Überblick über die derzeit vergebenen LRZ-Kennungen und ihre Verteilung auf die Hochschulen und LRZ-Plattformen wird über Stand und Entwicklung von LRZ-SIM im Organisations- und Frontend-Bereich, in den angebundenen Diensten und Plattformen sowie im SIM-Serverbetrieb berichtet. Es folgen die Weiterentwicklungen bei der Verzeichnisdienste- Kopplung mit den beiden Münchner Universitäten und beim MWN Active Directory als zentralem Infra- strukturdienst im gesamten Münchner Wissenschaftsnetz. Die Neuerungen in der Authentifikations- und Autorisierungsföderation des DFN (DFN-AAI), in der das LRZ als Dienstleister und sogenannter Identi- ty-Provider für die LMU und TUM fungiert, schließen dieses Kapitel ab.

12.1.1 Für LRZ-Systeme vergebene Kennungen

12.1.1.1 An Hochschuleinrichtungen vergebene Kennungen Die folgende Tabelle gibt einen Überblick über die vom LRZ an Hochschuleinrichtungen vergebenen Berechtigungen, und zwar pro Dienst bzw. Plattform und mit Stand von Ende 2012. Für die LMU und die TU München sind dabei außer den via Master User vergebenen Berechtigungen auch die Kennungen aufgelistet, die direkt an den Hochschulen vergeben und via CampusLMU bzw. TUMonline importiert wurden.

ortal)

Cluster

P Einrichtung -

/ WLAN -

Mail

TSM

NeSSI

Speicher

WebDNS

Exchange

Webserver

PC/Online

persönliche

Homepages

(NV

Linux

VPN

Leibniz-Rechenzentrum 693 345 375 1.167 226 21 102 91 37 55 Bayer. Akad. der Wissenschaften 401 378 72 367 – 25 12 23 5 – LMU München 12.196 10.451 1.110 2.904 817 127 369 478 151 54 von CampusLMU importiert 19.665 – – 2.710 – – – – – – TU München 9.042 9.139 – 469 961 523 123 920 422 173 von TUMonline importiert 19.447 – 22.277 19.447 – – – – – – Hochschule München 420 383 – 9 39 – 74 4 4 2 andere bayerische Hochschulen 498 320 – 183 208 12 10 10 9 3 Öffentlich-rechtliche Einrichtungen 3.690 3.589 – 1.622 26 48 58 70 44 14 sonstige Einrichtungen 26 1 – – 14 – 1 1 3 – Grid-Kooperationsprojekte – – – – 1.729 – – – – – HPC-Projekte 190 16 – 37 152 – – 7 – – Gesamt 66.268 24.622 23.834 28.915 3.946 756 749 1.604 675 301

Tabelle 17: Vergabe von Kennungen für LRZ-Plattformen

Nicht in der Tabelle enthalten sind die Kennungen für den Höchstleistungsrechner, da es hier häufig Ko- operationen gibt und daher keine klare Zuordnung zu einer Einrichtung möglich ist. Ende 2012 waren für diese Rechner insgesamt 3.914 Kennungen vergeben, davon 1.673 für Projekte aus dem Grid-Bereich.

Jahresbericht 2012 des Leibniz-Rechenzentrums 131

12.1.1.2 An Studenten vergebene Kennungen An der Ludwig-Maximilians-Universität und der Technischen Universität werden Kennungen für Studen- ten direkt an den Hochschulen vergeben und anschließend von dort ans LRZ übernommen (via Cam- pusLMU bzw. TUMonline). Für Studenten anderer Münchner Hochschulen erfolgt die Vergabe individuell und direkt durch das LRZ. Ende 2012 hatten gut 86.000 Studenten eine Kennung, die u.a. für die Dienste VPN/WLAN, Mail und PC/Online-Speicher genutzt werden konnte. Hier die Aufteilung auf die Hochschulen mit den meisten Kennungen:

Anzahl Hochschule Kennungen Ludwig-Maximilians-Universität München 49.460 Technische Universität München 34.890 Hochschule für Musik und Theater München 1.444 Hochschule für Fernsehen und Film München 289 Akademie der Bildenden Künste München 122 Hochschule für Philosophie München 46 Verwaltungs- und Wirtschaftsakademie München 21 FernUniversität Hagen 19 Hochschule für Politik München 21 sonstige Hochschulen 67 Gesamt 86.379

Tabelle 18: Vergabe von Kennungen an Studenten

12.1.2 Identity Management und Verzeichnisdienste Das LRZ Identity-Management-System (LRZ-SIM) basiert auf einem Cluster von Verzeichnisdiensten (Novell eDirectory und OpenLDAP), deren Datenbestände durch Konnektoren (sog. Novell IDM- Treiber) live synchronisiert, transformiert und in die LDAP-Authentifizierungsserver sowie in die direkt angebundenen Plattformen provisioniert werden. Als universelles Webfrontend dient das LRZ Id-Portal (https://idportal.lrz.de), sowohl für die Benutzer (Self Services) als auch für die Master User, die LRZ- Betreuer, den Servicedesk und Administratoren.

12.1.2.1 Neuerungen in der Benutzerverwaltung und Organisation Die wichtigste Entwicklung in LRZ-SIM war die technische Umsetzung der neuen LRZ- Passwortrichtlinie. Diese Richtlinie ist seit Anfang 2012 für LRZ-Mitarbeiter und seit Juni 2012 für alle LRZ-Benutzer bindend. Neben der nun erzwungenen Passwort-Mindestqualität sind der regelmäßige automatische Passwortverfall sowie der Änderungszwang von Startpasswörtern die wichtigsten Neuerun- gen. Kennungen mit verfallenem Passwort bzw. Startpasswort unterliegen einer technischen Sperre, die die Anmeldung an allen Authentifizierungsservern blockiert (siehe Abbildung 78). Ausgenommen von der LRZ-Passwortrichtlinie sind die von LMU und TUM importierten Kennungen, die der Passwortricht- linie der jeweiligen Hochschule folgen, sowie die in Grid-Projekten angesiedelten Kennungen, für die ein gültiges Passwort aufgrund von zertifikatsbasierter Authentifizierung nicht zwingend notwendig ist. Im Id-Portal waren dazu umfangreiche Erweiterungen sowohl in den Login-Seiten als auch in den Self Ser- vices erforderlich, um die Änderungen von Start- und verfallenen Passwörtern zu erzwingen. Hinzu kamen in fast allen Dienstebenen des Id-Portals zusätzliche Anzeigen und Übersichten zu Status, Ände- rungs- und Verfallsdatum von Passwörtern. Begleitend zur technischen Umsetzung der Passwortrichtlinie erfolgte eine vielschichtige Information von Benutzern und Master Usern.

132 Benutzerverwaltung und Verzeichnisdienste

Abbildung 78 Passwortstatus und Auswirkung auf die Authentifizierungsmöglichkeit bei den angebundenen Diensten und Plattformen

Die zentrale Benutzerverwaltung und die Betreuer am LRZ bilden den Second-Level-Support von LRZ- SIM und stehen den Master Usern und Administratoren beratend und helfend zur Seite bei Fragen und Problemen im Zusammenhang mit der Verwaltung von Projekten, Kennungen und Berechtigungen. 2012 war der Support-Bedarf besonders hoch, da es eine Vielzahl von Detailfragen und Spezialfällen im Zu- sammenhang mit der Passwortrichtlinie zu beantworten und zu lösen galt. Darüber hinaus sorgten neue Dienste für das VM-Serverhosting, neue Formen von Grid-Projekten und neue Kontingente für die Spei- cherbereiche im Linux-Cluster samt ihren unterschiedlichen technischen Auswirkungen für eine erhöhte Zahl von Benutzeranfragen.. Bei neueren Diensten wurden die Betreuer und Master User dadurch entlastet, dass dort die Plattformver- antwortlichen oder Administratoren über neue Webschnittstellen selbständig Berechtigungen vergeben können, so z.B. für die Netzverantwortlichen- und Monitoring-Portale sowie für Zugänge für Administra- toren im Web- und VM-Serverhosting-Bereich. Mit der seit 2012 vorliegenden Verfahrensbeschreibung „Identity-Management“ werden die Vorgaben des Datenschutzes umgesetzt. Da LRZ-Benutzer auf Anfrage Einblick in diese Beschreibung nehmen können, ist für sie eine kompakte Übersicht über Art, Verwendung und Sichtbarkeit ihrer persönlichen Daten in der zentralen LRZ-Benutzerverwaltung gegeben.

12.1.2.2 Erweiterungen bei der Anbindung von Plattformen und Diensten In Vorbereitung der Außerbetriebnahme des Speichersystems AFS mit seinem sehr vielschichtigen und feingranularen Berechtigungssystem wurden umfangreiche Untersuchungen über die bisherige Verwen- dung von AFS-berechtigten Kennungen angestellt. So konnten die AFS-Benutzer dann gezielt darüber informiert werden, welche Migrationswege und Ersatzsysteme (z.B. NAS) für sie zur Verfügung stehen. Im Laufe des Jahres wurden alle AFS-Berechtigungen mit Ausnahme der noch nicht migrierten virtuellen Webserver gesperrt und zum Jahreswechsel die zugehörigen AFS-Volumes endgültig gelöscht. Die Verwaltung der persönlichen Homepages, die bisher ebenfalls in AFS angesiedelt waren und deshalb migriert werden mussten, wurde in LRZ-SIM integriert. Anstelle der bisherigen Kommandozeilenschnitt- stelle können Benutzer nun bequem über das Id-Portal Homepages und Aliasnamen anlegen und löschen sowie Zertifikate für die verschlüsselte Übertragung beantragen. Sowohl das Anlegen neuer Homepages und Aliasnamen als auch die Ermittlung des belegten Speicherplatzes in den Self Services geschieht live durch Funktionsaufrufe auf den Webserver-Maschinen.

Jahresbericht 2012 des Leibniz-Rechenzentrums 133

Bei Funktionskennungen wurde das Id-Portal für die Verwaltung von shared Mailboxen unterschiedlicher Ausprägung und für deren Provisionierung nach Exchange erweitert. Es fehlen nun noch Funktionsobjek- te für Exchange-Verteiler. Für deren Konfiguration und Verwaltung gibt es jedoch ein detailliertes Im- plementierungskonzept, das 2013 umgesetzt werden kann. Für den autorisierten Mailversand wurde in den Authentifizierungsservern ein eigener Verzeichniscontai- ner namens Postouts eingeführt, den ein Loopback-Treiber aus den Containern der verschiedenen Mail- systeme provisioniert. Die für den autorisierten Mailversand wichtige Vervollständigung des Datenbe- stands um Funktionsmailadressen gelang durch vorausgehende Weiterentwicklungen des SIM-Schemas, der SIM-Konnektoren und des Live-Imports aller TUM- und LMU-Funktionskennungen (siehe Abschnitt 12.2). Nach Neuprogrammierung des Webformulars zur Beantragung einer LRZ-Kennung für externe Studie- rende werden nun auch hier Kennungen nach dem neuen LRZ-Namensschema vergeben und direkt die SIM-Directorys statt die frühere LRZ-Oracle-Datenbank als Zwischenspeicher verwendet. Auch der jähr- liche Bulkimport der Kennungen der Studenten der Hochschule für Musik und Theater basiert nun voll- ständig auf Directorys. Zum Ende des Jahres wurde im Id-Portal die Möglichkeit für Master User geschaffen, kurzlebige WLAN- Kennungen für Gäste an den Hochschulen einzurichten, für die die herkömmliche Kennungsvergabe zu aufwändig ist. Die Konnektor-Erweiterung im Backend zum Eduroam-Active-Directory ermöglicht diesen Benutzern den tageweisen WLAN-Zugang über die bewährte Eduroam-Technik. Bei der Provisionierung des MWN-ADS wurde ein Automatismus zur Generierung von Gruppen einge- führt: Spezielle Entitlement-Werte in den Benutzerdaten regeln die Aufnahme von Kennungen in und die Entfernung aus ADS-Gruppen. Dieser Automatismus kann gewinnbringend bei weiteren AD- angebundenen Diensten zum Einsatz kommen, um den Zugang zu zielgruppenspezifischen Diensten und Systemen an den Fakultäten zu regeln. Profitieren von diesem Konzept wird zunächst die Verwaltung der VM-Infrastruktur, für die automatisch projektgebundene Gruppen von VM-Administratoren und VM- Server-Bestellberechtigten erzeugt werden. Die dafür notwendigen Erweiterungen in LRZ-SIM und im MWN-ADS-Konnektor sind weitgehend implementiert und werden Anfang 2013 produktiv geführt. Auch für die HPC-Plattformen gab es auf Seiten der Benutzer- und Projektverwaltung einige Neuerun- gen. Zunächst wurde die Migration auf einheitliche Home-Verzeichnispfade vollzogen und in LRZ-SIM abgebildet. Für das Linux-Cluster wurden in LRZ-SIM neue Kontingentierungsmöglichkeiten der HO- ME- und WORK-Bereiche eingeführt. Beim Höchstleistungsrechner SuperMUC wurden die Rechenzeit- Restkontingente des HLRB II für den SuperMUC skaliert übernommen. Die zukünftige Deprovisionie- rung der abgelaufenen HPC-Projekte und die Freigabe der von ihnen belegten Speicherbereiche unter- stützt LRZ-SIM mit neuen Verwaltungsmöglichkeiten bei Historieneinträgen. Die mySQL-Provisionierung der LRZ-SIM-Daten von HPC-Projekten und -Benutzern musste auf drei neue Datenbanken aufgeteilt werden, getrennt für den SuperMUC, das Migrationssystem SuperMIG und das Linux-Cluster. Diese Datenbanken dienen als Grundlage für Accounting, Antragsbearbeitung und Statistik-Generierung. Im Vorfeld der Inbetriebnahme des SuperMUC war die Planung und Inbetriebnahme von ausreichend leistungsstarken Authentifizierungsservern erfolgt, wie im folgenden Abschnitt darlegt.

12.1.2.3 Entwicklungen im Server- und Dienstbetrieb Für den IDM-Betrieb entscheidend ist die Leistungsfähigkeit der Authentifizierungsserver-Infrastruktur. Zum Aufspüren von Performance-Engpässen oder auch zum Debuggen bei Schwierigkeiten der angebundenen Dienste wurden Logfile-Auswertungsprogramme geschrieben, die die sehr rasch wachsenden LDAP-Logdateien nach Verbindungen und Benutzern gruppieren, die umfangreichen Informationen bün- deln und die nicht explizit geloggten Antwortzeiten ermitteln können. Mit diesen Tools und ihrer pipe- lineartigen Implementierung stand dann eine gute Abschätzung der LDAP-Last zur Verfügung, die vom SuperMUC zu erwarten war. Als geeignetste Basis wurden zwei Servernodes auf dem SuperMUC aus- gewählt, motiviert durch die sehr leistungsfähige Hardware einerseits und die zu erwartende extrem hohe LDAP-Last beim Start großer SuperMUC-Jobs andererseits. Mit LRZ-SIM-Unterstützung wurden auf diesen zwei Nodes OpenLDAP-Server eingerichtet, die ihre Daten durch Replikation von den SIM- OpenLDAP-Servern beziehen, wobei der Benutzerumfang auf die HPC-Kennungen eingeschränkt ist.

134 Benutzerverwaltung und Verzeichnisdienste

Die aktuelle Infrastruktur der LRZ-Authentifizierungsserver mit der Datenprovisionierung über Novell IDM-Treiber (rot Pfeile) bzw. Replikationsmechanismen (graue Pfeile) sowie die beispielhafte Anbin- dung von Diensten und Servern (unten) ist in Abbildung 79 dargestellt. Dabei ist der Serverbetrieb auf verschiedene LRZ-Gruppen verteilt: Die SIM-Server administriert das Directory-Team (gelb), die Su- perMUC-Server die Gruppe HPC (schwarz), die Active-Directory-Server die Gruppe Desktop- Management (violett), und schließlich die Service Load Balancer die Gruppe Netzbetrieb (orange).

Abbildung 79 LRZ-Infrastruktur der Authentifizierungsserver

Im SIM-Kern ist das tägliche Backup um die Erzeugung von LDIF-Dateien erweitert worden, um im Fehlerfall auch Ausschnitte des Datenbestandes restaurieren zu können. Sicherungen erfolgen sowohl auf die lokale Platte als auch in ein eigenes NAS-Volume. Die LDAP-Server-Konfigurationen werden zusätz- lich in Subversion gehalten. Auch die Konfigurationen der SIM-Webserver (Id-Server, Id-Portal, Web- services für Kennungen sowie die Shibboleth Identity-Provider) und die zeitgesteuerten Programme der zentralen Benutzerverwaltung werden auf diese Art mindestens doppelt gesichert. Die neuen, zusätzlichen Möglichkeiten des Backups ersetzen nun die in der Vergangenheit problematische TSM-Sicherung der LDAP-Server, bei denen die Größe in Kombination mit der Dynamik der eDirectory- und OpenLDAP- Datenbanken vermehrt zu Fehlern (und damit nicht brauchbaren) Backups geführt hatte. Der SIM-Monitoring-Server wurde virtualisiert, was neben Ressourcenersparnis auch eine bessere Aus- fallsicherheit und Administrierbarkeit brachte. Neue Restart-Skripte sichern die Verfügbarkeit der Moni- toring-Prozesse selbst. Die von Nagios überwachten Services wurden um dienstspezifische Tests erweitert. Die parallel laufenden, eigenentwickelten LDAP-Monitoring-Tools liefern durch neue Fehlerzu- standsspeicher zeitnäher Warnmeldungen, ohne diese Meldungen unnötigerweise zu oft zu wiederholen. Schließlich gab es noch einige Maßnahmen zur weiteren Verbesserung der Sicherheit der Server: Die AFS-Abhängigkeiten, die naturgemäß bei den SIM-Servern besonders ausgeprägt waren, konnten sukzes- sive reduziert und auf eine letzte Maschine verlagert werden. Ohne AFS konnten die SIM-Server, insbesondere diejenigen, auf denen öffentliche Dienste wie LDAP- oder Webserver laufen, auf die aktuellste SLES-Version angehoben werden. Für diese wegen Sicherheits-Patches erforderliche Version stand näm- lich kein AFS-Kernelmodul mehr zur Verfügung. Eine zweite Maßnahme, speziell für die Webserver wie das Id-Portal, war die Konfiguration eines Apache-Modules, um beabsichtigte oder unbeabsichtigte Deni-

Jahresbericht 2012 des Leibniz-Rechenzentrums 135 al-of-Service-artige Request-Szenarien zu verhindern. Eine dritte Verbesserung der Sicherheit brachte die Revision der SSL-Konfiguration, wodurch auch neueren Angriffsszenarien erfolgreich begegnet wird.

12.2 CampusLMU und TUMonline Annähernd zwei Drittel der aktiven Kennungen im Bestand von LRZ-SIM entstammen den zentralen Verzeichnisdiensten von LMU und TUM (vgl. Tabellen in Abschnitt 12.1). Diese Benutzerdaten werden von IDM-Konnektoren automatisch und ohne Verzögerung in LRZ-SIM synchronisiert und enthalten Attribute, die die Berechtigungen für die vom LRZ erbrachten Dienste bei den einzelnen Kennungen steuern.

12.2.1 CampusLMU-Anbindung Für die bewährte Kopplung an den CampusLMU-Verzeichnisdienst waren in LRZ-SIM auch 2012 An- passungen und Erweiterungen notwendig, um die sich wandelnden und erweiterten Dienste des LRZ für die LMU optimal zu unterstützen. Die sogenannten Entitlement-Attribute, die von CampusLMU bei Kennungen gesetzt und in LRZ-SIM übernommen werden, dienen der automatischen Steuerung erweiterter Berechtigungen in LRZ-SIM selbst (Linux für die Physik, Mail und PC für die Biologie I) sowie dem automatischen Erzeugen von Gruppen im MWN-ADS. Für die AD-Anbindung einer Teaming-Software der LMU-Fakultät 11, die nahezu alle LMU-Studenten und viele Mitarbeiter verwenden dürfen, wurde ein solches neues Entitlement eingeführt. Dies bewirkte eine beträchtliche Erhöhung der Zahl von CampusLMU-Kennungen, die nun neu ins MWN-ADS weiterprovisioniert werden. Weiterhin wurde die Verschiebung von Kennungen zwischen LRZ-Projekten, basierend auf Physik- Entitlements für das Linux-Cluster, vollständig automatisiert. Ebenfalls automatisiert wurde die Deprovi- sionierung dieser Linux-Berechtigungen: CampusLMU-seitig ist kein dienstspezifischer Status „gesperrt“ vor der endgültigen Löschung möglich. Bei Wegfall des Linux-Entitlements löscht deshalb ein LRZ- seitiges Programm die Linux-Berechtigung und das Linux-Homeverzeichnis erst nach einer 14-tägigen, aus dem Historie-Attribut ermittelten Karenzzeit. Neben den aus Entitlements abgeleiteten Berechtigungen ist die explizite Dienste-Provisionierung durch CampusLMU erweitert worden: So entscheidet nun allein CampusLMU, nach welchen Regeln ein Benut- zer VPN- und Eduroam-Berechtigung bekommt, ohne dass auf LRZ-Seite ein manueller Prozess notwendig ist. In LRZ-SIM erforderte dies eine Erweiterung der Regeln, wann zu einer LMU-Person eine LRZ- Kennung angelegt wird. Ein weiterer Schritt in Richtung Automatisierung stellte die Übernahme der LMU-Funktionsmailadressen direkt aus CampusLMU dar. Sie ersetzt damit einerseits manuelle Eintragungen in LRZ-SIM und ermög- licht andererseits auch den autorisierten Versand mit diesen Funktionsmailadressen als Absender. Die Konsolidierung der LMU-Import-Projekte beseitigte die bisherige maildienstspezifische Trennung von Kennungen. Importierte Kennungen können nun gleichzeitig eine CampusLMU-Mailbox und eine lmu.de-Weiterleitung haben.

12.2.2 TUMonline-Anbindung Erweiterungen der Funktionalität des TUMonline-Portals und der in den TUM-Verzeichnissen gespeicherten Objekte machten auch bei der nunmehr schon im zweiten Jahr stabil laufenden Kopplung der TUM- und LRZ-SIM-Verzeichnisdienste Anpassungen erforderlich. Die beiden großen Arbeitsgebiete dabei waren die Übernahme von Funktionsobjekten sowie die Zusammenführung von Status- und Be- rechtigungsinformationen mit fremd- und LRZ-vergebenen Diensten. Obwohl das Schema der TUM-Funktionsobjekte mittlerweile sehr komplex ist, konnte die Kopplung erfolgreich um diese Objekte erweitert und auf Funktionskennungen im LRZ-SIM-Schema abgebildet werden. Eine Hürde bildete die Generierung von Personenobjekten und -referenzen, die in den TUM- Verzeichnissen nicht separat vorhanden sind. Die TUM-Funktionsmailadressen, die in früherer Zeit manuell in LRZ-SIM eingetragen wurden, können nun sukzessiv konsolidiert und über TUMonline verwaltet werden. Zudem haben mit den Funktionsobjekten nun sowohl der LRZ-Servicedesk wie auch Administra- toren im Id-Portal einen kompletten Überblick über alle TUM-Kennungen.

136 Benutzerverwaltung und Verzeichnisdienste

Zusätzlich zu den von TUMonline importierten Kennung sind nach wie vor von Master Usern verwaltete Kennungen in längerfristigen Projekten erforderlich, etwa für die Hochleistungsrechner, für Webserver und für TSM-Backup und -Archivierung. Für einen besseren Überblick erhalten die TUM- Verantwortlichen (CIO, Verwaltung) monatlich eine Liste der Master User von TUM-Projekten. Die aus SIM-Sicht einfachen Dienstberechtigungen, etwa für die WebDNS-, Netzverantwortlichen oder Monito- ring-Portale, können in LRZ-SIM zusätzlich auf TUM-Kennungen vergeben werden. Bei solchen Ken- nungen, deren Berechtigungen aus unterschiedlichen Quellen stammen, mussten jedoch geeignete Lösun- gen zur Deprovisionierung im TUM-Konnektor gefunden werden.

12.3 MWN Active Directory Als weiteren großen Infrastrukturdienst betreibt das LRZ für das MWN ein mandantenfähiges Active Directory (AD). Der Aufbau des zentralen, MWN-weiten AD wurde im Jahr 2007 im Rahmen der Bereit- stellung von Exchange und den Fileservices für den MWN-Speicher auf Basis von NetApp mit CIFS notwendig. Dieses MWN-AD ist so angelegt, dass einzelne, große Institutionen wie LMU, TUM oder die BAdW voneinander getrennt agieren können. 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. Jede Organisationseinheit erhält eine vordefinierte Unterstruktur (Organisational Unit, OU) in diesem Directory, die wiederum in Fakultäten und Lehrstühle weiter untergliedert werden kann. Auf diesen Ebe- nen können von einem sog. „Teil-Administrator“ des Kunden Computerkonten eingetragen und verwaltet werden. Damit es nicht zu Namenskonflikten kommt, wurde ein verbindliches Namenskonzept für Objek- te im Active Directory entwickelt. Zur Erfüllung ihrer Aufgaben wird den Teil-Administratoren ein Set an Werkzeugen über zwei Terminalserver zur Verfügung gestellt. Die Einrichtung dieser Organisationsstruk- turen 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. Die Benutzerkonten und zentralen Grup- pen werden über die beiden Metadirs (SIM, TUM) am LRZ weitestgehend automatisiert gepflegt. Dabei kommen Softwarelösungen der Firma Novell zum Einsatz. Mit dem MWN Active Directory können alle Clients ab Windows 2000 verwaltet, Mac OS X und Linux- Systeme integriert werden. Momentan sind aus den Mandanten TUM, LMU, HMT, BVB und BAdW rund 4.870 (Vorjahr: 3.550) Rechner im MWN-AD integriert. Es wurden bisher 508 (398) Teiladmins aus 302 (227) Einrichtungen registriert und in 2012 haben sich an der Infrastruktur rund 29.000 (21.000) verschiedene Nutzer angemeldet. Dabei wurden Dienste wie der MWN-Speicher, die Groupware Exchange oder die Anmeldung an ins MWN-AD integrierte Clientrechner genutzt. Seit 2009 erfolgt die Provisionierung der Benutzerkonten der TU München aus den Metadirs in das Acti- ve Directory durch den Identity Manager Driver for Scripting von Novell, der Attributsänderungen an vom LRZ selbstentwickelten PowerShell Skripten an die AD-Seite übergibt. Dadurch wird eine enorme Flexibilität beim Verarbeiten und der Fehlerbehandlung von Ereignissen erreicht. In 2012 wurden die Skripte weiter angepasst und bei der Verarbeitung von Funktionsobjekten wie Grup- pen, shared Mailboxen, Ressourcenmailboxen und Verteilerlisten weiter verfeinert. Viel Zeit floss auch in diesem Jahr in die Planung und Abstimmung mit der TUM. Um den Übergang von Berechtigungen bei der Vergabe oder dem Entzug von Berechtigungen für Kennungen abzubilden, sollen in Zukunft Dienstübergänge definiert werden. Dadurch lassen sich dann einzelne Berechtigungen im MWN-AD, MWN-Speicher und Exchange unabhängig voneinander vergeben. Die Realisierung ist für 2013 geplant. Um auch Gruppierungen im LRZ-SIM Verzeichnis umzusetzen ist mit der Provisionierung von Entitle- ments als Benutzerinformation eine einfache Art der Gruppierung von Benutzerobjekten im MWN Active Directory implementiert worden. Dieser Mechanismus kann nun von der LMU direkt genutzt werden um Gruppen ohne Zutun des LRZ im MWN-AD zu pflegen. In 2012 wurde für notwendige Infrastrukturdienste wie dem SCCM 2012 eine ins MWN-AD integrierte Windows Zertifizierungsstelle aufgebaut. Über die CA werden seit 2012 automatisiert Computerzertifika- te an alle konfigurierten Windows Clients verteilt.

Jahresbericht 2012 des Leibniz-Rechenzentrums 137

12.4 DFN-AAI/Shibboleth Föderiertes Identity Management (FIM) auf Basis der Software Shibboleth ermöglicht es Benutzern, Webdienste, die außerhalb ihrer eigenen Hochschule oder Einrichtung angesiedelt sind, mit der lokalen Hochschulkennung zu nutzen. Den organisatorischen Rahmen für einen solchen Diensteverbund stellt die DFN-AAI-Föderation dar. Als Authentifikationskomponenten, sogenannte Identity Provider (IdP), betreibt das LRZ in der DFN-AAI neben dem eigenen LRZ-IdP auch die IdPs für die LMU und die TUM. Die IdPs nutzen dabei als Datenbasis die SIM- und TUM-Verzeichnisdienste. Die großen Vorteile der Shibboleth-Authentifizierung, auch für nur hochschullokale Dienste, gegenüber einer LDAP-Anbindung sind:  Datenschutz: bedarfsgetriebene und vom Benutzer explizit zu genehmigende Weitergabe persön- licher Daten nur an die Dienste, die der Benutzer wirklich nutzt (keine universell leseberechtigten LDAP-Proxy-User, kein User-Provisioning auf Vorrat)  Sicherheit: Passworteingabe ausschließlich am IdP der Heimat-Einrichtung statt bei jedem Web- dienst extra, und damit u.a. Schutz vor Phishing  Komfort: Einmalige Passworteingabe für Zutritt zu allen Webdiensten während einer Browser- Session (Single-Sign-on)

12.4.1 Entwicklungen im Identity-Provider-Dienstbetrieb Bei den drei Servern für die TUM-, LMU- und LRZ-IdPs lag der Schwerpunkt der Weiterentwicklung auf der informationellen Selbstbestimmung: Die Konfiguration der Benutzerdatenfreigaben wurde grundlegend überarbeitet und an vorgegebene DFN-Standards angepasst. Trotzdem die Benutzer – im Gegensatz zu einer LDAP-Authentifizierung – vor der Nutzung eines Webdienstes der Weitergabe ihrer persönli- chen Daten explizit zustimmen müssen (Digital ID Card), konnte die Menge dieser Daten IdP-seitig vorab weiter eingeschränkt werden: Erstens wird der eduPersonPrincipalName nur noch an diejenigen Web- dienste übertragen, die explizit Bedarf an diesem Identifikator angemeldet haben. In der Regel können die Dienste einen Benutzer bei späteren Logins allein aufgrund eines automatisch berechneten Pseudonyms (eduPersonTargetedID) seinem bisherigen Profil zuordnen. Zweitens werden die Entitlement-Werte, die Voraussetzung z.B. für den Zugriff auf kostenpflichtige Online-Publikationen sind, gefiltert und dedizier- ter für einzelne SPs weitergegeben. Ein sehr sporadisch auftretender, aber dann schwerwiegender Fehler der Shibboleth-Software verhinderte zeitweise, dass die Metadaten aus den Föderationen automatisch aktualisiert wurden. Das Problem konnte dadurch entschärft werden, dass ein eigenentwickeltes Programm regelmäßig die Restgültigkeitsdauer aller Zertifikate in den Metadaten geprüft. Seit Mitte 2012 ist im LRZ-IdP die Voraussetzung dafür geschaffen, dass über dessen Authentifikation auch Dienste außerhalb Deutschlands genutzt werden können; genauer: Dienste, die über die Metafödera- tion eduGAIN zugänglich sind. EduGAIN ist eine Föderation von Föderationen, zu der seit 2012 auch der DFN-AAI gehört. Technisch ist hier die explizite Einbindung der eduGAIN-Metadaten notwendig für alle Dienste, die nicht auf „tieferer“ Ebene wie DFN-AAI oder einrichtungslokalen Freigaben erreichbar sind. Es handelt sich dabei um ein Opt-in-Verfahren, d.h. Identity- und Service-Provider müssen bei der DFN- AAI explizit zur Aufnahme in eduGAIN gemeldet werden. 2013 wird auch die Aufnahme der IdPs von TUM und LMU beantragt.

12.4.2 Anpassungen für spezielle Service Provider Für zwei sehr nützliche Dienste – den Transfer großer Datenmengen (GigaMove) und den DFN- Webkonferenzdienst – wurde die Freischaltung der drei IdPs bei den jeweiligen Service Providern veran- lasst und die Freigabe der notwendigen Attribute im IdP konfiguriert. Ein Pilotprojekt stellte die Einbindung des SPs für die Online-Abstimmung über die Einführung eines Semestertickets in München dar, weil hier mit den Verantwortlichen von TUM, LMU und HM nicht nur Fragen des Datenschutzes, sondern auch spezielle Anforderungen bei Senioren- und Promotionsstuden- ten, Doppel- und Zweit-Studiengängen zu lösen waren. Zudem mussten Mechanismen zur Verhinderung von doppelter Stimmabgabe gefunden werden.

138 Benutzerverwaltung und Verzeichnisdienste

Daneben gab es eine Reihe von zumeist hochschullokalen Diensten, die Shibboleth-Authentifikation nutzen und von den IdPs eine erweiterte Berechnung und Freigabe von Benutzerattributen benötigten. Dabei handelte es sich um Dienste wie Wiki-, Blog- und Evaluations-Server, weitere TUM-Typo3-Instanzen und LMU-Moodle-Instanzen (Medizin, Chemie, Physik, BWL). Für Berechtigungen, die nicht das Identity-Management-System selbst, sondern wie im Falle der vhb- Kurse ein Dritt-Dienstleister mittels Entitlement-Werten vergibt und verwaltet, wurde eine Lösung mit Zwischenspeicherung in der lokalen Datenbank der Identity-Provider-Server implementiert. Damit sind IdP-seitig diese Attribute nun ganz von den Directorys entkoppelt, um Seiteneffekte von Konnektoren (Löschung aller Entitlement-Werte) zu vermeiden. Nach erfolgreichem Login werden die in der Daten- bank gespeicherten Werte dann zusätzlich zu den aus dem Directory ausgelesenen Entitlements in der Benutzerfreigabe angezeigt und an den Service Provider ausgeliefert. Leider wird die Möglichkeit der Autorisierung für vhb-Kurse über die beim Shibboleth-Login mitgelieferten Attribute nach wie vor von keinem Moodle-Betreiber unterstützt.

Jahresbericht 2012 des Leibniz-Rechenzentrums 139

13 Dienste mit Sondervereinbarungen

13.1 Bibliotheksverbund Bayern Zur Erhöhung der Redundanz der Bibliothekssysteme wurde eine Planung erstellt, die vorsieht, die Clus- tersysteme auf die Brandabschnitte zu verteilen. Im Serverraum in DAR1, der in einem anderen Brandab- schnitt liegt, wurden die technischen Vorbereitungen zur Installation der Clusterrechner durchgeführt. Um die Speicherkomponenten auf die Brandabschnitte zu verteilen, müssen weitere Speichersysteme beschafft werden. Dazu wurde ein Antrag für Großgeräte der Länder gestellt. Der Antrag wurde ohne Ab- züge genehmigt, die Ausschreibung ist für 2013 in Vorbereitung. Weiterhin wurde die Ersetzung des jetzigen Firewallclustersystems, das schon heute den Datenverkehr nicht mehr komplett verwalten könnte, geplant. Für den Backupverkehr wurde dabei eine Lösung auf kostenfreier Open Source Software (pfsense) auf Althardware aufgebaut, um so den Betrieb aufrechterhalten zu können. Der Ersatz des Firewallclustersystems und die Verteilung des Clusters auf die beiden Brandabschnitte ist auch Teil des oben genannten Antrags und der Ausschreibung. In Kooperation mit der Bayerischen Staatsbibliothek wurde das System zur Langzeitarchivierung „Roset- ta“ von Ex Libris nach einer zweijährigen Projektphase jetzt produktiv geführt. Das LRZ betreibt die Plattform und betreut das Betriebssystem sowie den zugehörigen Datenbankcluster und die angeschlossenen Speichersysteme. Die Archivierung der Daten erfolgt auch durch das vom LRZ betriebene Ba- ckupsystem „Tivoli Storage Manager“ von IBM.

13.2 Managed Hosting für hochschulstart.de In diesem Jahr etablierte die „Stiftung für Hochschulzulassung“ (Stiftung öffentlichen Rechts) als Nach- folger der „Zentralstelle für die Vergabe von Studienplätzen“ (ZVS) gemäß dem Auftrag der Kultusmi- nisterkonferenz das bundesweite, zentrale "Dialogorientierte Serviceverfahren" für die Vergabe von Stu- dienplätzen. Der Wirkbetrieb, an dem sich grundsätzlich alle deutschen Hochschulen beteiligen können, wurde im April gestartet. Über eine Web-Applikation können sich Bewerber bei mehreren Hochschulen bewerben. Somit sind Letztere in der Lage, eine effizientere Bewerberauswahl, genauer gesagt Zu- oder Absagen zu treffen. Das LRZ, das im Vorjahr die Entwicklung der neuen Plattform technisch begleitet hat, ist für den Infra- strukturbetrieb zuständig; das Managed Hosting für die neue Applikation verlief aus Sicht des LRZ stö- rungsfrei. Die Applikation selbst wird von der Firma T-Systems Multimedia Solutions (MMS) betreut.

140 IT-Sicherheit

14 IT-Sicherheit

14.1 Antivirus Auf der Grundlage eines Landesvertrages über die Antiviren-Software der Fa. SOPHOS betreibt das LRZ eine Service-Infrastruktur zur automatischen Verteilung und Installation von SOPHOS-Virensignaturen für alle Nutzer im Münchner Wissenschaftsnetz, verbunden mit entsprechenden Beratungsleistungen zur Nutzung für Endbenutzer und CID-Betreibern in Bayern. Der Dienst wird täglich von rund 25.000 Clients im MWN genutzt. Der gesamte First-Level-Support wird inzwischen von den Auszubildenden am LRZ geleistet. (Weiterführende Serviceinformationen siehe: http://www.lrz.de/services/security/antivirus/).

14.2 WSUS Zur Versorgung von Clients im MWN mit Sicherheitsupdates für Windows-Betriebssysteme und Micro- soft 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 Gebrauch und kann auch von allen Endkunden im MWN über das LRZ benutzt werden. Der Dienst wird täglich aktiv von rund 8.500 Rechnern genutzt. (Weiterführende Serviceinformationen siehe: http://www.lrz.de/services/security/mwnsus)

14.3 Virtuelle Firewall Das LRZ betreibt 5 Cisco Firewall Service Module (FWSM), die sich auf verschiedene Backbone-Router im Münchner Wissenschaftsnetz (MWN) verteilen, und zwei ASA5580-40 zentral am LRZ (technische Details siehe Jahresbericht 2009). Derzeit werden damit rund 115 Kunden (104 im Vorjahr) mit virtuellen Firewalls (VFW) bedient.

Abbildung 80 Entwicklung der Anzahl von Kunden-VFWs

Abbildung 81 zeigt die Web-Schnittstelle zur Administration einer VFW.

Jahresbericht 2012 des Leibniz-Rechenzentrums 141

Abbildung 81 Web-Schnittstelle Adaptive Security Device Manager (ADSM)

Die beiden zentralen ASA5580-40 sollten im High-Availability-Modus (HA) in Betrieb genommen werden. Das wurde möglich, da die neueste Betriebssystemversion von Cisco sogenannte „Shared-Licenses“ zulässt. Das bedeutet, dass jetzt nur noch eine Lizenz pro VFW benötigt wird, die für beide ASA5580-40 gilt. Zuvor fielen im HA-Betrieb doppelte Lizenzkosten an, da pro VFW und pro ASA5580-40 eine Li- zenz benötigt wurde. Leider stellte sich diese und alle folgenden Betriebssystemversionen als so fehler- haft heraus, dass der geplante HA-Betrieb zurückgestellt werden musste. Um die Ausfallsicherheit zu erhöhen, wurde eine ASA5580-40 räumlich getrennt von der anderen aufgestellt. Diese befindet sich nun im Erweiterungsbau des Rechnerwürfels. Alle VFWs wurden für den Einsatz mit IPv6 vorbereitet. Viele Netze hinter den Firewalls haben bereits IPv6 Interface-Adressen erhalten und sind somit nativ mit IPv6 versorgt. Die Planungen für die Ersetzung der FWSMs haben begonnen. Als Folge der Ersetzung der Backbone- Router 2013 können die FWSMs nicht weiter betrieben werden, da die neue Router-Plattform nicht mit den vorhandenen FWSMs kompatibel ist. Dazu gab es bereits Gespräche und Produktpräsentationen

14.4 Sicherheitswerkzeuge und Sicherheitsmanagement

14.4.1 Secomat Das automatische proaktive Intrusion Prevention System (IPS) Secomat (vormals NAT-o-MAT) besteht derzeit aus einem Cluster mit 4 Nodes (Geschichte siehe Jahresbericht 2007 und 2009). Jeder Node kann eine theoretische Datenübertragungsrate von 10Gbit/s bewältigen. Die eingesetzte Technik zur Lastvertei- lung spaltet jedoch nur einmal 10Gbit/s auf die 4 Nodes auf. Diese Obergrenze wird vom MWN- Backbone vorgegeben, das auf dem 10-Gbit/s-Ethernet-Standard fußt.

142 IT-Sicherheit

Die folgenden Abbildungen zeigen Datenübertragungsraten, Benutzer und gesperrte Benutzer des Seco- mat-Clusters im Zeitraum von einer Woche.

Abbildung 82 Secomat1

Abbildung 83 secomat2

Abbildung 84 secomat3

Abbildung 85 secomat4

Die folgende Tabelle zeigt die Spitzenwerte bei Datenübertragungsrate und gleichzeitigen Benutzern. Secomat-Cluster Eingehende Datenübertragungsrate ca. 2,3 Gbit/s Ausgehende Datenübertragungsrate ca. 3,7 Gbit/s Gleichzeitige Benutzer ca. 17.000 Tabelle 19: Spitzenwerte der eingehenden und ausgehenden Datenübertragungsrate, sowie der Benutzeranzahl

Der Secomat-Cluster zeigt sich im Betrieb zuverlässig. Probleme im Betrieb macht im Großen und Gan- zen hauptsächlich Skype, das sich vermutlich aufgrund der Distanz zwischen Secomat und Skype-Client im MWN so verhält, als sei es nicht hinter einem NAT-Gateway (laut Dokumentation soll Skype erkennen können, ob es sich hinter einem NAT-Gateway befindet). Das führt dazu, dass Skype-Clients mit privaten IP-Adressen zu sogenannten „Supernodes“ werden und dann wegen ihres auffälligen Kommuni- kationsverhaltens durch den Secomat gesperrt werden. Die Sperrungen können am Secomat leider nicht verhindert werden, da sich das auffällige Kommunikationsverhalten der Skype-Clients nicht zuverlässig von Netzmissbrauch wie z.B. Portscans unterscheiden lässt. Deshalb muss das Verhalten des Skype- Clients auf dem Client-PC beeinflusst werden. Je nach Betriebssystem gibt es dafür unterschiedliche Lö- sungen. Zur Unterstützung der LRZ-Kunden wurde dazu eine ausführliche FAQ im Webserver des LRZ eingestellt. Die FAQ wurde um eine benutzerfreundliche Variante für Apples OS X ergänzt. Das LRZ

Jahresbericht 2012 des Leibniz-Rechenzentrums 143 stellt in diesem Fall ein vorkompiliertes Apple Script zur Verfügung, mit dem die erforderlichen Einstel- lungen per Mausklick durchgeführt werden (siehe https://www.lrz.de/fragen/faq/netz/netz10/). Um die Ausfallsicherheit zu erhöhen, wurde der Secomat-Cluster räumlich aufgeteilt: 2 Nodes wurden in den Erweiterungsbau des Rechnerwürfels migriert, während die restlichen 2 Nodes im alten Rechnerwür- fel verblieben. Zusätzlich wurden die doppelt ausgelegten IP-Netze für die Cluster-Kommunikation phy- sisch von den Administrations- und Strom-Management-Netzen getrennt.

14.4.2 Security Information & Event Management Die Detektion sicherheitsrelevanter Ereignisse erfolgt weiterhin am zentralen Übergang aus dem MWN ins X-WiN. Die dafür eingesetzte Sensorik umfasst zum einen ein signaturbasiertes Intrusion Detection System (IDS) und parallel dazu ein Accounting-System. Der vom IDS verwendete Regelsatz wurde auch 2012 an die aktuelle Bedrohungslage angepasst und um Signaturen ergänzt, die neue Schadsoftware er- kennt, die auf MWN-Systemen trotz regelmäßig durchgeführter Aktualisierung des Betriebssystems und der Software installiert werden konnte. So zeigte sich 2012 ein deutlicher Anstieg der Infektionen mit dem Trojanischen Pferd Zeus. Dieses verfolgt durch Kombination verschiedener Angriffstechniken das Ziel, für den Nutzer unbemerkt in Online-Banking-Kommunikation einzugreifen, um dabei genutzte Zu- gangsdaten, PINs und TANs zu stehlen. Die anschließende missbräuchliche Verwendung dieser Daten hat meist schlimme finanzielle Folgen für den Kontoinhaber. Die bewährte Identifikation Spam-versendender Systeme und von Portscan- und Denial-of-Service-Angriffen aus dem MWN heraus funktionierte überaus zuverlässig und ergänzte das nur auf bekannte Angriffe abzielende IDS um eine Anomalie-basierte Er- kennung. Die Auswertung und Korrelation der Ereignisse sowie die Alarmierung der zuständigen Netzverantwort- lichen und Systemadministratoren erfolgte weiterhin durch das am LRZ seit einiger Zeit eingesetzte Security Information & Event Management System (SIEM). Durch Event-Aggregation und Sensor- übergreifende Korrelation von Alarmmeldungen konnte ein erster Verdacht zuverlässig erhärtet oder ent- kräftet werden. Die Anzahl fälschlicherweise gemeldeter Auffälligkeiten konnte dadurch auf nahezu Null reduziert werden. Ein manuelles Eingreifen durch die LRZ-Abuse-Teammitglieder war nurmehr in wenigen Einzelfällen erforderlich, was auf die von der SIEM-Lösung angebotenen automatischen Reaktions- möglichkeiten zurückzuführen war. 2012 wurde, um die Erkennungsraten der eingesetzen Mechanismen weiter zu erhöhen und die knappen Systemressourcen noch effektiver zu nutzen, eine Bandbreitenmanagement-Lösung evaluiert. Zielsetzung war weniger ein aktives Eingreifen in die Kommunikation und das Beschränken der Bandbreite bestimm- ter Applikationen, sondern vielmehr eine Klassifikation des MWN-Netzverkehrs. Grundsätzlich sollten an dieser Stelle folgende Fragestellungen beantwortet werden:  Welche Applikationen und Protokolle werden im Münchner Wissenschaftsnetz verwendet und welchen prozentualen Anteil haben diese am Gesamtverkehrsaufkommen?  Sind nennenswerte Unterschiede bei ein- und ausgehender Kommunikation erkennbar?  Welche Netzbereiche besitzen monatlich das größte Verkehrsaufkommen? Sind die eingesetzten Netzkomponenten ausreichend dimensioniert?  Ließe sich die genutzte Bandbreite ausgewählter Applikationen zu bestimmten Zeiten begrenzen oder nur nicht-verschlüsselter Traffic an das IDS weiterleiten?  Können Applikationen selektiv priorisiert werden? Als Ergebnisse lassen sich u.a. festhalten, dass die im Rahmen der Tests durchgeführte Klassifikation die bisherige Vermutung des LRZ weitestgehend bestätigte. Streaming-Media und der Einsatz verschlüsselter Protokolle nehmen einen beachtlichen Anteil des MWN-Netztraffics ein, was besonders die Erkennung durch das IDS zunehmend erschweren wird. Desweitern würden sich die Reaktionsmöglichkeiten der SIEM-Lösung sinnvoll erweitern lassen. So könnte eine länger anhaltende Übertragung größerer Daten- mengen, welche sich oftmals negativ auf die übrigen Kommunikationsparteien auswirkt, durch gezielt angestoßenes Traffic Shaping Bandbreiten-technisch reglementiert werden. Dennoch wird auf eine derart aktive Regulierung durch Bandbreitenbegrenzung oder Priorisierung auch zukünftig im MWN verzichtet, auch wenn diese mit dem evaluierten Produkt problemlos möglich wäre. Die Einführung des IPv6-Protokolls im MWN ist in naher Zukunft weitestgehend abgeschlossen. Die erwartete IPv6-Unterstützung der LRZ-SIEM-Lösung ist, trotz mehrfacher Zusage des Herstellers, nicht vorhanden, so dass über einer Ersetzung nachgedacht werden muss. Diese soll neben einem um weitere

144 IT-Sicherheit

Sensoren ergänztes Event-Management, ein vollständig IPv6-fähiges Assetmanagement besitzen. Eine performante Auswertungsmöglichkeiten auch für Netflow-basierte Ereignisdaten, sowie erweiterte Korre- lations- und Auswertemöglichkeiten, sowie LRZ- und MWN-spezifische Reportingfunktionen sind wichtige zu erfüllende Anforderungen.

14.4.3 Nessi Das über den im ID-Portal anwählbaren Menüpunkt „Dienste für Netzverantwortliche“ ist ein Self- Service Portal für Netzverantwortliche. Netzverantworlichen wird es damit ermöglicht Informationen aus ihrem Netzbereich abzufragen (z.B. Mac-Adressen, per DHCP vergebene Adressen). Einfache Service- Requests können über dieses Portal an das LRZ verschickt werden. Das Portal wurde an die veränderte Struktur (DHCP-Server etc.) angepasst, und soll in Zukunft weitere Funktionen erhalten.

Abbildung 86 Nessi Portal

14.4.4 Nyx Das Sicherheits- und Netzmanagementwerkzeug Nyx, mit dem einzelne Rechner im MWN lokalisiert werden können, liefert nach Eingabe einer bestimmten MAC- oder IP-Adresse den Switchport, an dem der Rechner angeschlossen ist. Außerdem wird, falls hinterlegt, die Bezeichnung der Netzwerkdose aus- gegeben, zu welcher diese Switchports gepatcht ist. Dies ist gerade auch im Hinblick auf das schnelle Auffinden von Rechnern/Telefonen wichtig. Nyx überprüft dabei ca. 1.300 (Vorjahr: 1.250) Switche und fragt ca. 2.030 (Vorjahr: 1.800) Access- Points ab. Die Endgeräteanzahl innerhalb des MWNs steigt weiterhin deutlich, ebenso die Anforderungen an die Fähigkeiten dieses System. Bei der Bearbeitung von Missbrauchsfällen beispielsweise zum Auffinden infizierter Rechner ist es sehr nützlich. Für administrative Zwecke (Powercycling via PoE) werden die Daten aus Nyx ebenfalls verwendet.

Jahresbericht 2012 des Leibniz-Rechenzentrums 145

14.5 Server- und Benutzerzertifizierung nach X.509 Das LRZ ist mit mehreren Zertifizierungs- und Registrierungsstellen (CAs und RAs) in die Zertifizie- rungshierarchien „Global“ und „Grid“ 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. Das LRZ betreibt im Rahmen dieser Hierarchien eine Zertifizierungsstelle (CA) mit zwei Registrierungs- stellen (RA), eine RA für die Grid-CA der DFN-PCA sowie je eine RA für die CAs der beiden Münchner Universitäten. Im Gegensatz zu den Vorjahren werden letztere nur noch dazu verwendet, Zerifikate für solche Serverrechner auszustellen, die am LRZ selbst betrieben werden, insbesondere für Server für das Webhosting. Die eigene CA deckt den Bereich der Bayerischen Akademie der Wissenschaften einschließ- lich des LRZ selbst sowie solcher Einrichtungen im Münchner Wissenschaftsnetz ab, die keine eigene CA betreiben.

146 Arbeitsplätze

15 Arbeitsplätze

15.1 Windows Für das Deployment und Management von Windows Desktop- und Serversystemen kommt am LRZ Microsoft System Center Configuration Manager (SCCM) zum Einsatz. Der SCCM ermöglicht ein Betriebssystemrollout als Bare-Metal Variante (auf einem leeren System) sowie als in-place Upgrade oder Neuinstallation über ein bereits vorhandenes System. Im letzteren Fall werden dabei auch Einstellungen und Nutzdaten migriert. Des Weiteren ist es möglich, Software auf den gemanagten Clients zu installieren,, aktualisieren oder deinstallieren. Ein integriertes Reporting gibt Auf- schluss über die Erfolgsrate des Rollouts und etwaige aufgetretene Fehler. Über den SCCM werden sowohl Mitarbeiter-PCs und -Laptops als auch Serversysteme und virtuelle Maschinen installiert und gema- naged. Ein wichtiges Ziel ist es, das Produkt für eine Nutzung durch Teiladministratoren des MWNs freizuge- ben. Obwohl der SCCM keine Mandantenfähigkeit im eigentlichen Sinn aufweist, konnte hierzu für die Teiladministratoren eine Möglichkeit geschaffen werden, über die SCCM Console ihre jeweiligen Syste- me zu managen. Software-Pakete, die sich bereits im Software Repository befinden, können jederzeit benutzt werden - entsprechende Lizenzierung durch den Kunden vorausgesetzt. Software, die im Repository nicht vorhanden ist (in der Regel Spezialsoftware von Fakultäten), wird für den Kunden paketiert und nach Aufwand in Rechnung gestellt. Das LRZ übernimmt bei gemanagten PCs zudem die Aktualisierung von Standard- software, die aus Sicherheitsgründen aktualisiert werden muss (z.B. Java, Mozilla Firefox, Adobe Flash). Um das verfügbare Software Repository stets aktuell zu halten und an den Bedürfnissen der Nutzer aus- zurichten, wurden im vergangenen Jahr fortlaufend Software-Pakete aktualisiert sowie neue Software in das Repository eingepflegt. Dabei wurden die Methoden weiter verfeinert und die Reaktionszeiten bei den Paketen mit hohen Updatezyklen und hoher Sicherheitsrelevanz wie Java, Firefox oder Flash Player weiter deutlich verbessert und effizienter gestaltet. Insgesamt stehen derzeit über 400 Software-Pakete aus den unterschiedlichsten Anwendungsbereichen (Office, Internet, Architektur, Musik, Biologie, Wirtschaft, uvm.) für die Verteilung zur Verfügung. Un- terstützt werden alle aktuellen Windows Betriebssysteme. Insgesamt, d.h. MWN-weit, werden vom Sys- tem Center Configuration Manager 757 (698) Client-Systeme und 125 Serversystem verwaltet. In 2012 fand der Upgrade der Umgebung auf die neue Version SCCM 2012 statt. Vor allem in die Um- stellung der Pakete und Tasksequenzen musste dieses Jahr sehr viel Zeit investiert werden. Die bei der neuen Version erhofften Verbesserungen der Mandantenfähigkeit bei der neuen Version haben sich leider nur zum Teil erfüllt.

15.2 Linux-Mitarbeiter-PCs Schwerpunkt des Jahres 2012 war die Aktualisierung des Betriebssystems auf den etwa 60 vorhandenen Linux-Arbeitsplatz-Systemen. Die Version „openSUSE 11.3“ wurde auf „openSUSE 12.1“ angehoben. Zur Optimierung und Verschlankung der Partitionstabellen wurde jeweils eine Neuinstallation durchge- führt. Individuelle Daten konnten vor dem Formatieren per NFS gesichert und nach Abschluss der Instal- lation zurückkopiert werden. Neben der Installation auf physischer Hardware wird auch der Betrieb von „openSUSE 12.1“ als lokale, virtuelle Maschine (VM) mittels Hypervisor von VirtualBox, VMware-Player o.Ä. unterstützt. Bei Lap- tops, deren Hardwarefunktionalität für Windows-Betriebssysteme optimiert ist, ist der Einsatz von Linux als VM obligatorisch. Dies verringert aufwändigere Anpassungsarbeiten, zumal bei Vorhandensein viel- fältiger Laptop-Modelle.

15.3 Rechnerpools und Spezialarbeitsplätze 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 vollwerti-

Jahresbericht 2012 des Leibniz-Rechenzentrums 147 gen 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ösun- gen basierende Pools angeboten. Diese „Fullmanaged Desktops“ werden vom LRZ von der OS Installati- on, über die Softwarepflege bis zum Monitoring betreut. Bei den vom LRZ betreuten Systemen an der BAdW, TUM, LMU oder HMT wird der First Level Support von Vorortbetreuern der jeweiligen Man- danten wahr genommen, die bei Problemen oder Änderungswünschen als Ansprechpartner zum LRZ agieren. Im Rahmen des MWN-AD wird der „Light-Desktop/Server“ angeboten, bei dem Institutionen im MWN Rechner in die Infrastruktur integrieren können und so die Vorteile des zentral gepflegten MWN-AD für das Desktopmanagement mitnutzen können, ohne selbst eine Infrastruktur betreiben zu müssen. Die komplette Administration der integrierten Light-Desktop/Server obliegt dabei aber den lokalen Adminis- tratoren der jeweiligen Institutionen. Die verschiedenen Rechnergruppen setzen sich zahlenmäßig Ende 2012 wie in Tabelle 20 zusammen (Vorjahreszahlen in Klammern):

Light Desktop/Server Pool und Kurs Fullmanaged Desktop LRZ 86 51 (51) 177 (182) BAdW 216 (198) TUM 3.597 (2.402) 154 (128) LMU 402 (395) 20 (35) HMT 46 (57) BVB 4 (5)

Summen 4.089 (2.802) 271 (271) 393 (380)

Tabelle 20: Clients im MWN-AD

Bei den Kunden für den Remote Desktop Management Service in der ADS/LRZ-Domäne fanden in 2012 einige Umrüstungen statt:

- BAdW: o laufende Modernisierung der Hard- und Softwareausstattungen

- LRZ: o laufende Modernisierung der Hard- und Softwareausstattungen o Ersetzung der Leitwarte mit Thin-Clients o Modernisierung der CD-Brennstationen o Mac-Authentifizierung für Leitwarte und Pool-Rechner o Info-Display in der Hotline o Umbau der Netze für Gebäudemanagement o Aufbau einer zentralen Passwortverwaltung

- HMT (Hochschule für Musik und Theater) o Umstellung der letzten Pools auf Windows 7

- TUZE (TUM – Zentrale Einrichtungen) o Neuaufbau eines Pools mit 40 Clients

- TUSP (TUM-Sport) o Neuaufbau eines Pools mit 30 Clients

148 Arbeitsplätze

o Umstellung des bestehenden Pools auf Windows 7

- TUPH (TUM-Physik) o Übernahme des Betriebs der Terminalserver für Studenten an der Fakultät

Auch im Jahr 2012 wurden viele Stunden für Kundenberatung erbracht, um das Angebot des zentralen Speichers und des Light-Desktop/Server vorzustellen.

In 2012 wurden die bisherigen Datei-Ablagen von BAdW und LRZ auf dem gfiler.lrz-muenchen in den MWN-Speicher umgezogen. Dazu mussten Projektablagen und persönliche Verzeichnisse migriert werden. Mitte des Jahres erfolgte dann ein Umzug des MWN-Speichers auf neue, physische Systeme der Firma NetApp. Kurzfristig musste zum Ende des Jahres 2012 der Datenbereich der Fakultät F11 der LMU mit über 10 TB und rund 4.000 persönlichen Verzeichnissen auf den neuen MWN-Speicher migriert werden. Die in die Jahre gekommene und recht instabile Eigenentwicklung Webdisk um den MWN-Speicher auch über einen Browser zugänglich zu machen, wurde durch ein kommerzielles Produkt Http Commander von der Firma ElementIT ersetzt. Die neue zeitgemäße Oberfläche und die zusätzliche Möglichkeit nun auch über WebDAV zugreifen zu können, fanden im MWN große Akzeptanz.

Jahresbericht 2012 des Leibniz-Rechenzentrums 149

16 Interna

16.1 Personal

16.1.1 Personalausstattung Die Anzahl der Mitarbeiter im LRZ ist im Jahre 2012 aufgrund weiterer Drittmittelprojekte (EU- und BMBF-Projekte) weiter gestiegen. Aufgrund der weiterhin guten Konjunkturlage im IT-Bereich konnten offene Stellen jedoch teilweise gar nicht bzw. erst nach mehrfachen Ausschreibungen erfolgreich besetzt werden. So waren Ende 2012 am LRZ 157 Mitarbeiter und 39 wissenschaftliche und studentische Hilfs- kräfte beschäftigt. 2012 wurden wieder zwei Auszubildende (ein IT-System-Elektroniker und ein Fachin- formatiker der Richtung Systemintegration) am LRZ eingestellt. Zwei Auszubildende konnten ihre Aus- bildung erfolgreich abschließen und bereits kurze Zeit danach eine Anstellung in der Industrie annehmen.

16.1.2 Personalveränderungen 2012 Im Jahre 2012 waren insgesamt 43 Zugänge und 30 Abgänge zu verzeichnen. Es wurden 23 wissenschaftliche Mitarbeiter, 13 studentische Hilfskräfte, drei technische Angestellte, zwei Auszubildende sowie ein Verwaltungsangestellter und ein Kommunikationselektroniker neu am LRZ eingestellt. Acht wissenschaftliche Mitarbeiter, 16 studentische Hilfskräfte, zwei technische Angestellte, zwei Auszubildende nach erfolgreicher Ausbildung und zwei Verwaltungsangestellte verließen das LRZ und nahmen eine neue Beschäftigung an. Darüber hinaus traten drei wissenschaftliche Mitarbeiter sowie ein technischer Angestellter und ein Kommunikationselektroniker ihre Ruhephase in der Altersteilzeit an.

16.2 Gebäude und Infrastruktur

16.2.1 Gebäudemanagement Die Infrastruktur an Elektrizität und Kühlung als wichtigste Aufgabe des Infrastrukturmanagements konnte mit großem Einsatz stabil betrieben werden. Vor allem noch immer ausstehende Restleistungen und Mängel im Erweiterungsgebäude, das Mitte 2011 übergeben worden war, bergen latent Risiken für den Rechenzentrumsbetrieb. Die wichtigste Leistung des Jahres 2012 stellte die erfolgreiche Einbettung des neuen Höchstleistungs- rechners SuperMUC in die LRZ-Infrastruktur dar. Dazu musste eigens ein innovatives Kühlsystem aus deionisiertem Wasser im SuperMUC-Bereich installiert werden. Im Einzelnen gab es sehr viel Arbeit mit Restleistungen und Mängeln aus dem Bauabschnitt 2 (Erweite- rungsbau) aus den Jahren 2009-2011. Hier sind v.a. zu nennen  Gebäudeleittechnik (GLT) Dieses Gewerk hat für Überwachung und Steuerung der technischen Gebäudeausrüstung rund um die Uhr zentrale Bedeutung. Die GLT befand sich indes auch mehr als ein Jahr nach Übergabe des Erweiterungsbaues (Aug. 2011) noch in einem so beklagenswerten Zustand, dass die Über- wachungsaufgaben nur durch Botengänge und vor-Ort-Beobachtungen der Hauswerkstätte wahr- genommen werden konnten. Leider konnten dadurch auch Fehler und Schwächen anderer Ge- werke erst spät entdeckt und behoben werden. Dieser Prozess ist auch zum Jahresende 2012 noch nicht abgeschlossen.  Kühlturmbetrieb Bei den neuen Rückkühlwerken auf dem Dach zeigte sich erst spät - verschleppt u.a. durch die mangelhaft funktionierende Leittechnik - wie komplex und anpassungsbedürftig ihr Betrieb war. Dies führte über längere Zeit zu einem erhöhten Verbrauch von teurem Umkehrosmosewasser, weil die Regelung für das Abschlämmen des mit Verdunstungsrückständen befrachteten Abwas- sers nicht funktionierte.  Wasseraufbereitung / Umkehrosmose

150 Interna

Der für die Leistungsfähigkeit der Kühltürme entscheidende sog. „Benetzungsbetrieb“ mit Um- kehrosmosewasser konnte aufgrund von Durchsatzproblemen und von Fehlsteuerungen der Was- seraufbereitung erst spät im Jahr so betrieben werden, dass Schäden durch Benetzungswasser- rückstände einigermaßen sicher vermieden werden können.  Hydraulik der Wasserkühlsysteme Die Verzweigtheit der Rohrnetze und der sehr ungleichmäßige Kältebedarf des LRZ führt v.a. im Warmwasserkühlbereich zu hydraulischen Problemen: sie äußern sich in ungewollten „Kurz- schlüssen“ und beträchtlichen Ineffizienzen in den Entsorgungspfaden für die Rechnerabwärme. Hier sind größere Anpassungen notwendig. Dieser Prozess wird sich noch deutlich ins Jahr 2013 hinein ziehen.  Kommunikationshindernisse zwischen Lüftung und Steuerung Die ausführenden Firmen insbesondere der Lüftungstechnik sahen sich außerstande bzw. waren nicht bereit, die dringend benötigte Kompetenz ihrer Subunternehmer einzuschalten, deren Geräte sie zugekauft haben. Das LRZ erprobt hier erstmalig eine neue Kühlungsinfrastruktur, die zu massiven Einsparungen bzgl. der Energie führen. Diese „Pionierfunktion“ führt allerdings dazu, dass nicht von Beginn der Inbetriebnahme ein voll erprobtes Gesamtsystem vorhanden ist. Die genannten Probleme wurden in Dringlichkeitssitzun- gen mit dem Bauamt und den wesentlichen beteiligten Firmen eskaliert. Durch die Einrichtung von re- gelmäßigen wöchentlichen Sitzungen wurden wesentliche Fortschritte erzielt, ebenso durch die personelle Erweiterung des Teams des LRZ durch einen erfahrenen Mitarbeiter.

16.2.2 Energieeffizienz Das LRZ erhielt im März 2012 den deutschen Rechenzentrumspreis in der Kategorie "Energie- und Res- sourceneffiziente Rechenzentren". In seiner Bewerbung "Höchstleistungsrechnen – höchst effizient!" hatte das LRZ die weltweit einzigartige Energieeffizienz seines neuen Höchstleistungsrechners Super- MUC herausgestellt. Durch die innovative Kühlung des Systems mit warmem Wasser ist es möglich, den Großteil der Rechnerkomponenten ganzjährig ohne den Einsatz von Kältemaschinen zu kühlen. Die effiziente Ausnutzung der Energiesparmechanismen neuester Prozessortechnologien erlaubt zudem die gleichzeitige Optimierung der Rechnerperformance für Geschwindigkeit und Energie. Auch auf diesem Gebiet ist das LRZ Pionier. Trotz dieser Auszeichnung mussten aufgrund fehlender Personalkapazitäten (sowohl beim LRZ wie auch bei den beteiligten Firmen) und den oben beschriebenen Problemen bei der Mängelbeseitigung des Erwei- terungsbaus geplante Tätigkeiten zur weiteren Optimierung auf das Jahr 2013 verschoben werden, da vor allem zuerst der geplante Funktionsumfang der Gebäudeinfrastruktur zuverlässig betriebsfähig gestaltet werden muss. Erst danach bleibt Raum für dringend naheliegende Optimierungen in der Betriebsweise der Stromversorgungs- und Kühlungsaggregate.

16.3 Das LRZ als Ausbildungsbetrieb Seit 2007 ist das LRZ als Ausbildungsbetrieb anerkannt und bietet Ausbildungsplätze für IT-System- Elektroniker und Fachinformatiker Systemintegration an. Die Ausbildung geschieht abteilungsübergrei- fend und wird von Herrn Reiser (als verantwortlicher Ausbilder), Herrn Benen (Vertreter), Herrn Häfele, Herrn Neumann und Herrn Niedermeier koordiniert. Im Ausbildungsjahr 2012/2013 wurden wieder zwei Auszubildende (ein IT-System-Elektroniker und ein Fachinformatiker der Richtung Systemintegration) am LRZ eingestellt, die Bewerberauswahl wurde Ende 2011 erstmals eigenständig im LRZ durchgeführt. Zwei Auszubildende konnten ihre Ausbildung erfolgreich abschließen und bereits kurze Zeit danach eine Anstellung in der Industrie annehmen. Auch für das Ausbildungsjahr 2013/2014 ist geplant, wieder zwei Auszubildende einzustellen. Die Verstetigung der Ausbildung im Haushaltsansatz für den Doppelhaushalt 2013/2014 war leider nicht erfolgreich. Es wurden hierfür leider keine entsprechenden Mittelansätze genehmigt.

Jahresbericht 2012 des Leibniz-Rechenzentrums 151

16.4 Dienstleistungskatalog Der Wunsch anderer Hochschulen und wissenschaftsnahen Institutionen (Fachhochschulen, Bibliotheken, Max-Planck-Institute, Studentenwerk usw.) IT-Dienste des LRZ für sie zu betreiben und zu betreuen (IT- Outsourcing) hat sich auch 2012 weiter verstärkt. Das LRZ hatte schon Ende 2008 eine erste Version eines Dienstleistungskatalogs in Absprache mit seinem zuständigen Ministerium (Bayerisches Staatsmi- nisterium für Wissenschaft, Forschung und Kunst) erstellt, der im ersten Schritt nur diejenigen Dienste enthalten hatte, die bisher für andere Institutionen schon betrieben bzw. von anderen Institutionen aktiv nachgefragt wurden. Langfristig soll dieser Dienstleistungskatalog alle Dienstleistungen des LRZ umfas- sen, also auch diejenigen, die bisher und auch in Zukunft für Nutzer (im engeren Sinne) kostenlos sind, da sie der satzungsgemäßen Grundversorgung zugerechnet werden. Eine erste Auflistung hierzu findet sich in der Schrift „Das Leibniz-Rechenzentrum (LRZ) – eine Einführung“, die 2012 in einer neuen Auflage und einer einheitlichen Strukturierung nach dem Dienstleistungsbaum erschienen ist. Diese Schrift hatte 2010 den bisher im Jahresbericht enthaltenen Teil über die Dienstleistungen des Leibniz-Rechenzentrums ersetzt und wird auch zukünftig regelmäßig den aktuellen Gegebenheiten angepasst werden. Teil dieses Dienstkatalogs ist auch eine aktualisierte Klasseneinteilung möglicher Nutzer/Kunden. An- hand dieser Einteilung werden die Antragsteller klassifiziert und die für die Dienstleistung anzusetzenden Kosten berechnet. Dieser Entscheidungsprozess erfolgt in enger Abstimmung mit der Bayerischen Aka- demie der Wissenschaften und unserem Ministerium. Im letzten Jahr wurden zusätzlich zu den schon in den Vorjahren erbrachten Dienstleistungen weitere Dienste für die Hochschulen und die Bayerische Staatsbibliothek insbesondere aus dem Bereich Hosting virtueller Server, Online-Speicher und Archiv- und Backupservice erbracht.

16.5 Management-Tools, Dokumentation und Dienstleistungsbaum 2009 wurde im Zuge eines Projektes zur Konsolidierung der Management-Tools ein Arbeitskreis für Informationsmanagement gegründet. Um sowohl die Management-Tools wie auch die administrativen Abläufe am LRZ auf eine konsolidierte und fundierte Informationsbasis zu stellen, hat es sich der Ar- beitskreis zur Aufgabe gemacht, das Management der Informationen, im Speziellen der Dokumentationen zu verbessern. 2012 wurden wichtige Maßnahmen, die bereits 2011 initiiert wurden, konsequent fortge- führt. Der sogenannte Dienstleistungsbaum gliedert die Aufgabenbereiche des LRZ systematisch nach dem Dienstangebot. Diese Struktur wurde kontinuierlich weiter auf verschiedene Informationsquellen am LRZ ausgerollt und etabliert. In regelmäßigen Intervallen wurde der Dienstleistungsbaum auch überarbei- tet und an das sich ändernde Dienstleistungsportfolio des LRZ angepasst. Eine klare und intuitive Struktu- rierung des Serviceangebots und ein verbesserter Wiedererkennungswert sind hierbei große Vorteile für die Kunden des LRZ. Auch in der internen Gestaltung der Informationslandschaft wurde 2012 ein wichtiger Meilenstein erreicht. Um die unterschiedlichen Informationsquellen der einzelnen Projekt-Teams, Gruppen und Abtei- lungen für die Dokumentenablage konsolidieren zu können, wurde ein zentrales „LRZ-Wiki“ eingeführt. Durch diese Einführung konnte eine Vielzahl zuvor dezentral administrierter Wikis durch ein zentral gepflegtes Wiki abgelöst werden. Ein wichtiger Baustein für die Verbesserung der abteilungsübergreifenden Informationsstrukturen ist damit gelegt. Weitere Planungen für die Konsolidierung anderer dezentral verwalteter Daten konnten nun angegangen werden. Die Planung und Umsetzung hierfür wird auch 2013 noch eine zentrale Aufgabe für den Arbeitskreis für Informationsmanagement sein.

16.6 Mitarbeit in Gremien  BRZL: Arbeitskreis der bayerischen Rechenzentrumsleiter  ZKI: Zentren für Kommunikation und Information  ZKI-Arbeitskreis Universitäts- und Fachhochschul-Rechenzentren  MPG: Beratender Ausschuss für Rechensysteme  MPG: Kuratorium der Institute für Extraterrestrik und Astrophysik  DFN: Diverse Gremien und Ausschüsse  DFG-Gutachtersitzungen  IFIP/IEEE: Diverse Working Groups, Program and Organization Committees

152 Interna

 IT-Beirat fuer das Bibliothekswesen Bayerns (Bayerische Universitäts- und Fachhochschul- bibliotheken), ehemals: Kommission für EDV-Planung  Arbeitsgruppe IT-Strategie für die staatlichen Museen und Sammlungen in Bayern  Beirat zur Implementierung der Langzeitarchivierungssoftware „Rosetta Digital Preservation System“ im Bibliotheksverbund Bayern  D-Grid Beirat  EGI Management Board  DGI-2 Leitungsgremium  NGI/DE : nationale Koordination der Entwicklungsaktivitäten für eine europäische Grid- Infrastruktur)  Gauss Centre for Supercomputing (GCS)  Gauß Allianz  PRACE Management Board  ETP4HPC (European Technology Platform for High Performance Computing) Founding Fathers Board  PRACE Council  PROSPECT Board  EOFS Administrative Council  OGF GLUE Working Group  GEG (Géant Expert Group)

16.6.1 Abteilung „Benutzernahe Dienste und Systeme“  ZKI-Arbeitskreis Verzeichnisdienste  ZKI-Arbeitskreis Multimedia und Grafik  ZKI-Arbeitskreis Verteilte Systeme  Regionale DOAG-Arbeitsgruppe München (Deutsche Oracle Anwendergemeinde)  Arbeitskreis vernetzter Arbeitsplatzrechner (AKNetzPC)  Bayerischer Arbeitskreis Identity Management (vormals Bayerischer Arbeitskreis Metadirectory und Arbeitskreis AAI)  DFN-Arbeitsgruppe E-Learning

16.6.2 Abteilung „Hochleistungssysteme“  ZKI-Arbeitskreis Supercomputing  KONWIHR (Kompetenznetzwerk für Technisch-Wissenschaftliches Hoch- und Höchstleistungs- rechnen in Bayern)  UNICORE Forum (UNICORE User Group)  IBM SPXX-L User Group for Large IBM Installations  IBM SciCom HPC Systems Scientific Computing User GroupD-Grid Technical Advisory Board (TAB)  OGF Production Grid Interoperability (PGI) working group  NGI-DE Joint Research Unit (JRU)  Münchner Arbeitskreis Langzeitarchivierung  Fortran Standardisierung (International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) through their Joint Technical Committee 1 (JTC1), International Standardization Subcommittee for programming languages (SC22), Working Group 5 Fortran)  STRATOS (PRACE Advisory Group for Strategic Technologies)  IESP (International Exascale Software Project)  EESI2 (European Exascale Software Initiative 2)

Jahresbericht 2012 des Leibniz-Rechenzentrums 153

 ETP4HPC Strategic Research Agenda (SRA) Working Group  PRACE-1IP Technical Board  PRACE-2IP Executive Board  EEHPCWG (Energy Efficient HPC Working Group)  ScalaLife Executive Board  ScalaLife Project Management Board  Autotune Management Board  EGI Technology Coordination Board (TCB)  EGI CF12 Programme Committee  IGE Project Management Team (PMT)  IGE Steering Committee  IGE Technical Board  VERCE Steering Committee  VERCE Technical Board  e-IRGSP3 Project Management Board

16.6.3 Abteilung „Kommunikationsnetze“  BHN (Bayerisches Hochschulnetz)  IT-Beirat der Staatlichen Museen und Sammlungen  ZKI-Arbeitskreis Netzdienste  ZKI-Kommission "Eduroam off Campus"  DFN-Betriebsausschuss  Projektgruppe Datenverkabelung (öffentlicher Gebäude in Bayern)  Arbeitsgruppe "Voice over IP Strategie" für bayerische Dienststellen (Leitung STMF)  Arbeitskreis IT Service Management in Hochschulen  IT Service Management Forum itSMF  TÜV Komitee Personenzertifizierung nach ISO/IEC 20000  TÜV Komitee Personenzertifizierung nach ISO/IEC 27000  DFN Forum Kommunikationstechnologien 2012  19. DFN-Workshop Sicherheit in vernetzten Systemen (2012)  International Conference on Resource Intensive Applications and Services (INTENSIVE 2012)  IEEE/IFIP International Symposium on Integrated Network Management (IM 2013)  7th International Conference on Autonomous Infrastructure, Management and Security (AIMS 2013)  IEEE GlobeCom 2012 (GC’12) - Symposium on Communication and Information Systems Security (CISS 2012)  DMTF Academic Alliance Workshop on Systems and Virtualization Management (SVM’12)  International Conference on Advanced Communications and Computation (INFOCOMP 2012)

16.6.4 Abteilung „Zentrale Dienste“  ZKI-Arbeitskreis Softwarelizenzen  BSK-Arbeitskreis (Bayerische Software-Kooperation)

154 Interna

16.7 Veranstaltungen am LRZ Titel Datum ZKI, Eduroam of Campus 10.01.2012 CUDA Kurs 16.01. - 18.01.2012 IGE Advisory Board Meeting 31.01.2012 DFN Informationsveranstaltung „VideoConferencing“ 01.02.2012 EOFS-Meeting 07.02. – 08.02.2012 ExaScale I/O Workshop 07.02. – 08.02.2012 NGI-DE Beiratssitzung 13.02.2012 PDP Workshop 15.02. - 17.02.2012 Besuch ZiH Dresden Baudelegation 20.02.2012 ASCETE Kickoff Meeting 24.02.2012 Scalalife Winterschool 27.02. – 02.03.2012 Kompaktkurs: Parallel Programming of High Performance Systems 05.03. – 09.03.2012 OCIP Workshop 2012 12.03.- 14.03.2012 ETP Steering Board Meeting 12.03.2012 PROSPECT Meeting 13.03.2012 Thementag SOPHOS Endpoint Security 15.03.2012 EGI Community Forum 2012 26.03. – 30.03.2012 Ferienprogramm Stadtjugendamt München 04.04.2012 ieT User Group Treffen 16.04.2012 ITSM Airport Simulation für Hochschule München 20.04.2012 Girls Day 2012 26.04.2012 DEEP All Hands Meeting 08.05. – 09.05.2012 BGCE Research Day 10.05.2012 Symposium Forum Technologie der BAdW 11.05.2012 Sitzung der Evaluationskommission der BAdW 11.05.2012 Scalalife EAC Board Meeting 15.05.2012 GEPOM Workshop 15.06.2012 LabView Anwendertreffen 18.06.2012 GIDS Projekttreffen 25.06. – 27.06.2012 ISPDC 2012 25.06. – 29.06.2012 11th Intern. Symposium on Parallel and Distributed Computing DRIHM Meeting 17.07. – 18.07.2012 Einweihungsfeier SuperMUC und 50 Jahre LRZ 20.07.2012 Gauss Allianz Mitgliederversammlung 20.07.2012 Sitzung des Bayerischen Arbeitskreises Metadirectory und AAI 25.07.2012

Jahresbericht 2012 des Leibniz-Rechenzentrums 155

PRACE PCP Meeting 08.08.2012 Kompaktkurs: Iterative Linear Solvers and Parallelisation 10.09. – 14.09.2012 TUM Workshop Numerik 17.09. – 18.09.2012 DRIHM Meeting 18.09. – 19.09.2012 Kompaktkurs: Advances Topics with Fortran 17.09. – 21.09.2012 ieT User Group Treffen 01.10.2012 LabView Anwendertreffen 04.10.2012 ISO 20000 Kurs - Airport Simulation 08.10. – 09.10.2012 Tag der offenen Tür am Campus Garching 27.10.2012 DRIHM Meeting 08.10. – 12.10.2012 IBM Veranstaltung X-Series (Mittelstandskunden) 11.10.2012 10th VI-HPS Tuning Workshop 15.10. - 19.10.2012 Besuch einer chinesischen Delegation 19.10.2012 Adobe Roadshow 22.10.2012 Festakt: Eröffnung V2C 25.10.2012 Maplesoft Seminar "Mathematics and Modeling with Maple and MapleS- 26.10.2012 im" Tag der offenen Tür am Campus Garching 27.10.2012 DRIHM 2 US Kickoff Meeting 09.11.2012 HP Networking Technology Day 14.11.2012 Storage Consortium Anwenderkonferenz 15.11.2012 GCS Steuerkreissitzung 20.11.2012 Abschlussfeier Elitestudiengang Wirtschaftsinformatik 30.11.2012 Node-Level Performance Engineering 06.12. – 07.12.2012

156 Interna

16.8 Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstal- tungen

16.8.1 Abteilung „Benutzernahe Dienste und Systeme“  Workshop Konnektivität der Hochschulen zur vhb 26.01.2012 Hochschule München (Ebner)  AK NetzPC Thementage Sophos 08.02.2012 Würzburg (Schreiner)  Storage AK NetzPC; Treffen BSK Novell Landeslizenzvertrag 15.02.2012 - 16.02.2012 Regensburg (Hartmannsgruber)  ZKI Arbeitskreise Verzeichnisdienste und Campus Management 07.03.2012 - 08.03.2012 Halle (Ebner)  Preisverhandlungen in Rahmen der Beschaffungsverträge für Monitore, Notebooks und Desktops 14.03.2012 Regensburg (Hartmannsgruber)  Diskussion zum Thema "Microsoft Support Vertrag Bayern" 30.03.2012 Kempten (Hartmannsgruber)  Sitzung des AK NetzPC GroupWise Tag 19.04.2012 Regensburg (Hartmannsgruber)  Apple Mac OS X Support Essential 10.7 07.05.2012 - 09.05.2012 Erlangen (Gillmeister)  Workshop AD Grundlagen 15.05.2012 - 16.05.2012 Würzburg (Hollermeier)  Hochverfügbarkeitslösungen auf Basis von MySQL 23.05.2012 München (Nickl)  Ausschreibung Notebook/ Desktop 14.06.2012 Regensburg (Hartmannsgruber)  Workshop AD Fortgeschrittene 02.07.2012 - 03.07.2012 Augsburg (Hollermeier)  VRAR 2012 19.09.2012 - 20.09.2012 Düsseldorf (Anthes)  ZKI Arbeitskreis Verzeichnisdienste 08.10.2012 - 09.10.2012 Würzburg (Ebner)  VM World Konferenz 2012 08.10.2012 - 11.10.2012 Barcelona (SP) (Gillmeister)  AK Netz PC 11.10.2012 Amberg (Niedermeier)  Security Vorträge an Schulen 26.10.2012 Ingolstadt (Bötsch)  Workshop Windows Server 2012; Treffen der AG Novell Landeslizenz 29.10.2012 - 31.10.2012 Regensburg (Hartmannsgruber)  Workshop Windows Server 2012 29.10.2012 - 30.10.2012 Regensburg (Fakler)  International Supercomputing Conference 2012 10.11.2012 - 22.11.2012 Salt Lake City (USA)/Ho Chi Minh (Vietnam) (Anthes)  DV-Fachseminar 21.11.2012 - 28.11.2012 Stade (Oesmann)  Gastvortrag Identity Management 13.12.2012 Kempten (Ebner)  Vertragsverhandlungen zum Novell-Landeslizenzvertrag 19.12.2012 Nürnberg (Hartmannsgruber)

Jahresbericht 2012 des Leibniz-Rechenzentrums 157

16.8.2 Abteilung „Hochleistungssysteme”  Peer review meeting 16.01.2012 - 17.01.2012 Brüssel -BE (Brehm)  PRACE 2IP WP 11 Meeting 17.01.2012 - 18.01.2012 Brüssel -BE (Christadler)  ETP Steering Board Meeting 19.01.2012 - 20.01.2012 Rom -IT (Huber)  Projekttreffen DGSI 23.01.2012 - 24.01.2012 Göttingen (Paisios)  DEEP-Projektmeeting 23.01.2012 Regensburg (Auweter, Huber)  Face-to-Face working group KPIs 25.01.2012 - 26.01.2012 Amsterdam -NL (Saverchenko)  PRACE 1IP und 2IP MB Meeting 27.01.2012Frankfurt am Main (Christadler)  PRACE 1IP WP9 und 2IP WP11 Meeting 13.02.2012 - 16.02.2012 Stockholm -SE (Auweter, Christadler)  PRACE 2IP WP 11 Meeting 13.02.2012 - 16.02.2012 Stockholm -SE (Wilde)  Thementage Storage 15.02.2012 Regensburg (Reiner)  Dissemination Workshop Development of impact measures for e-infrastructures 20.02.2012 Brüssel -BE (Straube)  Projekttreffen SLA4 D-Grid 22.02.2012 - 23.02.2012 Göttingen (Paisios)  High Performance Computing Workshop 26.02.2012 - 01.03.2012 Leogang -AT (Auweter)  Standbetreuung CeBIT 05.03.2012 - 11.03.2012 Hannover (Kemmler, Weinberg)  Parallel programming of high performance systems (eigener Vortrag) 05.03.2012 Erlangen (Guillen)  Kurs "Parallel programming of high performance systems" 05.03.2012 - 08.03.2012 Erlangen (Bader)  Vortrag bei IBM über SuperMUC im Rahmen der CeBIT 06.03.2012 - 07.03.2012 Hannover (Huber)  DEEP-Projektmeeting WP7 19.03.2012 Regensburg (Auweter, Huber)  D-Grid Ergebniskonferenz 19.03.2012 - 21.03.2012 Bonn (Paisios)  e-IRGSP3 Delegates Meeting; ICRI 2012 20.03.2012 - 23.03.2012 Kopenhagen -DK (Frank)  EGI Community Forum Spring 2012 (Techn. Conference) 26.03.2012 - 30.03.2012 München (Frank)  9th Intel EMEA HPC Roundtable Meeting; Face-to-Face Meeting WP7 27.03.2012 - 30.03.2012 Paris –FR / Stockholm -SE (Weinberg)  Face-to-Face Meeting WP 7 28.03.2012 - 30.03.2012 Stockholm -SE (Block, Christadler)  Future Thinking Konferenz 2012 - Preisverleihung Rechenzentrumspreis 29.03.2012 - 30.03.2012 Sinsheim (Auweter)  EC Review PRACE prototypes 29.03.2012 - 30.03.2012 Brüssel -BE (Wilde)  PRACE 1 IP Prototype Evaluation and Future Technologies (WP9) 10.04.2012 - 13.04.2012 Daresbury -UK (Christadler, Wilde)  MONT-BLANC Face-to-Face Meeting

158 Interna

11.04.2012 - 13.04.2012 Barcelona -ES (Auweter)  PRACE 1IP WP6 und PRACE 2IP WP6+WP10 all Hands Meeting 11.04.2012 - 13.04.2012 Bologna -IT (Saverchenko)  NA2/JRA 1/JRA2 Meeting 11.04.2012 - 13.04.2012 Rom -IT (Leong)  MONT-BLANC Face-to-Face Meeting 11.04.2012 - 13.04.2012 Barcelona -ES (Allalen)  PRACE 1 IP WP6 und PRACE 2IP WP6-WP10 all Hands meeting 11.04.2012 - 13.04.2012 Bologna -IT (Lanati)  Invitation to the 4th PRACE Executive Industrial Seminar 15.04.2012 - 17.04.2012 Bologna -IT (Wilde)  IGE All-Hands Meeting 17.04.2012 - 20.04.2012 Uppsala -SE (Frank, Paisios, Rössle-Blank)  PRACE Priorisation Panel 18.04.2012 - 19.04.2012 Brüssel -BE (Brehm)  NGI-DE Jahrestagung: Ein neues Betriebskonzept für das Grid in Deutschland 18.04.2012 - 19.04.2012 Karlsruhe (Eißler, Saverchenko, Waldmann)  ZKI AK Supercomputing Frühjahr 2012 (eigener Vortrag) 19.04.2012 - 20.04.2012 Karlsruhe (Weinberg)  HPC Lösungen für ANSYS mechanical 14.0 19.04.2012 Böblingen (Block)  TCB 11 23.04.2012 - 24.04.2012 Amsterdam -NL (Heller)  Seminar IBM Tivoli Storage Manager Client Functions 23.04.2012 - 25.04.2012 Stuttgart (Hoferer, Neumann)  VERCE Face-to-Face Meeting 02.05.2012 - 04.05.2012 Paris -FR (Frank, Leong)  HLRS Workshop on Scalable Global Parallel File Systems 07.05.2012 - 09.05.2012 Stuttgart (Otte)  ETP4HPC Steering Board Meeting 10.05.2012 Paris -FR (Huber)  ACM International Conference (eigener Vortrag) 15.05.2012 - 17.05.2012 Cagliari -IT (Auweter)  Informationsveranstaltung: Aktuelle Fördermöglichkeiten im 7. Forschungsprogramm der EU für Informations- und Kommunikationstechnologien 24.05.2012 München (Frank)  VERCE Project Rehearsal and Project Review 07.06.2012 - 08.06.2012 Brüssel -BE (Frank)  PRACE 2IP WP 8 Face-to-Face Meeting 11.06.2012 - 13.06.2012 Paris -FR (Wilde)  e-IRGSP3 Workshop; Closes e-IRG Delegates Meeting 11.06.2012 - 13.06.2012 Kopenhagen -DK (Frank, Straube)  DEEP Rehearsal and Review Meeting 11.06.2012 - 12.06.2012 Brüssel -BE (Auweter)  Intel Many Integrated Core Advanced-Workshop 13.06.2012 - 15.06.2012 Feldkirchen (Allalen, Weinberg)  International Supercomputing Conference 2012 15.06.2012 - 21.06.2012 Hamburg (Auweter, Hammer, Jamitzky, Satzger)  International Supercomputing Conference 2012 (eigener Vortrag) 17.06.2012 - 21.06.2012 Hamburg (Brehm, Wilde)  International Supercomputing Conference 2012 18.06.2012 - 21.06.2012 Hamburg (Huber)  DatacenterDynamics Conference and Training 25.06.2012 München (Huber)  VM- VIWN (VMware vSphere 5: What´s new)

Jahresbericht 2012 des Leibniz-Rechenzentrums 159

25.06.2012 - 26.06.2012 Hallbergmoos (Roll)  Arbeitsmeeting ISO/ IEC JTC1/ SC22/ WG 5 25.06.2012 - 30.06.2012 Toronto -CA (Bader)  Strategic Research Agenda Workshop 29.06.2012 Paris -FR (Huber)  DESY Computing Seminar (eigener Vortrag) 02.07.2012 Hamburg (Lanati)  DEEP WP3 Meeting 04.07.2012 - 05.07.2012 Braunschweig (Auweter)  Peer Review Meeting 17.07.2012 Brüssel -BE (Brehm)  Seminar "Führung kompakt" 30.07.2012 - 03.08.2012 Seeon (Biardzki)  Antragsvorbereitung Projekt NLL 22.08.2012 Frankfurt am Main (Baur)  GridKa School 2012 27.08.2012 - 31.08.2012 Karlsruhe (Leong)  VERCE Training 02.09.2012 - 05.09.2012 Liverpool (UK) (Brietzke, Frank, Leong)  Meeting bei Fa. Bull 03.09.2012 - 04.09.2012 Les Clayes -FR (Auweter, Pancorbo)  PRACE 2 IP All Hands Meeting; PRACE 3 IP Kick off; PRACE 2 IP WP11 Meeting 03.09.2012 - 07.09.2012 Paris -FR (Wilde)  PRACE 2 IP All Hands Meeting; PRACE 3 IP Kick off 05.09.2012 - 07.09.2012 Paris -FR (Lanati, Weinberg)  2nd International Conference on ICT 05.09.2012 - 06.09.2012 Wien -AT (Auweter)  Conf 2012 The 3rd Annual Splunk Worldwide User´s Conference 08.09.2012 - 15.09.2012 Las Vegas -US (Hanauer)  DEEP-Treffen 12.09.2012 Regensburg (Auweter, Huber, Tafani)  e-IRG Delegates Meeting 13.09.2012 - 14.09.2012 Athen -GR (Frank, Straube)  PRACE 1 IP Review Meeting 13.09.2012 - 14.09.2012 Brüssel -BE (Wilde)  EGI Technical Forum 16.09.2012 - 19.09.2012 Prag -CZ (Heller, Leong, Rössle-Blank, Waldmann)  Kurs Data ONTAP 7-Mode Administration 17.09.2012 - 21.09.2012 Hallbergmoos (Kaumanns)  EGI Technical Forum 17.09.2012 - 21.09.2012 Prag -CZ (Frank, Saverchenko)  CEA Meeting 18.09.2012 - 20.09.2012 Paris -FR (Huber)  Xeon Phi Workshop 18.09.2012 - 21.09.2012 Montpellier -FR (Brietzke, Weinberg)  8. Fachtagung IT-Beschaffungen 18.09.2012 - 19.09.2012 Berlin (Bopp)  CEA Meeting 19.09.2012 - 20.09.2012 Paris -FR (Brehm, Wilde)  Finales Redaktionstreffen zum Projekt NLL 19.09.2012 Berlin (Baur)  1st International LSDMA Symposium 24.09.2012 - 25.09.2012 Eggenstein (Peinkofer)  Projektmeeting Autotune 25.09.2012 - 28.09.2012 Rennes/Vannes -FR (Guillen, Hesse, Navarrete)

160 Interna

 IGE All-Hands Meeting 01.10.2012 - 04.10.2012 Madrid -ES (Frank, Heller, Paisios, Rössle-Blank)  Mont-Blanc Face-to-Face Meeting; Slurm User Group Meeting 07.10.2012 - 11.10.2012 Barcelona -ES (Pancorbo)  Mont-Blanc Meeting 07.10.2012 - 10.10.2012 Barcelona -ES (Auweter, Tafani)  VM World Konferenz 2012 08.10.2012 - 11.10.2012 Barcelona -ES (Roll)  Blender Conference 2012 (eigener Vortrag) 11.10.2012 - 16.10.2012 Amsterdam -NL (Satzger)  DEEP Treffen WP7 15.10.2012 Regensburg (Auweter)  Tutorium "Grundlagen des Datenschutzes für Administratoren" 15.10.2012 - 15.10.2012 Berlin (Hanauer)  DEEP-Treffen 15.10.2012 Regensburg (Tafani)  DEEP ER Face-to-Face Meeting 17.10.2012 Köln (Huber)  ETP4 HPC Meeting 19.10.2012 Brüssel -BE (Huber)  DEEP Face-to-Face Meeting 22.10.2012 - 24.10.2012 Leuven -BE (Auweter, Tafani)  DGI-2 Workshop zu NGI-DE General Operations Policy 23.10.2012 - 24.10.2012 Karlsruhe (Waldmann)  Review Meeting 23.10.2012 - 24.10.2012 Brüssel -BE (Wilde)  Workshop zur NGI-DE General Operations Policy 23.10.2012 - 24.10.2012 Karlsruhe (Saverchenko)  Mont-Blanc Meeting 28.10.2012 - 30.10.2012 Barcelona -ES (Auweter)  ScalaLife Review Meeting 28.10.2012 - 31.10.2012 Brüssel -BE (Jamitzky)  PRACE 2 IP WP7 Meeting; PRACE 3 IP Face-to-Face Meeting 29.10.2012 - 01.11.2012 Montpellier -FR (Weinberg)  Technology Coordination Board Meeting 05.11.2012 - 06.11.2012 Amsterdam -NL (Heller)  EESI2 Coordination Meeting 06.11.2012 Brüssel -BE (Huber)  Workshop "Online Speicher" als föderierter DFN-Dienst 07.11.2012 - 07.11.2012 Berlin (Baur)  International Supercomputing Conference 2012 09.11.2012 - 17.11.2012 Salt Lake City -US (Huber, Jamitzky, Satzger, Wilde)  International Supercomputing Conference 2012 10.11.2012 - 17.11.2012 Salt Lake City -US (Bader)  International Supercomputing Conference 2012 11.11.2012 - 17.11.2012 Salt Lake City -US (Brehm)  Project Rehearsal and Project Review 18.11.2012 - 21.11.2012 Barcelona -ES (Tafani)  DV-Fachseminar 21.11.2012 - 28.11.2012 Stade (Hufnagl)  EGI/EUDAT/PRACE Workshop 26.11.2012 - 27.11.2012 Amsterdam -NL (Lanati)  IGE Review Meeting 27.11.2012 - 29.11.2012 Brüssel -BE (Frank, Heller, Rössle-Blank)  DEEP Workshop for Suppliers of Supercomputing / HPC System

Jahresbericht 2012 des Leibniz-Rechenzentrums 161

28.11.2012 - 30.11.2012 Ostrava -CZ (Tafani)  DGI-2 Abschlusstreffen mit dem PT 05.12.2012 - 06.12.2012 Hannover (Frank)  Autotune Review Meeting 10.12.2012 - 11.12.2012 Brüssel -BE (Brehm, Navarrete)  ETP4 HPC Meeting 13.12.2012 - 14.12.2012 Flughafen Municon (Huber, Ott)  Tivoli Sorage Manager Update 13.12.2012 - 14.12.2012 Heidelberg (Peinkofer)  ICPADS Konferenz 17.12.2012 - 19.12.2012 Singapur -SG (Leong)

16.8.3 Abteilung „Kommunikationsnetze“  D-Grid Beiratssitzung 13.01.2012 Hannover (Reiser)  ZKI Arbeitskreis "Service-Management und Sicherheit" 16.01.2012 - 17.01.2012 Ansbach (Hommel)  DFN-Betriebsausschusssitzung 14.02.2012 Berlin (Reiser)  UI Workshop 15.02.2012 - 17.02.2012 Zürich -CH (Schmitz)  19. DFN-Workshop "Sicherheit in vernetzten Systemen" (eigener Vortrag) 21.02.2012 - 22.02.2012 Hamburg (von Eye)  19. DFN-Workshop "Sicherheit in vernetzten Systemen" 21.02.2012 - 22.02.2012 Hamburg (Hommel)  Geant E2E Mon Review Face-to-Face Meeting 29.02.2012 - 03.03.2012 Kopenhagen -DK (Liu)  Geant Third Bandwidth-on-Demand Service Pilot Workshop 11.03.2012 - 14.03.2012 Athen -GR (Liu)  56. DFN Betriebstagung 13.03.2012 - 14.03.2012 Berlin (Tunka)  D-Grid Ergebniskonferenz 18.03.2012 - 21.03.2012 Bonn (von Eye)  NOMS 2012 (eigene Veröffentlichung) 13.04.2012 - 23.04.2012 Hawaii -US (Reiser)  GN3 JRA 2T1/ SA 2T5 Face-to-Face Meeting 17.04.2012 - 19.04.2012 Belgrad –XS (Liu)  Best Management Practice Kongress 2012 08.05.2012 - 10.05.2012 Bad Neuenahr (Brenner)  IPv6 Kongress 09.05.2012 - 11.05.2012 Frankfurt am Main (Schmidt)  DFN-Forum (eigener Vortrag) 21.05.2012 - 22.05.2012 Regensburg (Reiser, Schmitz)  DFN-Mitgliederversammlung 11.06.2012 - 12.06.2012 Berlin (Reiser)  DFN-Betriebsausschusssitzung 18.06.2012 Berlin (Reiser)  EUNIS 2012 (eigener Vortrag) 19.06.2012 - 23.06.2012 Vila Real – PT (von Eye)  BHN-Sitzung 21.06.2012 Bamberg (Reiser, Tröbs)  Beratungs- und Expertenworkshop "Europäische IT-Sicherheitsforschung" 04.07.2012 Köln (Reiser)  SIDAR Graduierten Workshop über Reaktive Sicherheit (eigener Vortrag)

162 Interna

05.07.2012 - 06.07.2012 Berlin (von Eye)  D-Grid Beiratssitzung 06.07.2012 Frankfurt am Main (Reiser)  Normausschuss Informationstechnik und Anwendungen "IT-Sicherheitsverfahren" 22.08.2012 Berlin (Metzger)  Fortbildung ComConsult IPv6 09.09.2012 - 12.09.2012 Berlin (Tunka)  ZKI Herbsttagung 2012 10.09.2012 - 12.09.2012 Leipzig (Reiser)  ZKI AK Service Management und Sicherheit 10.09.2012 Leipzig (Hommel)  Security Kurs 17.09.2012 - 21.09.2012 Nürnberg (Metzger)  Teilnahme und Vortrag bei der User Group "IT-Betrieb" (eigener Vortrag) 20.09.2012 - 21.09.2012 Leipzig (Brenner)  Abschiedskolloquium für Peter Holleczek 21.09.2012 Erlangen (Reiser)  Work Meeting FedSM-Projekt 03.10.2012 - 05.10.2012 Barcelona -ES (Brenner)  GEANT Symposium (eigener Vortrag) 15.10.2012 - 19.10.2012 Wien -AT (Gräter, Liu, Pöhn, Schmitz)  57. DFN Betriebstagung 15.10.2012 - 17.10.2012 Berlin (Tunka)  INFOCOMP 2012 Konferenz (eigener Vortrag) 21.10.2012 - 25.10.2012 Venedig -IT (Hommel)  BHN-Sitzung 25.10.2012 Erlangen (Reiser, Tröbs)  Erfahrungsaustausch Netzwerk Management 08.11.2012 Nürnberg (Loidl)  Laborbesuch, Workshop und Besuch NMC 19.11.2012 - 20.11.2012 Bamberg (Reiser)  DV-Fachseminar 21.11.2012 - 28.11.2012 Stade (Stoller)  72. DFN-Betriebsausschusssitzung 26.11.2012 Berlin (Reiser)  DFN Workshop Datenschutz 27.11.2012 - 28.11.2012 Hamburg (Hommel)  Kick-Off Meeting SASER-SIEGFRIED (deutscher Teil) 27.11.2012 - 28.11.2012 München (Hommel, von Eye)  65. DFN Mitgliederversammlung 04.12.2012 - 05.12.2012 Bonn (Reiser)  Working Meeting FedSM-Projekt (eigener Vortrag) 04.12.2012 - 06.12.2012 Amsterdam –NL (Brenner)  GN3 Übergabe Treffen (eigener Vortrag) 06.12.2012 - 07.12.2012 Kopenhagen -DK (Gräter, Liu)

16.8.4 Abteilung „Zentrale Dienste“  Seminar: Gebäudeautomation mit BACnet 23.01.2012 - 25.01.2012 Frankfurt am Main (Kirnberger)  Besprechung Projektvorschlag "German Academic Library Cloud" 26.01.2012 Berlin (Apostolescu)  Tagung "Die neue Entgeltordnung im TV-L" 06.02.2012 München (Apel)  DFN-Betriebsausschusssitzung

Jahresbericht 2012 des Leibniz-Rechenzentrums 163

14.02.2012 Berlin (Apostolescu)  AK Softwarelizenzen Frühjahrstreffen 2012 28.02.2012 - 29.02.2012 Hamburg (Diehn)  BSK-Sitzung 21.03.2012 Regensburg (Diehn)  BRZL-Klausurtagung 21.03.2012 Regensburg (Apostolescu)  CMS Schulung "Einführung in das Content-Management-System GSB" 22.03.2012 - 23.03.2012 Jülich (Palm)  Netzsitzung 2012 22.03.2012 - 23.03.2012 Köln (Apostolescu)  IT-Beiratssitzung in der Bay. Staatsbibliothek 25.04.2012 München (Apostolescu)  Rehearsel und DEEP Review Meeting 10.06.2012 - 12.06.2012 Brüssel -BE (Palm)  ZKI Kernteam-Treffen 13.06.2012 - 14.06.2012 Würzburg (Diehn)  DFN-Betriebsausschusssitzung 18.06.2012 Berlin (Apostolescu)  DEEP on ISC 2012 20.06.2012 - 21.06.2012 Hamburg (Palm)  ZKI Arbeitskreis Software-Lizenzen 17.09.2012 - 19.09.2012 Wismar (Diehn)  IBM DataCenter Expert Conference (eigener Vortrag) 19.09.2012 - 20.09.2012 Bonn (Breinlinger)  Abschiedskolloquium für Peter Holleczek 21.09.2012 Erlangen (Apostolescu)  BSK Klausurtagung 27.09.2012 - 28.09.2012 Pfronten (Diehn)  Konferenz Data Center Dynamics 22.10.2012 Frankfurt am Main (Breinlinger)  DEEP Face-to-Face Meeting 22.10.2012 - 24.10.2012 Leuven -BE (Palm)  DFG Netzsitzung 2012 28.10.2012 - 29.10.2012 Berlin (Apostolescu)  Entgeltsystem TVöD/ TVL 29.10.2012 - 30.10.2012 Unterhaching (Apel)  Treffen der AG Novell Landeslizenz 31.10.2012 Regensburg (Diehn)  International Supercomputing Conference 2012 09.11.2012 - 17.11.2012 Salt Lake City –US (Palm)  DataCenter Update 2012 13.11.2012 - 14.11.2012 Ehningen (Labrenz)  DV-Fachseminar 21.11.2012 - 28.11.2012 Stade (Mende)  72. DFN-Betriebsausschusssitzung 26.11.2012 Berlin (Apostolescu)

164 Interna

16.9 Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung Be- nutzernahe Dienste und Systeme betreut:

 Lang, A., EnergyViz – Visualising large scale multi-dimensional sensory data to reduce power consumption, Master Thesis, Ludwig-Maximilians-Universität München, Sommer 2012  Fussenegger, M., 3D Printing in a Scalable Cloud Environment, Bachelor Thesis, Lud- wig-Maximilians-Universität München, Sommer 2012

Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung Kommunikationsnetze betreut:

 Bittner, S., Effizientes Management von Router Access Control Lists (ACL) am Leibniz– Rechenzentrum (LRZ), Bachelorarbeit, Ludwig–Maximilians–Universität München, Juli, 2012.  Eberl, R., Ontologie–basierter Ansatz einer interorganisationalen Configuration Ma- nagement Database als Grundlage für das IT Service Management, Diplomarbeit, Lud- wig–Maximilians–Universität München, Mai, 2012.  Gembler, E., Erarbeitung eines kryptographischen Modells organisationsweiter Pass- wortverwaltung am Beispiel des Leibniz–Rechenzentrums, Bachelorarbeit, Ludwig– Maximilians–Universität München, September, 2012.  Grabatin, M., Erkennung von Innentätern — Entwicklung eines Systems zur heuristi- schen Analyse von Logfiles am Beispiel eines Hochschulrechenzentrums, Bachelorarbeit, Ludwig–Maximilians–Universität München, August, 2012.  Obexer, G., Erstellung eines IPv6–Securitykonzeptes für das Münchner Wissenschafts- netz, Diplomarbeit, Ludwig–Maximilians–Universität München, Mai, 2012.  Reisinger, R., Evaluation der Leistungsfähigkeit des Datenqualitätsmanagements mit Uniserv–Werkzeugen, Bachelorarbeit, Ludwig–Maximilians–Universität München, Sep- tember, 2012.  Romanyuk, A., Erstellung eines IT–Forensik–Leitfadens für das LRZ, Diplomarbeit, Ludwig–Maximilians–Universität München, Januar, 2012.  Wallwitz, A., Konzeption und Implementierung eines Moduls für den Fraunhofer– Honeypot "MalCoBox" am Leibniz–Rechenzentrum, Bachelorarbeit, Ludwig– Maximilians–Universität München, Oktober, 2012.  Weber, T., Authentifizierung mit dem neuen Personalausweis (nPA), Fortgeschrittenenpraktikum, Ludwig–Maximilians–Universität München, Juli, 2012.

Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abtei- lung Hochleistungssysteme betreut:

 Hayk Shoukourian, Towards a unified energy efficiency evaluation toolset: an approach and its implementation at LRZ, TUM, Oct-2012

Jahresbericht 2012 des Leibniz-Rechenzentrums 165

16.10 Veröffentlichungen der Mitarbeiter 2012

ALLALEN M., OFFMAN D., SATZGER H., JAMITZKY F., LRZ Validation-Suite for life Science. IinSIDE Vol. 10 No.2 (Autumn), 2012

ISSN 1436-753X APOSTOLESCU V., BODE A., FRANK A.C., Wissenschaft verbinden – For- schungskooperationen am LRZ, In: Akademie Aktuell, Zeitschrift der Baye- rischen Akademie der Wissenschaften, 02/2012, pp. 42-43, 2012

AUWETER A., HUBER H., Direct warm Water cooled Linux Cluster Munich: CooLMUC. In: inSiDE Band 10, Heft 1, Juni 2012

ISSN 1436-753X BAUR W., (K)EIN GRUND ZUM FEIERN. In: Akademie Aktuell, Zeitschrift der bayerischen Akademie der Wissenschaften, Heft 41, Ausgabe 02-2012

ISBN 978-3-642-24024-9 BISCHOF C., HEGERING H.-G., NAGEL W., WITTUM G., (eds): Competence in High Performance Computing 2010 (Proceedings, Schwetzingen, June 2010). Springer-Verlag Berlin, Heidelberg 2012 (234 Seiten)

ISSN 1436-753X BODE A., 50 Jahre IT-Dienstleistung am Leibniz-Rechenzentrum, In: Aka- demic Aktuell, Zeitschrift der Bayerischen Akademie der Wissenschaften, 02/2012, , pp. 12-16, 2012

ISSN 1436-753X BODE A., Höchstleistungsrechnen am LRZ, In: Akademie Aktuell, Zeitschrift der Bayerischen Akademie der Wissenschaften, 02/2012, pp. 44-45, 2012

ISSN (Online) 1865-7648 BRANTL M., CEYNOWA K., GROß M., REINER B., SCHOGER A., Digitale ISSN (Print) 0341-4183 Langzeitarchivierung in Bayern - Vom explorativen Projekt zum nachhalti- gen Modell. In: Bibliothek Forschung und Praxis, Band 35, Heft 1, April 2011

ISBN 978-1-4673-0267-8 BRAUN L., KLEIN A, CARLE G., REISER H., EISL J., Analyzing Caching Benefits for YouTube Traffic in Edge Networks - A Measurement-Based Evaluation. In: IEEE/IFIP Network Operations and Management Sym- posium (NOMS 2012), Maui, Hawaii, USA; April 2012

BREHM M.; BADER R., The new Petaflop Class System at LRZ In: inSiDE – Innovatives Supercomputing in Deutschland, Vol. 10 No. 1, Spring 2012.

VON EYE F., METZGER S., HOMMEL W., REISER H., GAIAS-IDS: Architek- turkonzept zur Integration szenarienspezifischer Datenquellen in dyna mische Intrusion Detection Systeme In: SIDAR Graduierten-Workshop über Reaktive Sicherheit, Berlin, July 2012

ISBN: 978-3-939296-04-1 FASTL H., LICHTINGER B., KERBER S., Psychoakustische Experimente zur Knallhaftigkeit. Tagungsband Fortschritte der Akustik - DAGA 2012, Darm- stadt, pp. 583–584, 2012

FIESELER T., HOMBERG W., AUWETER A., The Mont-Blanc Project: European Summit of Exascale System Architectures. In: inSiDE Band 10, Heft 1, Juni 2012

166 Interna

ISBN 978-3-00-038333-5 HEGERING H.-G., Chronik 50 Jahre Leibniz-Rechenzentrum der Bayeri- schen Akadmie der Wissenschaften. LRZ Garching, Druckhaus Köthen, 2012 (304 Seiten)

ISBN 978-9897040863 GENTSCHEN FELDE N., HOMMEL W., REISER H., VON EYE F., KOHLRAUSCH J., SZONGOTT C., A Grid–based Intrusion Detection System (GIDS), In Book of abstracts — a 360° perspective on IT/IS in higher education, 185–186, University of Trás–os–Montes e Alto Douro, EUNIS 2012 — 18th EUNIS Congress, Vila Real, Portugal, Juni 2012

ISBN 978-3885792970 GENTSCHEN FELDE N., HOMMEL W., REISER H., VON EYE F., KOHLRAUSCH J., SZONGOTT C., Das Datenschutzkonzept für das föderierte Frühwarnsystem im D–Grid und seine technische Umsetzung, In GI–Edition — Lecture No- tes in Informatics (LNI): Proceedings; 5. DFN–Forum Kommunikations- technologien — Beiträge der Fachtagung, (203), 53–62, Gesellschaft für Informatik, Verein zur Förderung eines Deutschen Forschungsnetzes e.V. (DFNVerein), Bonn, Germany, Mai 2012

HOMMEL, W., Integriertes Management von Security–Frameworks, Ludwig– Maximilians–Universität München, Habilitation, Juli 2012

HOMMEL, W., KRANZLMÜLLER, D., STRAUBE, C., A Platform for the Integrated Management of IT Infrastructure Metrics, In Proceedings of the Second In- ternational Conference on Advanced Communications and Computation (INFOCOMP 2012), 2012(2), 125–129, Venice, Italy, Oktober 2012

ISSN 2190-846X HOMMEL W., METZGER S., REISER H., VON EYE F., GAIAS–IDS: Architektur- konzept zur Integration szenarienspezifischer Datenquellen in dynamische Intrusion Detection Systeme, In: Proceedings of the Seventh GI SIG SIDAR Graduate Workshop on Reactive Security (SPRING), (SR–2012– 01), GI FG SIDAR, Berlin, Deutschland, Juli 2012

ISBN 978-9897040863 HOMMEL W., METZGER S., REISER H., VON EYE F., Log file management compliance and insider threat detection at higher education institutions, In Book of abstracts — a 360° perspective on IT/IS in higher education, 115– 116, Universidade de Trás–os–Montes e Alto Douro, EUNIS 2012 — 18th EUNIS Congress, Vila Real, Portugal, Juni 2012

ISBN 978-3844806885 HOMMEL W., METZGER S., VON EYE F., Innentäter in Hochschulrechenzen- tren — organisatorische und technische Maßnahmen zur Prävention und Detektion, In Sicherheit in vernetzten Systemen: 19. DFN Workshop, B–1– B–19, Books on Demand, Norderstedt, Januar 2012

ISSN: 1099-1190 DOI 10.1002/nem.1801 HOMMEL W., LIU F., METZKER M., SCHIFFERS, M. KÖNIG R., YAMPOLSKIY M., Link repair in managed multi–domain connections with end–to–end quality guarantees, International Journal of Network Management, 2012 (Volume 22, Issue 6), John Wiley & Sons, September, 2012

ISSN (Online) 1436-753X HUBER A., AUWETER A., Green IT am Leibniz-Rechenzentrum. In: Akademie Aktuell, Heft 41, Ausgabe 02/2012, Juli 2012

ISSN (Online) 1436-753X HUBER H., AUWETER A., Energieeffizienz für die Supercomputer von mor- gen. In: Akademie Aktuell, Heft 41, Ausgabe 02/2012, Juli 2012

Jahresbericht 2012 des Leibniz-Rechenzentrums 167

JANUSZEWSKI R., GILLY L., YILMAZ E., AUWETER A., SVENSSON G., Cooling – making efficient choices. PRACE Whitepaper, Oktober 2012

ISBN 978-9897040863 KNITTL S., HOMMEL W., VON EYE F., XaaS Cloud Service Strategy for Dy- namic Higher Education Institution IT Infrastructures, In Book of abstracts — a 360° perspective on IT/IS in higher education, 177–178, Universidade de Trás–os–Montes e Alto Douro, EUNIS 2012 — 18th EUNIS Congress, Vila Real, Portugal, Juni 2012

ISSN: 1942-2652 KNITTL S., LIU F., YAMPOLSKIY M., A Reference Model for Improving an In- ter–Organizational IT Management Tool, International Journal On Advanc- es in Internet Technology, 2012( Vol. 5, No. 1&2), IARIA, Juli, 2012

DOI 10.1109/ AHS.2012.6268638 KRAJA F., BODE A., MARTORELL X.., 2D-FMFI SAR Application on HPC Ar- chitectures with OmpSs Parallel Programming Model, Proc. 2012 NASA/ESA Conference on Adaptive Hardware and Systems, pp. 115-121, IEEE Conference Publications, 2012

ISSN: 1095-323X DOI 10.1109/ AERO.2012.6187226 KRAJA F., MURARASU A., ACHER G., BODE A., Performance evaluation of SAR image reconstruction on CPUs and GPUs, IEEE 2012 Aerospace Conference, pp.1-16, 2012

ISSN: 1095-323X DOI 10.1109/ AERO.2012.6187225 KRAJA F., ACHER G., BODE A., Parallelization techniques for the 2D Fourier Matched Filtering and Interpolation SAR Algorthm, IEEE 2012 Aerospace Conference, pp. 1-10, 2012

ISBN: 978-3-88579-297-0 LIU F., MARCU P., SCHMITZ D., YAMPOLSKIY M., Rethinking of Multi–Layer Multi–Domain Network Monitoring, In 5th DFN–Forum Kommunikations- technologien — Verteilte Systeme im Wissenschaftsbereich, 2012, GI– Verlag, DFN Forum, Regensburg, Germany, Mai, 2012.

METZGER S., HOMMEL W., VON EYE F., Innentäter in Hochschulrechenzen- tren – organisatorische und technische Maßnahmen zur Prävention und Detektion. In: Sicherheit in vernetzten Systemen: 19. DFN Workshop, B-1- B-19, Books on Demand, Norderstedt, Januar 2012

METZGER S., HOMMEL W., REISER H., VON EYE F., Log file management compliance and insider threat detection at higher education institutions. In: Book of abstracts – a 360° perspective on IT/IS in higher education, EUNIS 2012 – 18th EUNIS Congress, Vila Real, Portugal, Juni 2012

METZGER S., HOMMEL W., REISER H., VON EYE F., GAIAS-IDS: Architektur- konzept zur Integration szenarienspezifischer Datenquellen in dynamische Intrusion Detection Systeme. In: Proceedings of the Seventh GI SIG SIDAR Graduate Workshop on Reactive Security (SPRING), Berlin, Deutschland, Juli 2012

ISBN 978-3-88579-297-0 MÜLLER P., NEUMAIR B., REISER H., DREO RODOSEK,G., (Hrsg.) 5. DFN-

168 Interna

Forum Kommunikationstechnologien: Verteilte Systeme im Wissen- schaftsbereich. Lecture Notes in Informatics (LNI). Band P-203, Bonn, May 2012

DOI 10.1016/ j.procs.2012.04.038 MURARASU A., BUSE G., PFLÜGER D., WEIDENDORFER J., BODE A., Fastsg: A Fast Routines Library for Sparse Grids, Procedia Computer Science, Vol. 9, 2012, Proc. Conf. on Computational Science, ICCS 2012, pp. 354-363, Elsevier, 2012

ISSN 1436-753X REISER H., An jedem Ort, zu jeder Zeit: Mobilität im „Netz“. In: Akademie Aktuell, Ausgabe Nr. 42, S. 30-33, Oktober 2012

ISSN 1436-753X REISER H., MWN, DFN, GÉANT – München weltweit vernetzt. In: Aka- demie Aktuell Ausgabe Nr. 41, S. 38-39, Bayerische Akademie der Wissenschaften, July 2012

RICHTER C., SCHAAF T., An approach to consolidate and optimize monitoring solutions, In 7th IFIP/IEEE International Workshop on Business-driven IT Management (BDIM 2012), Hawaii, USA, Mai, 2012

PALM L., SuperMUC-Aufbau am LRZ schreitet zügig voran. In: Quartl 1/2011

PALM L., Leibniz-Rechenzentrum erhält „Deutschen Rechenzentrumspreis 2012“. In: Quartl 1/2011

ISSN 1436-753X PALM L., Das LRZ in Kürze. In: Akademie aktuell 02/2012

PALM L., Inauguration Ceremony of LRZ Extension. In: inSiDE – Innova- tives Supercomputing in Deutschland, Vol. 10 No. 1, Spring 2012

PALM L., LRZ awarded German Data Centre Prize. In: inSiDE – Innovatives Supercomputing in Deutschland, Vol. 10 No. 1, Spring 2012

PALM L., “SuperMUC”, Europe’s fastest Supercomputer, inaugurated at the 50th Anniversary of LRZ. In: inSiDE – Innovatives Supercomputing in Deutschland, Vol. 10 No. 1, Autumn 2012

PALM L., Mit SuperMUC in die nächsten 50 Jahre. In: Quartl 2/2011

PALM L., Zentrum für Virtuelle Realität und Visualisierung (V2C) am Leib- niz-Rechenzentrum eröffnet. In: Quartl 3/2011

ISSN 1436-753X PALM L., In der Champions League der Großrechner. In: Akademie aktuell 04/2012

ISBN (Print) SCHUBERT G., ANTHES C., KRANZLMÜLLER D., PETZOLD F., From Physical 978-986-03-4289-5 to Virtual: Real-time Immersive Visualisations from an Architect‘s working Model. In: Proceedings of 12th International Conference on Construction Applications of Virtual Reality, Band 12, Heft 1, S. 417-426, November 2012

Jahresbericht 2012 des Leibniz-Rechenzentrums 169

WAGNER S., BODE A. SATZGER H. BREHM M., High Performance Computing in Science and Engineering, Garching/Munich 2012, Bayerische Akademie der Wissenschaften 2012 (232 Seiten)

WEINBERG V., Data-parallel programming with Intel Array Building Blocks (ArBB) PRACE Whitepaper, November 2012, http://arxiv.org/abs/ 1211.1581

16.11 Promotionen und Habilitationen am LRZ In 2012 konnte ein Mitarbeiter erfolgreich sein Habilitationsvorhaben abschließen. In diesem Zusammen- hang entstand folgende Arbeit

 Hommel, W., Integriertes Management von Security–Frameworks, Ludwig–Maximilians– Universität München, Habilitation, Juli 2012

17 0 Technische Ausstattung

17 Technische Ausstattung

17.1 Datenspeicher

BRUTTOKAPAZITÄTEN ONLINE-SPEICHER (NAS+SAN) Typ Modell Anwendung Kapazität E-Mail LRZ, interne Server, Arbeitsplatz- NAS 2 x NetApp FAS 3050 47 TB Filedienste, WWW NAS 1 x NetApp R200 Replikation (asynchrones Spiegeln) 50 TB Speicher für die Wissenschaft (SFW), Speicher- NAS 2 x NetApp FAS 6070 236 TB hosting LMU, Exchange NAS 2 x NetApp FAS 3170 Metrocluster für VMware 504 TB

NAS 1 x NetApp FAS 6070 Replikation für den SFW und VMware 319 TB Speicher für die Wissenschaft (SFW), NFS- NAS 2 x NetApp FAS 6280 960 TB Dateidienste, Linux-Mailsysteme (NEU) Replikationssystem für SFS, NFS-Dateidienste, NAS 1 x NetApp FAS 6280 576 TB Linux-Mailsysteme (NEU) NAS 1 x NetApp FAS 6280 Replikationssystem für VMware 288 TB

NAS 2 x NetApp FAS 3170 Speicher für LZA-Projekte der BSB 730 TB

NAS 12 x NetApp FAS 6280 Projektspeicherplatz für SuperMUC 3.456 TB

NAS 4 x NetApp FAS 6280 Replikation Projektspeicherplatz für SuperMUC 1.536 TB

NAS 6 x NetApp FAS 3170 Linux-Computecluster 584 TB

NAS 1 x NetApp FAS 3050 Linux compute cluster repository (staging) 8 TB

NAS 2 x SUN 7310 Speicher für Datenbanken und VMware 22 TB

NAS 1 x SUN 7210 Replikation für SUN7310 24 TB

NAS 2 x NetApp FAS 3170 Metrocluster für Hochschulstart.de 50 TB

NAS Gesamt 9.390 TB

SAN 1 x STK D280 AFS 14 TB

SAN 9 x IBM DS3500 Cache für Archiv- und Backupsystem 1938 TB

SAN 3 x SUN 6780 Cache für Archiv- und Backupsystem 486 TB

SAN 2 x IBM StorWize SSD DB für Archiv- und Backupsystem 10 TB

SAN 3x Dell PowerVault DB+Cache für Archiv- und Backupsystem 281 TB

SAN Gesamt 2.729 TB Gesamt NAS+SAN 12.119 TB

Jahresbericht 2012 des Leibniz-Rechenzentrums 171

Die Tabelle gibt differenziert nach Speicherarchitektur einen Überblick über die Bruttokapazität der Plat- tenspeichersysteme des LRZ Ende 2012 und deren primäre Verwendung. Die tatsächliche Nutz- speicherkapazität ist um ein Viertel bis ein Drittel geringer, je nachdem wie redundant das System konfiguriert ist (RAID, Checksummen, Hotspare). Auf die NAS-Speicher wird im LAN/WAN über die Proto- kolle CIFS, NFS und iSCSI zugegriffen. Die SAN-Plattensysteme sind mit den Rechnern und Bandlauf- werken über die Speichernetz-Infrastruktur verbunden. Unter Nearlinesystemen versteht man Speicher, die nicht in direktem Zugriff sind. Der Datenträger (in der Regel eine Kassette) muss erst in ein Laufwerk geladen werden. Die nachfolgende Tabelle gibt die Mindestkapazitäten differenziert nach Typ des Datenträgers an. Durch die Hardwarekomprimierung der Bandlaufwerke wird in der Praxis eine deutlich höhere Speicherbelegung erreicht, als in der Tabelle angegeben.

KAPAZITÄTEN DER NEARLINE-SPEICHER

Systemname Bandbibliothek Bandlaufwerke Kassetten Kapazität

DRABS IBM TS3500 7 x IBM LTO 5 6.000 9.000 TB

SUN SL8500 26 x SUN T10K 10.000 10.000 TB HABS IBM TS3500 15 x IBM LTO 5 5.000 7.500 TB 10 x IBM LTO 4 IBM TS3500 8 x IBM LTO 5 LABS 16.500 14.000 TB 16 x IBM LTO 4 SUN SL8500 16 x IBM LTO 5 Gesamt 5 98 37.500 40.500 TB

17.2 Rechner und Server

17.2.1 Höchstleistungsrechner SuperMUC Gesam- Systemdaten Anzahl ter Kompo- Haupt- Prozessoren der Aufgabe Typ der Komponenten nenten speicher Komponenten (in GB) 18 Inseln 297216 Hochtemperatur- Je Insel 516 iDa- Höchstleistungsrechner für Benut- wassergekühltes IBM taPlex Knoten mit zer aus den Hochschulen in System x iDataPlex mit jeweils zwei 8-Core Deutschland sowie Tier-0 System Fat-Tree Verbindungs- Intel Sandy Bridge- für europäische Nutzer aus dem netz auf der Basis von EP (Xeon E5-2680) PRACE Projekt; für die Nutzungs- Mellanox FDR10 Infini- Sockeln und 32 berechtigung ist eine spezielle Be- band Technologie. GByte Hauptspeicher. gutachtung durch den wissenschaft- Die Inseln sind unterei- lichen Lenkungsausschuss oder nander ebenfalls mit PRACE-Begutachtung notwendig. einem Fat-Tree verbun- Typ: Parallel-Rechner den, allerdings mit einer um den Faktor 4 redu- zierten Bandbreite.

172 Technische Ausstattung

17.2.2 Migrationssystem SuperMIG (IBM BladeCenter HX5)

Anzahl Gesam- Systemdaten der ter Kom- Haupt- Typ der Komponen- Prozessoren der Aufgabe po- speicher ten Komponente nenten (in GB) Eine 52480 Luftgekühltes IBM 205 x3850 Blades Höchstleistungsrechner für Benut- Insel BladeCenter HX5 mit mit jeweils vier 10- zer aus den Hochschulen in Fat-Tree Verbindungs- Core Westmere-EX Deutschland; für die Nutzungsbe- netz auf der Basis von (Intel Xeon E7-4870) rechtigung ist eine spezielle Be- Mellanox QDR Infini- Sockeln und 256 gutachtung durch den wissen- band Technologie. GByte Hauptspeicher schaftlichen Lenkungsausschuss notwendig. Typ: Parallel-Rechner

17.2.3 Hochleistungs-Linux-Systeme Am LRZ selbst konfigurierter Linux-Cluster, der aus ca. 1.100 Komponenten mit insgesamt 23.5 TByte Hauptspeicher besteht, die mit 1 oder 10 GBit Ethernet, Myrinet oder Infiniband vernetzt sind. Er dient zur Bearbeitung üblicher, auf Linux verfügbarer Anwendungsprogramme und für Programme, die mittels MPI parallelisierbar sind. Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 1 SUN X4100 2 4 GB Komponente des Linux-Clusters: Opteron, 2600 SGE 6.2u2 Master-Server MHz 1 SUN X4100 4 8 GB Komponente des Linux-Clusters: Opteron, 2600 Zentraler nagios-Überwachungsserver MHz 8 MEGWARE 8 16 GB Attended Cluster-Housing-Knoten des Xeon E5462, Lehrstuhls für Geodäsie der TU- 2800 MHz München 15 SUN 4600 16 64 GB Attended Cluster-Housing-Knoten des Opteron, 2800 Lehrstuhls für Mathematik der TU- MHz München 35 MEGWARE 4 8 GB Attended Cluster-Housing-Knoten der Xeon X3230, Bayerischen Staatsbibliothek 2667 MHz 124 MEGWARE 4 8 GB Komponente des Linux-Clusters: Xeon X3230, LCG Tier-2 Rechen-Knoten 2667 MHz 32 DELL 12 36 GB Komponente des Linux-Clusters: Xeon L5640, LCG Tier-2 Rechen-Knoten 2261 MHz

Jahresbericht 2012 des Leibniz-Rechenzentrums 173

Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 68 MEGWARE 8 16 GB Komponente des Linux-Clusters: Xeon L5420, LCG Tier-2 Rechen-Knoten 2500 MHz 15 MEGWARE 4 4 GB Komponente des Linux-Clusters: Xeon 5060, 3200 LCG Tier-2 dCache-Knoten MHz 13 MEGWARE 4 4 GB Komponente des Linux-Clusters: Xeon 5148, 2333 LCG Tier-2 dCache-Knoten MHz 10 MEGWARE 4 8 GB Komponente des Linux-Clusters: Xeon L5240, LCG Tier-2 dCache-Knoten 3000 MHz 6 DELL 24 16 GB Komponente des Linux-Clusters: Xeon L5640, LCG Tier-2 dCache-Knoten 2261 MHz 2 MEGWARE 16 132 GB Attended Cluster-Housing-Knoten des Quad-Core Op- LMU Exzellenz-Cluster teron, 2400 MHz 20 MEGWARE 8 32 GB Attended Cluster-Housing-Knoten des Xeon L5420, LMU Exzellenz-Cluster 2500 GHz 112 MEGWARE 8 16 GB Attended Cluster-Housing-Knoten des Xeon L 5420, LMU Exzellenz-Cluster 2500 GHz 1 MEGWARE 4 12 Attended Cluster-Housing-Knoten der Xeon E5504, LMU, LS Prof. Ruhl 2000GHz 12 MEGWARE 6 48 Attended Cluster-Housing-Knoten der Xeon X5500, LMU, LS Prof. Ruhl 2660GHz, Je 1 NVidia GPU 4 MEGWARE 48 16 Attended Cluster-Housing-Knoten der AMD Opteron, LMU, LS Prof. Ruhl Je 1 NVIDIA GPU 38 MEGWARE 8 32 GB Komponente des Linux-Clusters: Opteron, 2600 x86_64-Cluster Knoten für parallele MHz MPI- und 8-fach Shared Memory Jobs 234 MEGWARE 4 8 GB Komponente des Linux-Clusters: Opteron, x86_64-Cluster Knoten für serielle und 2600 MHz parallele 4-fach Shared Memory Jobs

174 Technische Ausstattung

Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 64 SGI Altix 512 1536 GB X86_64-MPP-Rechner ICE8200  2 Prozessorsockel pro Knoten Xeon E5540,  8 Prozessorkerne pro Knoten 2533 MHz  3 GB pro Prozessorkern 2 SGI UV1000 1040 3328 GB X86_64-SMP-Rechner. Er wird in Form Xeon E7-4780, zweier separierter Partitionen betrieben. 2400 MHz 183 MEGWARE 2928 2928 GB X86_64-MPP-Rechner CooLMUC,  2 Prozessorsockel pro Knoten AMD Opteron  16 Prozessorkerne pro Knoten 6128HE,  1 GB pro Prozessorkern 2000 MHz 63 MEGWARE 1904 11200 GB Wird für die Informatik der TUM gehos- Unterschiedliche tet; Einsatz für Forschung an aktuellen Architekturen, Systemen sowie auch an Kühltechnolo- teilw. Mit Be- gien. schleunigern

17.2.4 Grid-Rechner

Anzahl Typ CPUs RAM (GB) Projekt 9 VM 1-2 0,5-4 D-Grid 2 VM 1 0,5 EGI 10 VM 1-2 0,5-4 IGE 23 VM 1-2 0,5-4 Internal 3 VM 1 0,5-2 MAPPER 13 VM 1-2 0,5-8 PRACE 3 VM 1 1-32 VERCE 8 Intel Xeon 16 16 Internal

17.2.5 Hochleistungs-Graphik-System

Systemdaten (Bei Systemen, die aus mehreren Komponenten bestehen, stehen die Daten der einzelnen Komponenten in den Zeilen darunter) Hersteller System und Sys- Struktur Aufgabe tem-Typ Anzahl Anzahl der Haupt- der Prozesso- speicher Kompo- Typ der Komponenten ren der der nenten Kompo- Kompo- nente nente

Jahresbericht 2012 des Leibniz-Rechenzentrums 175

Grafik- SGI Altix Cluster mit 12 12 Je 2 x Intel 6core Xeon, 2 144 GB 5-seitige Projektionsinstallation, Hochleis- XE500 Knoten 3.06 GHz,Nvidia Quadro (Server) (CAVE), 2,70 x 2,70 m pro Seite tungs- 6000 48 GB Cluster (Render- knoten)

Grafik- SGI Altix 1 4 x Intel 8core Xeon, 4 262 GB Großformatige Stereoprojektion, Hochleis- UV10 2.66 GHz, Nvidia (Powerwall), 6m x 3,15 m tungs- Quadroplex mit 4 Cluster Quadro 7000

Grafik- Am LRZ Mit 10 Gbit-E 3 SGI VSS40 2 32 GB Immersive 3D-Projektionstechnik (im Hoch- selbst vernetzte Intel Intel Xeon 5160 3 GHz Visualisierungs-Labor) als Rechen- leistungs- konfiguriert Xeon Systeme Nvidia Quadro FX5600 Cluster für eine Holobench Cluster mit Gsync

Remote SUN Fire Mit 10 Gbit-E 1 SUN Fire X4600 mit 4 16 128 GB Remote Visualisierung von umfang- Visualisie- X4600 vernetztes AMD Nvidia Quadroplex- reichen Datensätzen rungssys- Opteron System Einheiten mit insgesamt teme 4 Quadro FX5500 Gra- fikkarten

SUN Fire Mit 10 GbitE 4 AMD Quad-Core Opte- 16 128 GB Remote Visualisierung von umfang- X4600 vernetztes AMD ron reichen Datensätzen, speziell im Opteron System Rahmen von D-GRID 8 Nvidia Quadro FX5800 240 GPUs 4 GB Grafikkarte

GPGPU FluiDyna Intel Xeon 2 Intel Xeon Quadcore 8 62 GB GPGPU Testsystem System TWS System Nvidia Tesla Grafikkarte 240 GPUs 4 GB

17.2.6 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher ca. 350 PCs und andere Desktop-Workstations als Arbeitsplätze

14 Dell Dual QuadCore 2,8 GHz 2 8 GB Benutzerarbeitsplätze LRZ

ca. Dell Intel Core i5 3,2 GHz 1 1-8 GB Mitarbeiter-Arbeitsplätze, incl. Operateure, 115 Hotline, Beratung, stud. Hilfskräfte, Windows oder Linux

176 Technische Ausstattung

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher ca. Dell Intel Core i7 M 2.70 Ghz 1 256MB - 8 Laptops für Präsentationen, Notebooks/ 120 GB Arbeitsplätze für Mitarbeiter ca. 25 Dell, Apple Verschiedene 1 - 4 0,5-4 GB Benutzerarbeitsplätze für spezielle Geräte (Multimedia ACAD-Arbeitsplätze, Scanner, Multimedia, Videoschnittplatz) 30 Dell Intel Core i5 3,2 GHz 1 4-8 GB Arbeitsplätze in Kursräumen

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher BVB- Server und Storage 9 Sun SPARC Verschiedene 2-32 4-92 GB Zentrales Verbundsystem, Lokalsysteme (Da- tenbanken und OPACs) 15 Sun Verschiedene 1-8 8-32 GB Firewall, Suchmaschinen-Cluster 26 FSC Verschiedene 1-8 1-8 GB Suchmaschinencluster, OPACS, weitere Web- dienste, Allegro Datenbanken, Windows und Citrix Server, Mailserver, Netzüberwachung. 6 SUN Storage FC und SCSI 16 TB Storage für Datenbanken

1 IBM Storage 24 TB Storage für Datenbanken 16 HP Blades Xeon 2,53 GHz 1-8 0,5-4 GB Webservice/-control, Suchmaschinen

Jahresbericht 2012 des Leibniz-Rechenzentrums 177

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher Windows-Server

2 DELL Xeon 2,53 GHz 1 24 GB SQL-Cluster

5 DELL Xeon 2,4 GHz 2 16 GB Active Directory

9 VMware Xeon 2,53 GHz 1-4 16 GB Citrix Farm, Terminalserver Farm

4 Vmware Xeon 2,53 GHz 2 4 GB IET-Infrastruktur

12 Vmware Xeon 2,53 GHz 1-4 4-48 GB MS Exchange 2010, Forefront TMG

6 Dell Xeon 2,53 GHz 2 64 GB MS Exchange 2010

11 DELL Xeon 2,3 GHz 1-2 16 GB Facility Mgmt, Datenbanken, Storageserver, Applikationsserver 29 Vmware Xeon 2,53 GHz 1-2 8 GB Management Server, Applikationsserver, Soft- wareverteilung, Sharepoint, Monitoring, Domänencontroller An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 83 Linux-Server für AFS, Backup- und Archivierungsdienste

14 Advanced Xeon 2,80 GHz 1-2 2-4 GB AFS Unibyte 23 IBM Xeon bis 3,00 GHz 2-64 2-132 GB Backup, Archivierung

2 SGI Xeon 2,66 GHz 8 8 GB NAS-Backup, Test

10 VMware Xeon 2,53 GHz 1-8 0,5-4 GB Webservice, Software-Management

4 Dell Pentium III 1,0 GHz 2 0,25-2 GB AFS

13 Sun AMD Opteron 2,59 GHz 4 bis 16 GB Backup, Archivierung

5 IBM AMD Opteron 2 6 GB Backup, Archivierung bis 2,59 GHz 12 Sun Xeon 2,83 GHz 16 bis 74 GB Backup, Archivierung

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 35 Linux-Server für Maildienste

15 Advanced Xeon bis 3,60 GHz 2-4 2-8 GB - Unibyte 20 VMware Xeon 2,53 GHz 1-2 1-4 GB -

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 58 Linux-Server für Webdienste

27 VMware Xeon 2,53 GHz 1-4 0,5-8 GB Moodle, Proxy, Apache, Zope

31 Sun AMD Opteron 1-4 8-16 GB Apache, Zope bis 2,59 GHz

178 Technische Ausstattung

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 23 Linux-Server für Datenbanken

19 VMware Xeon 2,53 GHz 1-2 0,5-16 GB MySQL

4 Sun AMD Opteron 2,59 GHz 4 16 GB MySQL

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 48 Linux-Server für e-Directory-Dienste

41 VMware Xeon 2,53 GHz 1-2 1-6 GB SIM

7 Sun AMD Opteron 2,59 GHz 1-2 2-8 GB SIM

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 18 Linux-Server für Konsolzugänge und Leitwarten-PCs

5 Avocent - 1 - Serielle Konsolen

1 VMware Xeon 2,53 GHz 2 1 GB Konsole für externe Benutzer

5 Dell Pentium III bis 1,4 GHz 2 0,25-2 GB Leitwarte, LOM-Gateway

5 Dell Pentium 4 3,20 GHz 1-2 1 GB Leitwarte

2 Dell Core i5 3,20 GHz 4 4 GB Leitwarte

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher Linux-Server für Grafik- und Multimedia-Dienste

2 Advanced Xeon 2,80 GHz 2 2 GB Printing Unibyte 3 SGI Xeon 3,0 GHz 4 3 GB Grafik-Cluster

4 VMware Xeon 2,53 GHz 1-2 0,5-2 GB Printing, Streaming

2 Sun AMD Opteron 2,59 GHz 2 2 GB Printing

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 53 Linux-Server für Hosting und Housing externer Kunden

3 Advanced Xeon bis 3,20 GHz 4 4-16 GB e-Learning, Webservice Unibyte 1 Sun Xeon 3,0 GHz 4 8 GB e-Learning

45 VMware Xeon 2,53 GHz 1-8 0,5-32 GB IntegraTUM-, BSB-, Hosting

1 Dell Pentium III bis 1,4 GHz 2 - KDE

3 Sun AMD Opteron 2-4 2-8 GB VMware-Server, Bibliotheksverwaltung bis 2,59 GHz

Jahresbericht 2012 des Leibniz-Rechenzentrums 179

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 67 Linux-Server für verschiedene Dienste

5 Advanced Xeon 2,80 GHz 2-4 2-4 GB Installation, Monitoring Unibyte 51 VMware Xeon 2,53 GHz 1-4 0,5-4 GB Lizenzverwaltung, Monitoring, Tests

1 Dell Pentium III 1,26 GHz 2 1 GB Nagios

6 Sun AMD Opteron 2,59 GHz 1-2 2-4 GB VoIP, Up.Time, News, Splunk

4 Dell Xeon 2,67 GHz 24 24 GB VoIP, Monitoring

17.3 Netzkomponenten

17.3.1 Router

Aktive Aktive Ports Aktive Aktive Ports 10GE Ports 1GE Ports FE Anzahl Hersteller/Typ Einsatz Ethernet 8 Cisco Catalyst 6509 Backbone-Router 50 240 8 0 4 Cisco Catalyst 6509 LRZ-Router 75 56 1 0 1 Cisco 7206VXR Anbindung Triesdorf 0 2 0 0 1 Cisco 2821 Anbindung Straubing 0 0 2 0 1 Cisco 2911 Anbindung Fürstenfeldbruck 0 2 0 0 1 Cisco 1921 Anbindung Ingolstadt 0 2 0 0 18 Cisco 1811/1812 Standortanbindung 0 0 36 0 2 Cisco 1721 Standortanbindung 0 0 1 3 2 Cisco 891 0 0 4 0 1 Cisco 1802 0 0 2 0 5 Cisco 1921 Site2Site VPN 0 0 4 0 2 F5 BigIP 8900 Server Load Balancer 4 0 0 0 1 F5 BigIP 3400 Server Load Balancer 0 4 0 0 48 Router gesamt 129 306 53 2

17.3.2 Switches

Anzahl Hersteller/Typ verfügbare TP-Ports verfügbare Glasfaserports 10/100/1000 10GE 100/1000 10GE 2 HP E8212zl 25.354 9 3.944 337 253 HP E5406zl / E5412zl 214 HP E4204 / HP E4208vl 23.423 - 614 3 171 HP 4104gl / HP 4108gl 11.393 - 1.898 - 1 HP 4000 24 - - - 13 HP E6600-24XG/-24G-4XG 624 9 - 138 11 HP E6600-48G-4XG 4 HP E3800-48G-4G 161 - 31 9 4 HP 3500yl-24G-PoE+ 137 - 7 - 1 HP 3500yl-48G-PoE+ 14 HP E2910al-24G 1.478 - 10 12

180 Technische Ausstattung

24 HP E2910al-48G 7 HP2900-24G 1.656 72 - 39 31 HP2900-48G 24 HP E2810-24G 1.371 - 21 - 17 HP E2810-48G 11 HP3400cl-48G 523 - 5 6 2 HP 6400cl-6XG - 16 - 8 2 HP 6410cl-6XG 49 HP 2824 2.271 - 9 - 23 HP 2848 11 HP E2620-24 286 11 25 HP E2610-48 / -48pwr 186 HP E2610-24 / -24pwr 6.365 - 99 - 10 HP E2610-24/12pwr 62 HP E2615-8-PoE 782 - 18 - 18 HP E2915-8G-PoE 46 HP 2650 48 HP 2626 / HP 2626-pwr 3.488 - 96 - 4 HP 2600-8-pwr 11 HP E2510 / HP E2510G 264 - 12 - 3 HP 2524 74 - 1 - 1 Cisco Nexus7000 - - - 288 1.303 Switches gesamt 79.674 106 6.776 840

17.3.3 WLAN-Komponenten

Anzahl Hersteller/Typ Verwendung Standards Radios 939 HP MSM 310 Access Point 802.11b/g 1 10 HP MSM 310 Gebäudeanbindung 802.11b/g 1 94 HP MSM 320 Access Point 802.11a/b/g 2 1 HP MSM 320 Gebäudeanbindung 802.11a/b/g 2 450 HP MSM 422 Access Point 802.11a/g/n 2 6 HP MSM 422 Gebäudeanbindung 802.11a/g/n 2 498 HP MSM 460 Access Point 802.11a/g/n 2 51 HP MSM 466 Access Point 802.11a/g/n 2 4 HP MSM 466 Gebäudeanbindung 802.11a/g/n 2 1 HP MSC3200 Controller 2 6 HP M111 Wireless Client Bridge 802.11b/g 1 2.060 WLAN gesamt

17.3.4 Netz-Server

Anzahl Hersteller/Typ Verwendung Betriebssystem Prozessoren Hauptspeicher 6 Cisco ASA5540 VPN-Server proprietär 2 Cisco ASA5585-X VPN-Server propritär 1 Cisco 3030E VPN-Server proprietär Modem/ISDN-Server, 2 Cisco AS5350XM proprietär SIP-Gateway 2 Cisco ASA5580 Firewall proprietär 2 24 GB

Jahresbericht 2012 des Leibniz-Rechenzentrums 181

1 Meinberg Lantime NTP-Server Linux 1 32 MB DNS/DHCP-Server 14 Dell PowerEdge R610 Security-Server Linux 96 268 GB VoIP-Server 2 Sun Fire X4100 Radius Linux 4 4 GB 2 Sun Galaxy VoIP Linux 2 8 GB 2 Sun Fire X4150 Netzmanagement Linux 8 8 GB 1 Dell GX150 DSL-Server Linux 1 256 MB 2 Sun Fire X2100 Bibliotheksproxy Linux 2 2 GB 37 Server gesamt