Jahresbericht 2010 Des Leibniz-Rechenzentrums I

Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften

Jahresbericht

2010

Juni 2011 LRZ-Bericht 2011-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 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 2010 des Leibniz-Rechenzentrums i

Vorwort ...... 1

1 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS) ...... 3 1.1 Kurse und Veranstaltungen ...... 3 1.1.1 Kursübersicht, Statistik 2010 ...... 3 1.1.2 Vorträge „Schattenseiten des Internet“ ...... 5 1.2 Software-Versorgung für Rechnersysteme außerhalb des LRZ ...... 6 1.2.1 Landesweiter ESRI Vertrag ...... 6 1.2.2 Landesweiter Secunia Vertrag ...... 7 1.2.3 Weitere neue oder geänderte Verträge ...... 7 1.2.4 Routinemäßige Verlängerung bestehender Verträge ...... 7 1.2.5 Status Microsoft Select-Plus Lizenzen ...... 7 1.2.6 Betrieb von Lizenzservern für externe Systeme am LRZ ...... 7 1.2.7 Verträge mit Instituten im MWN ...... 7 1.2.8 Laufende Verhandlungen und Planungen ...... 7 1.2.9 Zusammenfassung ...... 8 1.3 Benutzerverwaltung und Verzeichnisdienste ...... 8 1.3.1 Für LRZ-Systeme vergebene Kennungen ...... 8 1.3.2 LRZ Secure Identity Management (LRZ-SIM) ...... 10 1.3.3 TUM-Verzeichnisdienste ...... 14 1.3.4 AAI-Föderationen: Shibboleth Identity Provider ...... 16 1.4 E-Mail, Web-Dienste und Datenbanken...... 18 1.4.1 E-Mail-Services ...... 18 1.4.2 Webdienste ...... 22 1.4.3 Datenbanken ...... 26 1.5 Grafik, Visualisierung, Multimedia ...... 27 1.5.1 Virtual Reality (VR) ...... 27 1.5.2 Streamingserver ...... 27 1.6 Serveradministration und Applikationsunterstützung ...... 27 1.6.1 Serveradministration in BDS ...... 28 1.6.2 Service für das Münchner Wissenschaftsnetz ...... 28 1.7 Desktop-Applikationsservices ...... 29 1.7.1 Sicherheitsdienste für Desktops im MWN ...... 29 1.7.2 Active Directory im Münchner Wissenschaftsnetz ...... 30 1.7.3 Desktop Management ...... 32 1.7.4 Server Management ...... 34 1.7.5 Microsoft Office Sharepoint Services (MOSS) ...... 35 1.7.6 Tätigkeiten im Rahmen der Berufsausbildung ...... 36 1.8 Server- und Benutzerzertifizierung nach X.509 ...... 36 1.9 Bearbeitung von Missbrauchsfällen ...... 37 1.9.1 Statistik der Missbrauchsfälle ...... 37 1.10 IT Bibliotheksverbund Bayern ...... 42 1.10.1 Umsetzung Großgeräte-Antrag...... 43 1.10.2 Rosetta ...... 44

2 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS) ...... 45 2.1 Entwicklung in der Datenhaltung ...... 45 2.1.1 Überblick ...... 45

ii Inhaltsverzeichnis

2.1.2 Archiv- und Backupsystem ...... 45 2.1.3 Langzeitarchivierung ...... 52 2.1.4 Online-Speicher ...... 56 2.1.5 Daten- und Archivraum ...... 62 2.2 Entwicklungen bei den Rechensystemen ...... 62 2.2.1 Höchstleistungsrechner in Bayern (HLRB II: SGI Altix 4700)...... 62 2.2.2 Linux-Cluster ...... 70 2.2.3 Tests und Prototypen ...... 70 2.2.4 Linux MPP Erweiterung ...... 70 2.2.5 Remote Visualisierungsserver ...... 71 2.3 Aktivitäten zur Beschaffung des neuen Petascale-Rechners SuperMUC ...... 72 2.4 Software und User Support im Bereich Hochleistungsrechnen ...... 74 2.4.1 Software für Linux-Cluster und Höchstleistungsrechner ...... 74 2.4.2 Supportanfragen ...... 75 2.4.3 Einführung des neuen Incidenttools ...... 75 2.4.4 Benutzerverwaltung ...... 75 2.4.5 Kurse und Ausbildung ...... 75 2.5 Öffentlichkeitsarbeit ...... 76 2.5.1 Supercomputing Konferenzen in Hamburg und New Orleans ...... 76 2.5.2 Wissenschaft im Dialog/Tag der offenen Tür ...... 77 2.5.3 Berichtsband ...... 77 2.5.4 InSiDe und Quartl ...... 77 2.5.5 Sonstige Aktivitäten im Umfeld des Hochleistungsrechnens ...... 78 2.6 Projekte und Kooperationen ...... 79 2.6.1 PRACE ...... 79 2.6.2 DEISA2 ...... 80 2.6.3 PROSPECT e.V...... 82 2.6.4 KONWIHR ...... 82 2.6.5 ISAR ...... 83 2.6.6 EU Projekt Scalalife ...... 83 2.6.7 Beteiligung an Workshops ...... 83 2.7 Tätigkeiten im Server-Betrieb ...... 83 2.7.1 Linux-Serversysteme ...... 83 2.8 Aktivitäten im Bereich „Verteilte Ressourcen“ ...... 87 2.8.1 Initiative for Globus in Europe (IGE) ...... 88 2.8.2 D-Grid: Förderung „e-Science und vernetztes Wissensmanagement“ des BMBF ...... 88 2.8.3 EGI-InSPIRE ...... 90 2.8.4 MAPPER ...... 90 2.8.5 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3) ...... 90 2.8.6 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) ...... 90 2.8.7 LRZ-Projekt „Eclipse4Grid“ ...... 91 2.8.8 Cloud-Computing ...... 91 2.8.9 Projektanträge 7. EU-Forschungsrahmenprogramm „e-Infrastrukturen“ ...... 92 2.8.10 Betrieb der Grid-Infrastruktur ...... 92 2.8.11 Sonstige Grid-Aktivitäten ...... 92 2.9 Managed Hosting für Hochschulstart.de ...... 93

3 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes ...... 95 3.1 Betrieb des Kommunikationsnetzes ...... 95

Jahresbericht 2010 des Leibniz-Rechenzentrums iii

3.1.1 Backbone-Netz ...... 98 3.1.2 Gebäude-Netze ...... 99 3.1.3 Rechenzentrumsnetz ...... 100 3.1.4 Wellenlängenmultiplexer ...... 101 3.1.5 WLAN (Wireless LAN) ...... 102 3.1.6 Wesentliche Netzänderungen im Jahr 2010 ...... 109 3.1.7 Netzausbau (Verkabelung) ...... 110 3.1.8 Anbindung Studentenwohnheime...... 110 3.2 Dienste ...... 113 3.2.1 Wählzugänge (Modem/ISDN) ...... 113 3.2.2 VPN ...... 115 3.2.3 DFN-Roaming ...... 117 3.2.4 Unterstützung von Veranstaltungen ...... 118 3.2.5 Internet-Zugang ...... 122 3.2.6 Service Load Balancer (SLB) ...... 124 3.2.7 Proxies und Zeitschriftenzugang ...... 124 3.2.8 Domain Name System ...... 125 3.2.9 DHCP-Server ...... 126 3.2.10 Voice over IP (VoIP) im Jahr 2010 ...... 127 3.2.11 Zugang über UMTS: Vodafone Sponsoring der Exzellenz Universitäten TU München und Ludwig-Maximilians-Universität München ...... 127 3.2.12 IPv6 im MWN ...... 127 3.3 Management ...... 129 3.3.1 Weiterentwicklung und Betrieb der Netzdokumentation ...... 129 3.3.2 Netz- und Dienstmanagement ...... 130 3.3.3 Überwachung der Dienstqualität des MWN mit InfoVista ...... 133 3.3.4 Action Request System (ARS) ...... 135 3.4 Sicherheit ...... 139 3.4.1 NAT-o-MAT/Secomat ...... 139 3.4.2 Security Information & Event Management...... 140 3.4.3 Zentrale Sperrliste ...... 141 3.4.4 Monitoring am X-WiN-Übergang ...... 141 3.4.5 Sicherheitswerkzeuge "Nyx" und "Nessi" ...... 142 3.4.6 Virtuelle Firewalls ...... 143 3.5 Projektarbeiten im Netzbereich 2010 ...... 143 3.5.1 D-GRID Projekt GIDS ...... 144 3.5.2 Customer Network Management ...... 148 3.5.3 Géant E2E Link Monitoring ...... 151 3.5.4 Géant I-SHARe ...... 152 3.5.5 Géant-Visualisierungswerkzeuge und Performance Monitoring ...... 153 3.5.6 100GET-E3...... 156

4 Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen ...... 159 4.1 Arbeitskreis Security ...... 159 4.2 Arbeitskreis IT-Service-Management ...... 159 4.2.1 Aktivitäten im Bereich IT-Service-Management am LRZ ...... 160 4.2.2 Weitere Aktivitäten im Bereich IT-Service-Management ...... 161 4.3 Arbeitskreis Continuity ...... 161 4.4 Arbeitskreis Informationsmanagement ...... 162

iv Inhaltsverzeichnis

5 Organisatorische Maßnahmen im LRZ ...... 163 5.1 Personalveränderungen 2010 ...... 163 5.1.1 Zugänge ...... 163 5.1.2 Abgänge ...... 164 5.2 Gebäudemanagement und Gebäudebetrieb ...... 164 5.2.1 Erweiterung des LRZ (Rechner- und Institutsgebäude) ...... 165 5.2.2 Energieeffizienz ...... 165 5.2.3 Personalausstattung der Hauswerkstätte ...... 166 5.3 Dienstleistungskatalog ...... 166 5.4 Mitarbeit in Gremien ...... 167 5.4.1 Abteilung „Benutzernahe Dienste und Systeme“ ...... 167 5.4.2 Abteilung „Hochleistungssysteme“ ...... 167 5.4.3 Abteilung „Kommunikationsnetze“ ...... 168 5.4.4 Abteilung „Zentrale Dienste“ ...... 168 5.5 Veranstaltungen am LRZ ...... 168 5.6 Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen ...... 169 5.6.1 Abteilung „Benutzernahe Dienste und Systeme“ ...... 169 5.6.2 Abteilung „Hochleistungssysteme” ...... 170 5.6.3 Abteilung „Kommunikationsnetze“ ...... 174 5.6.4 Abteilung „Zentrale Dienste“ ...... 175 5.7 Öffentlichkeitsarbeit ...... 176 5.8 LRZ als Ausbildungsbetrieb ...... 177 5.9 Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten ...... 177 5.10 Veröffentlichungen der Mitarbeiter 2010 ...... 178

6 Regelwerk des LRZ ...... 181 6.1 Satzung der Kommission für Informatik ...... 181 6.2 Mitglieder der Kommission für Informatik ...... 181 6.3 Benutzungsrichtlinien für Informationsverarbeitungssysteme ...... 181 6.4 Betriebsregeln des Leibniz-Rechenzentrums ...... 181 6.5 Richtlinien zum Betrieb des Münchner Wissenschaftsnetzes (MWN) ...... 181 6.6 Richtlinien zur Nutzung des Archiv- und Backupsystems ...... 181 6.7 Gebühren des Leibniz-Rechenzentrums ...... 181 6.8 Zuordnung von Einrichtungen zu LRZ-Betreuern ...... 181 6.9 Betriebs- und Organisationskonzept für den Höchstleistungsrechner in Bayern (HLRB) 181 6.10 Nutzungs- und Betriebsordnung für den Höchstleistungsrechner in Bayern (HLRB) ...... 181 6.11 Mitglieder des Lenkungsausschusses des Höchstleistungsrechners in Bayern (HLRB) ... 181

7 Technische Ausstattung ...... 183 7.1 Speicher ...... 183 7.2 Rechner und Server ...... 184 7.2.1 Höchstleistungsrechner SGI Altix 4700 ...... 184 7.2.2 Hochleistungs-Linux-Systeme ...... 185 7.2.3 Grid-Rechner ...... 188

Jahresbericht 2010 des Leibniz-Rechenzentrums v

7.2.4 Hochleistungs-Graphik-System ...... 188 7.2.5 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner ...... 189 7.3 Netzkomponenten ...... 193 7.3.1 Router ...... 193 7.3.2 Switches ...... 193 7.3.3 WLAN-Komponenten ...... 194 7.3.4 Netz-Server ...... 195

Jahresbericht 2010 des Leibniz-Rechenzentrums, Vorwort 1

Vorwort Der Jahresbericht 2010 des Leibniz-Rechenzentrums (LRZ) der Bayerischen Akademie der Wissenschaf- ten ist ein Beleg für das weitere quantitative und qualitative Wachstum dieser Einrichtung. IT- Dienstleistungen für Forschung, Lehre und Verwaltung werden für Kunden im Großraum München, in Bayern, Deutschland und zunehmend auch international, vor allem in Europa, erbracht. Besondere Schwerpunkte und neue Aufgabenstellungen des LRZ im Jahr 2010 waren insbesondere: • Mit der Erweiterung der Rechner- und Institutsgebäude wurde Platz für den nächsten Höchstleis- tungsrechner SuperMUC, für ein neues Visualisierungs- und Virtual-Reality-Zentrum sowie für neue Projektmitarbeiter – vor allem im Rahmen europäischer Projekte – geschaffen. Dabei wurde besonderer Wert auf eine neuartige Infrastruktur für energieeffizientes (Super-)Computing gelegt, das im Kontext der Beschaffung verschiedener Rechnersysteme zu einem neuen Themenschwer- punkt des LRZ wird. In Anwesenheit von Innenminister Joachim Herrmann konnte für die Ge- bäudeerweiterung am 18. Oktober mit zahlreichen prominenten Teilnehmern das Richtfest gefeiert werden. • Mit der feierlichen Vertragsunterzeichnung zwischen LRZ und der Firma IBM GmbH wurde am 13.12.2010 eine 9-monatige intensive Auswahlphase für den neuen Höchstleistungsrechner Su- perMUC im Rahmen eines Wettbewerblichen Dialogs erfolgreich abgeschlossen. In Anwesenheit des Staatsministers Dr. Wolfgang Heubisch wurde ein Superrechner für das Gauss Centre for Su- percomputing GCS e.V. als bayerischer bzw. deutscher Beitrag zur europäischen Infrastruktur PRACE (Partnership for Advanced Computing in Europe) beschafft, der in der ersten Ausbau- phase mit 3 PetaFlop/s (drei Billiarden Rechenoptionen pro Sekunde) zu den leistungsfähigsten Rechnern der Welt zählen wird. Mit IBM wurde darüber hinaus eine wissenschaftliche Koopera- tion zum Thema Energieeffizienz vereinbart, die neben der Erprobung neuester Kühlungstechnik auf Basis von Warmwasser auch spezielle Maßnahmen in Hardware und Software des Super- rechners, sowie neue Betriebsstrategien umfasst. Das LRZ erprobt hier neue Techniken, die zu- künftig vor allem in Hinblick auf hohe Energiekosten für weitere Bereiche des Rechnerbetriebs von besonderer Bedeutung sind. Mehrere erfolgreich eingeworbene Drittmittelprojekte unterstüt- zen diese Arbeiten des LRZ in den nächsten Jahren, die in enger Kooperation mit internationalen Partnern, vor allem aber mit Lehrstühlen der Ludwig-Maximilians-Universität München und der Technischen Universität München, durchgeführt werden. • Durch die Stiftung für Hochschulzulassung, Dortmund, wurde das LRZ beauftragt, den Infra- strukturbetrieb und das Managed Hosting des „Dialogorientierten Serviceverfahrens“ für die bundesweite Vergabe von Studienplätzen zu übernehmen. Nach der Konzeption und Beschaffung der entsprechenden Hard- und Software-Konfigurationen konnte im Herbst bereits der Testbe- trieb der Anwendung begonnen werden, die von der Fa. T-Systems MMS erstellt wurde. Die Be- auftragung dieser weiteren überregionalen Aufgabe erfolgte zunächst bis 31. März 2012. Den Mitarbeiterinnen und Mitarbeitern des LRZ möchte ich für ihre engagierte Arbeit danken. Mein besonderer Dank gilt aber auch der Leitung der Bayerischen Akademie der Wissenschaften, den zuständi- gen Ansprechpartnern im Bayerischen Staatsministerium für Wissenschaft, Forschung und Kunst sowie den Mitgliedern des HLRB-Lenkungsausschusses und der Kommission für Informatik, die die Arbeit des LRZ mit konstruktiver Kritik stets fachkundig unterstützt haben. Persönlich danke ich insbesondere den Mitgliedern des Direktoriums des LRZ, den Kollegen H. J. Bungartz, D. Kranzlmüller und H.-G. Hegering, die ihre große Fachkompetenz in die Leitung des LRZ mit eingebracht haben. Der vorgelegte Jahresbericht geht wieder bewusst über das Zahlenwerk üblicher Jahresberichte hinaus. Wir versuchen wie in den letzten Jahren, viele unserer Dienste und Geschäftspro- zesse zu erklären und unsere Konventionen und Handlungsweisen zu begründen. Dies soll die Komplexi- tät unserer Aufgabenstellung und das LRZ als Institution transparenter machen. Das LRZ nimmt aufgrund seiner Größe und Organisationsform, des Umfangs seines Versorgungsbereiches, der Anzahl seiner Nut- zer, Anzahl, Vielfalt und Heterogenität der Systeme, Beteiligung an Entwicklungsprojekten usw. eine deutliche Sonderstellung ein, die auch im Bericht sichtbar wird. Eine moderne IT-Infrastruktur ist essentiell für die Wettbewerbsfähigkeit der Hochschulen und des Lan- des, und so muss auch das IT-Kompetenzzentrum eng im Hochschulumfeld verankert sein. Das Leibniz- Rechenzentrum als das technisch-wissenschaftliche Rechenzentrum für die Münchner Hochschulen wird

2 Vorwort 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 bin überzeugt davon, dass es dem LRZ auch im Jahr 2010 erneut gelungen ist, die Erwartungshaltung seiner Nutzer einerseits, aber auch seiner Finanzgeber andererseits zu erfüllen und seine Dienstqualität und IT-Kompetenz erneut zu steigern. Ich freue mich auf die Zusammenarbeit mit Ihnen und die weitere Entwicklung im Jahr 2011.

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

Jahresbericht 2010 des Leibniz-Rechenzentrums 3

1 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

1.1 Kurse und Veranstaltungen Das LRZ bietet seinen Kunden regelmäßig mehr als 20 Kurse an, die sich in die Bereiche PCs und PC- Software, UNIX/Linux, Internet, Hochleistungsrechnen und weitere Veranstaltungen einteilen lassen. Die in den Tabellen 1 bis 5 aufgeführten Veranstaltungen wurden von ca. 900 Teilnehmern besucht. Zusätz- lich boten externe Anbieter weitere Kurse an, so dass die Gesamtteilnehmerzahl weit über 1.000 liegt.

1.1.1 Kursübersicht, Statistik 2010 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 PCs und PC-Software ist der Unterschied zwischen der Zahl der Anmeldungen und der Zahl der Teilnehmer nach wie vor groß. Dies hat hohen Verwaltungsaufwand für diese Kurse zur Folge, müssen doch bei jeder Absage auf einen erteilten Kursplatz wieder alle organisatorischen Schritte für die Nach- rücker durchlaufen werden. 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. Auf eine gedruckte Version des Kursprogramms wird seit 2010 verzichtet. Dies ermöglicht eine schnelle Aktualisierung, falls Kurse kurzfristig abgesagt werden müssen bzw. zusätzliche stattfinden. Auf den WWW-Seiten des LRZ ist immer die aktuellste Version zu finden. 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 PCs und PC-Software 2010 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Textverarbeitung mit Word 2007 (Kompaktkurs) 10 5 50 170 140 Word 2007 lange Dokumente, wiss. Arbeiten 12 2 24 40 22 MS-Excel 2007 (Kompakt- u. Fortsetzungskurs) 10 9 90 290 220 PowerPoint 2007 (Kompaktkurs) 9 2 18 60 35 Photoshop CS (Einsteigerkurs) 16 2 32 105 31 Access 2007 12 5 60 60 46 SPSS (Spezialkurs) 8 2 16 50 35 Insgesamt: 77 27 290 775 529

Tabelle 1: Kurse zu PCs und PC-Software

4 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Unix-Kurse und Praktika 2010 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Einführung in die Systemverwaltung unter Unix 65 1 65 21 21 Insgesamt: 65 1 65 21 21

Tabelle 2: Kurse zum Themenbereich Unix

Auch im Jahr 2010 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.

Internet 2010 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Barrierefreies Webdesign 3 1 3 14 11 Insgesamt: 3 1 3 14 11

Tabelle 3: Kurse zum Thema Internet Hochleistungsrechnen 2010 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Debugging serial and parallel applications with Allinea DDT 5 1 5 12 11 Data Mining of XML Data Sets using R 7 1 7 6 6 Eclipse: C/C++ programming (with a slight Fortran touch) 9 1 9 13 11 Advanced Fortran Topics 45 1 45 15 13 GPGPU Programming 21 1 21 32 27 Introduction to Molecular Modeling on Super- computers 14 1 14 16 11 Einführung in C++ für Programmierer 45 1 45 33 26 Introd. to the Usage of High Perf. Systems, Remote Visual. and Grid Facilities at LRZ 3 2 6 22 16 High-Performance Computing with GPGPUs 21 1 21 21 17 Parallel Programming with Cilk 18 1 18 15 13 Parallel Programming with R 7 1 7 6 5 Scientific High-Quality-Visualisation with R 7 1 7 10 8 Visualisation of Large Data Sets on Supercom- puters 7 1 7 8 8 Insgesamt: 209 14 212 209 172

Tabelle 4: Hochleistungsrechnen

Jahresbericht 2010 des Leibniz-Rechenzentrums 5

Weitere Veranstaltungen 2010 Dauer Anzahl Stunden Teilnehmer Teilnehmer Kurstitel (Stunden) Kurse insgesamt angemeldet teilgenommen Train the Trainer 7 2 14 21 11 Einführung in das Archiv- u. Backupsystem am LRZ 7 1 7 100 100 Professioneller IT-Betrieb in mittleren und gro- ßen Umgebungen 3,5 1 3,5 40 25 Insgesamt: 17,5 4 24,5 161 136

Tabelle 5: Weitere Kurse

1.1.2 Vorträge „Schattenseiten des Internet“ Die große Zahl der gemeldeten und selbst entdeckten Missbrauchsfälle (siehe Kapitel 1.9) 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/).

Abbildung 1: 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. Für Eltern und Lehrer einerseits und Jugendliche ab 12 Jahren andererseits

6 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS) stehen angepasste Varianten zur Verfügung. Die beiden Schwerpunkte des Vortrags behandeln Problem- bereiche, die Kinder, Jugendliche und Erwachsene gleichermaßen betreffen: • In den letzten beiden Jahren wird das Thema „Abzocker im Internet“ relativ häufig in Presse und Fernsehen behandelt. Dennoch fallen allein in Deutschland jährlich mehrere Hunderttausend Inter- net-Nutzer auf die vielen unseriösen Angebote herein. Etwa 40% der Opfer kennen ihre Rechte zu wenig und zahlen deshalb die geforderten Beträge zwischen 60 und 200 Euro, obwohl dies überhaupt nicht erforderlich wäre. • Alle Nutzer des Internet unterliegen mehr oder weniger umfangreichen rechtlichen Pflichten. Ein Verstoß dagegen (z.B. gegen das Urheberrecht) kann mehrere Tausend Euro kosten! Leider kennen praktisch keine Jugendlichen und nur wenige Erwachsene diese Art von Gefahren. Im Jahr 2010 wurden durch diesen Dienst des LRZ mehr als 1300 interessierte Zuhörer erreicht (Schul- klassen und Eltern an mehreren Gymnasien).

1.2 Software-Versorgung für Rechnersysteme außerhalb des LRZ Das LRZ liefert seinen Kunden Software-Lizenzen zu günstigen Konditionen. Mit der Bündelung der Nachfrage über Instituts- und Hochschulgrenzen hinweg wird auch Verhandlungsmacht 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 Kooperation mit Instituten und Hochschulen, teilweise auf das Münchner Wissenschaftsnetz (MWN) beschränkt, teilweise überregional, geeignete Abkommen mit Händlern und Herstellern. Welche Software von welchen Nutzern zu welchen Konditionen über das LRZ bezogen werden kann, ist auf der Webseite www.lrz.de/services/swbezug dargestellt. Tabelle 6 listet die wertmäßig umsatzstärksten Softwarepakete (nur Kauflizenzen) auf. Miet- und Sub- skriptionsmodelle (SPSS, Matlab, Novell, SAS) sowie Pauschal-Verträge (ESRI, Sophos) werden nicht in dieser Tabelle erfasst. Die Zahlen zu Microsoft und Adobe sind geschätzt (die exakten Zahlen gehen über die Kalenderjahresgrenzen hinweg).

Hersteller / Name Beschreibung Lizenzzahlen 2010 Bruttowert der 2010 beschafften Lizen- zen Microsoft Applikationen, Sys- 28.000 Ca. 899.000 € tem- und Server- Software Adobe Acrobat, Photoshop, 3.000 Ca. 474.000 € GoLive, Illustrator, Premiere etc. Corel Grafiksoftware 325 15.303,- € Endnote Literaturverarbeitung 393 42.061,74 € Systat Datenanalyse und 42 14.025,- € Datenpräsentation

Tabelle 6: Die umsatzstärksten Softwarepakete

1.2.1 Landesweiter ESRI Vertrag In Kooperation mit der FH Würzburg-Schweinfurt und der Universität Würzburg konnte ein landesweiter Vertrag mit der Firma ESRI (ArcGis Geoinformationssysteme) abgeschlossen werden, in den die bestehenden Verträge der bayerischen Hochschulen und Unikliniken integriert werden konnten (auch der Campusvertrag für das MWN wird zu gleichbleibenden Konditionen in den neuen Vertrag überführt).

Jahresbericht 2010 des Leibniz-Rechenzentrums 7

Wichtigster Vorteil ist, dass nun auch kleine Hochschulen Lizenzen zu sehr günstigen Konditionen beziehen können. Außerdem werden dadurch Administration und Abrechnung vereinfacht, und somit Hoch- schulmitarbeiter entlastet. Neben dem LRZ versorgen sich nun elf weitere Hochschulen über diesen Ver- trag. Für alle anderen Hochschulen und Unikliniken in Bayern besteht die Option zur späteren Teilnahme zu definierten Konditionen.

1.2.2 Landesweiter Secunia Vertrag In Kooperation mit u. a. der Universität Augsburg konnte ein landesweiter Vertrag mit der Firma Secunia abgeschlossen werden, der elf Hochschulen die Nutzung der gleichnamigen Produktpalette zu einem pau- schalen, sehr günstigen Preis ermöglicht. Secunia ist ein Schwachstellen- und Patchscanner, der installierte Programme identifiziert und fehlende Sicherheitspatches für Windows-Betriebssysteme und -An- wendungen aufzeigt.

1.2.3 Weitere neue oder geänderte Verträge Im Berichtsjahr stand die Neuverhandlung von Verträgen für die Produkte Mathematica (MWN, Ver- tragspartner Additive), Amira (MWN, Vertragspartner VisageImaging), CoCreate (MWN, Vertrags- partner Parametric Technology PTC) an. Die neu verhandelten Verträge bieten den Kunden des LRZ insgesamt sehr günstige Konditionen.

1.2.4 Routinemäßige Verlängerung bestehender Verträge Routinemäßig verlängert wurden u. a. der Adobe CLP Rahmenvertrag (bundesweit gültig), Mietverträge zu SPSS (Großteil der bayerischen Hochschulen), Ansys, LabView, Matlab, und SAS (alle MWN-weit). Für Adobe-Produkte musste das LRZ im Frühjahr den Handelspartner für die Versorgung des MWN wechseln, da der bisherige Händler erheblich höhere Preise durchsetzen wollte. So konnten den versorgten Instituten empfindliche Preiserhöhungen erspart werden.

1.2.5 Status Microsoft Select-Plus Lizenzen Die im Sommer 2009 abgeschlossenen Select-Plus Rahmenverträge brachten für die bayerischen Hoch- schulen, Universitäten und Unikliniken einige Änderungen in der Verwaltung u. a. der Lizenzschlüssel mit sich. Hier war das LRZ beratend tätig, und hat zwischen den Einrichtungen und Microsoft vermittelt, um die neuen Abläufe zu definieren und zu verstetigen. Das LRZ hat darüber hinaus 2010 einen so genannten KMS Server für die akademischen Einrichtungen des MWN eingerichtet, um die lokalen Admi- nistratoren bei der Aktivierung von Microsoft Installationen zu entlasten.

1.2.6 Betrieb von Lizenzservern für externe Systeme am LRZ Das LRZ betreibt derzeit ca. 30 Lizenzserver, die für die Benutzer im MWN Netzwerklizenzen zur Ver- fügung stellen. Das angebotene Spektrum der Netzwerklizenzen beinhaltet vor allem technisch wissenschaftliche Software (Matlab, Mathematica, Maple, Ansys, Patran, ...). Der Betrieb von Lizenzservern am LRZ erspart den Mitarbeitern in den Instituten den dezentralen und redundanten Aufbau eigener Server und damit viel Arbeit.

1.2.7 Verträge mit Instituten im MWN Im Sommer wurde ein Vertrag mit der Fakultät für Geowissenschaften der LMU geschlossen, der die Versorgung der Institute dieser Fakultät mit ArcGis Produkten der Fa. ESRI vereinfacht und verbessert (Flatrate für die gesamte Fakultät statt Einzelabrechnung nach Produkten und Lehrstühlen).

1.2.8 Laufende Verhandlungen und Planungen Mit der Universität Würzburg wird die Verlängerung des bayernweiten Rahmenvertrags für Microsoft Mietlizenzen (bekannt als "Microsoft Campus", heißt künftig „Enrollment for Education Solutions“) für

8 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

2011 vorbreitet, dafür und für die im Vorjahr geschlossenen Microsoft Select-Plus Rahmenverträge (Kauflizenzen) werden Händlerausschreibungen (mit Würzburg als Vergabestelle) vorbereitet. Gemeinsam mit dem Regionalen Rechenzentrums Erlangen (RRZE) arbeitet das LRZ an einem SPSS Landesvertrag. Das ist erforderlich, da IBM, der neue Eigentümer der Firma SPSS, die bisherigen Miet- verträge nicht verlängern wird, die SPSS separat jeweils mit dem RRZE und dem LRZ geschlossen hatte.

1.2.9 Zusammenfassung Die umsatzstärksten Softwarepakete im letzten Jahr waren: • Microsoft-Lizenzen im Rahmen der Select-Plus-Verträge • Adobe- und Corel-Bestellungen im Rahmen des CLP-Vertrags Bei Microsoft und Adobe/Corel-Bestellungen kümmert sich das LRZ im Tagesgeschäft lediglich um Au- thentifizierung/Autorisierung der Besteller, Verteilung der Software, Beratung und Unterstützung bei der Bestellung, Lizenzierung und Aktivierung. Die kaufmännische Abwicklung erfolgt über Handelspartner. Dabei kommen jährliche Umsätze im sechsstelligen Bereich zustande. Bei den meisten anderen Produk- ten 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: hier sind derzeit die höchsten Wachstumsraten zu verzeichnen. Da das LRZ hier einen zentralen Lizenzserver für das MWN betreibt (und Lehrstühle bzw. Institute individuell abrech- net), ist allerdings auch der administrative Aufwand im Berichtszeitraum empfindlich gestiegen. Der Umsatz im MWN erreichte 2010 ca 100.000 Euro. • 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 Soft- warelizenzen online zu bestellen. Hierzu zählen die Münchner Universitätskliniken mit ihrem jeweiligen Zentraleinkauf, die Universität Augsburg, einige Fachhochschulen aus dem südbayerischen Raum sowie einige kleinere Einrichtungen. Darüber hinaus werden einige hundert Lehrstühle, Arbeitsgruppen und Institute im MWN durch das LRZ individuell mit diversen Lizenzen versorgt, betreut und beraten. Novell- und Sophos-Produkte (künftig auch ESRI- und Secunia-Produkte) werden den bayerischen Uni- versitäten und Hochschulen nach einem festen Kostenschlüssel bereitgestellt, daher gibt es an dieser Stel- le keine Umsatzzahlen (die ESRI-Produkte werden auf Campusebene mit den Instituten abgerechnet).

1.3 Benutzerverwaltung und Verzeichnisdienste Bei der Vergabe von Kennungen an Hochschuleinrichtungen und Studenten arbeitet das LRZ sehr eng mit den beiden Münchner Universitäten zusammen. Abschnitt 1.3.1 gibt einen Überblick über die derzeit vergebenen Kennungen und ihre Verteilung auf die LRZ-Plattformen. In Abschnitt 1.3.2 wird die Weiter- entwicklung des LRZ-Identity-Management-Systems (LRZ-SIM) beschrieben, dessen Datenbasis und Konfiguration komplett auf LDAP-Verzeichnisdiensten basiert. Die an LRZ-SIM angebundenen Dienste und deren Nutzer profitieren dabei von der direkten Kopplung mit den LMU- und TUM-seitigen Hoch- schulverzeichnisdiensten. Die für die TUM am LRZ entwickelte Verzeichnisdienst-Infrastruktur, ihren Regelbetrieb und ihre Fortentwicklung beschreibt Abschnitt 1.3.3. Ein weiteres sehr dynamisches Ar- beits- und Forschungsgebiet ist die Authentifizierungs- und Autorisierungsföderation des DFN (DFN- AAI), in der das LRZ als Dienstleister und sogenannter Identity-Provider für die LMU und TUM fungiert und hochschulintern wie auch föderationsweit an der Gestaltung aktiv mitwirkt (Abschnitt 1.3.4).

1.3.1 Für LRZ-Systeme vergebene Kennungen

1.3.1.1 An Hochschuleinrichtungen vergebene Kennungen Die folgende Tabelle gibt einen Überblick über die vom LRZ an Hochschuleinrichtungen (via Master User) vergebenen Kennungen, und zwar pro Dienst bzw. Plattform und mit Stand von Ende 2010.

Jahresbericht 2010 des Leibniz-Rechenzentrums 9

Ex- Sun- Linux- Einrichtung VPN Mail AFS PC change Cluster Cluster Leibniz-Rechenzentrum 647 1.020 130 314 312 176 1.065 Bayerische Akademie der Wiss. (ohne LRZ) 367 370 43 44 41 – 337 Ludwig-Maximilians-Universität München 10.880 10.220 278 755 720 792 1.313 Technische Universität München 8.487 8.677 4.561 827 810 688 438 Hochschule München 424 392 – 97 94 40 8 andere bayerische Hochschulen 388 280 – 32 27 140 169 Öffentlich-rechtliche Einrichtungen 2.879 2.866 – 155 153 20 402 sonstige Einrichtungen 28 1 – 2 2 12 1 Kooperationsprojekte aus dem Grid-Bereich – – – – – 879 – Nutzer des Bundeshöchstleistungsrechners 14 3 – – – 233 – Gesamt 24.114 23.829 5.012 2.226 2.159 2.980 3.733

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

Für die TU München werden Exchange-Berechtigungen direkt über TUMonline vergeben, nicht über die Master-User-Schiene. Nicht in der Tabelle enthalten sind die Kennungen für den Bundeshöchstleistungsrechner, die SGI Altix 4700, da es hier häufig Kooperationen gibt und daher keine klare Zuordnung zu einer Einrichtung mög- lich ist. Ende 2010 waren für diesen Rechner insgesamt 2.536 Kennungen vergeben, davon 1.167 für Projekte aus dem Grid-Bereich.

1.3.1.2 An Studenten vergebene Kennungen Die Vergabe von Kennungen an Studenten erfolgt bei der Ludwig-Maximilians-Universität und bei der Technischen Universität gekoppelt mit der Vergabe von Kennungen für das Web-Portal CampusLMU bzw. das Campus-Management-System TUMonline. Für Studenten anderer Münchner Hochschulen erfolgt die Vergabe individuell und direkt durch das LRZ. Ende 2010 hatten knapp 85.000 Studenten (Vorjahr: ca. 82.000) eine Kennung, die u.a. für Mailzwecke und für den VPN-Zugang ins MWN genutzt werden konnte. Hier die Aufteilung auf die Hochschulen mit den meisten Kennungen:

Anzahl Hochschule Kennungen Ludwig-Maximilians-Universität München 51.903 Technische Universität München 31.248 Hochschule für Musik und Theater München 1.042 Hochschule für Fernsehen und Film München 205 Akademie der Bildenden Künste München 105 Hochschule für Philosophie München 42 Verwaltungs- und Wirtschaftsakademie München 20 FernUniversität Hagen 20 Hochschule für Politik München 16 sonstige Hochschulen 78 Gesamt 84.679

Tabelle 8: Vergabe von Kennungen an Studenten

10 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

1.3.2 LRZ Secure Identity Management (LRZ-SIM) Das neue zentrale LRZ Identity&Access-Management-System (IDM) mit dem Projektnamen LRZ-SIM („LRZ Secure Identity Management“) lief in seinem mittlerweile dritten Einsatzjahr stabil und zuverläs- sig. Die Flexibilität seiner Architektur zeigte sich bei der Programmierung vieler weiterer Automatismen und Optimierungen für die Benutzerverwaltungsprozesse, die für erhöhten Benutzerkomfort, weniger manuelle Erfassungsarbeit sowie auch für eine weitere Verbesserung der Datenqualität, Datenaktualität und Datensicherheit sorgen. Die internen Strukturen und Betriebsabläufe wurden laufend weiterentwickelt und optimiert und eine Reihe weiterer LRZ-Systeme über LDAP-Authentifizierung oder Provisio- nierung von Benutzerdaten angebunden. Um die zentrale Benutzerverwaltung weiter zu automatisieren, den manuellen Aufwand durch Mehrfach- registrierung und -pflege von Benutzern zu vermeiden und um Redundanzen und Inkonsistenzen weitest möglich zu reduzieren, ist der Import von Benutzerdaten der beiden großen Münchener Universitäten und ihren Berechtigungen weiter vorangebracht worden. Die Übernahme der Daten aus dem zentralen Ver- zeichnis der Ludwig-Maximilians-Universität (LMU) ist schon seit Längerem im Einsatz. Bei den Mitar- beiterdaten sind fakultätsweise nach individuellen Vereinbarungen weitergehende Datenimporte einzu- richten. Die Anbindung an die TUM-Directorys ist nach intensiver Testphase gut vorbereitet, und wird Anfang 2011 in Produktionsbetrieb gehen. Dabei werden dann alle TUM-Benutzer mit allen LRZ- relevanten Berechtigungen in einem Zug nach LRZ-SIM übernommen werden können.

1.3.2.1 Überblick und aktueller Stand der Identity-Management-Architektur Während die IDM-Kernarchitektur, wie sie im März 2008 in Produktionsbetrieb ging, beibehalten wurde, gab es 2010 im Detail etliche Weiter- und Neuentwicklungen, sowohl beim Datenmodell als auch besonders beim LRZ-Identity-Management-Portal (Id-Portal), bei den angeschlossenen Datenquellen, bei den Konnektoren und bei den angebundenen Systemen. Abbildung 2 zeigt die aktuelle logische Struktur des IDM-Systems mit seinen Erweiterungen und Ände- rungen bis Ende 2010. Die einzelnen Verzeichnisdienste erfüllen mit einem für den jeweiligen Zweck optimierten Datenschema unterschiedliche Aufgaben: • Der Authentifizierungs-Satellit dient der Anbindung der vielfältigen LRZ-Dienste über LDAP- Authentifizierung und -Autorisierung. • Der Applikations-Satellit ist Datenbasis für das Id-Portal mit Management-Funktionalität sowie für LRZ-Plattformen mit Bedarf an Attributen, der über den Umfang des Authentifizierungs- Satelliten hinausgeht. • Der Import-Export-Satellit regelt den Datenaustausch mit den beiden Münchner Universitäten sowie auch mit der LRZ-Personaldatenbank. • Das Metadirectory im Zentrum koordiniert den Abgleich der Datenbestände über Konnektoren (dicke Pfeile). • Ein durch die Diversifizierung der LRZ-Maildienste und -systeme notwendig gewordenes Mail- forwarder-Verzeichnis ist Grundlage für die Annahme und Bearbeitung von E-Mails (Zustellun- gen, Weiterleitungen und Abwesenheitsnotizen). • Neu hinzugekommen ist die Provisionierung eines zweiten Active Directorys für den Eduroam- Dienst des DFN sowie Server für Webservices, über die momentan die Vergabe von LRZ- Kennungen und Mailadressen kanalisiert wird. Alle Verzeichnisse sind redundant und hochverfügbar implementiert. Angeschlossene Systeme können über LDAP-Verbindungen direkt die Datenbestände in den Verzeichnissen nutzen (dünne Pfeile) oder auf höherer Ebene die Webservices über SOAP-Requests ansprechen.

Jahresbericht 2010 des Leibniz-Rechenzentrums 11

Abbildung 2: Architekturmodell und Integration des LRZ-Identity-Managements

1.3.2.2 Entwicklungen im Server- und Dienstbetrieb Die umfangreiche produktive Server-Infrastruktur innerhalb von LRZ-SIM erforderte eine kontinuierliche Aktualisierung der eingesetzten Software, um bei Releases und Patches auf dem aktuellen Stand zu bleiben, und zwar sowohl auf Betriebssystem-Ebene (SuSE Linux), auf Verzeichnisdienst-Ebene (Novell eDirectory und OpenLDAP) als auch auf IDM-Ebene (Novell Identity Manager, iManager und Designer). Um den unterbrechungsfreien Betrieb dauerhaft gewährleisten zu können, wurde der Software- Loadbalancer-Rechner dupliziert und mit einer aktuelleren Version samt Webfrontend ausgestattet. Alle Konnektoren sind in Standby-Konfiguration auf jeweils einem weiteren Rechner installiert und können bei Ausfall des Hauptservers, dessen Directory-Services oder dessen Konnektoren rasch für die Fortfüh- rung des Datenaustauschs aktiviert werden. Parallel zu den Produktionsservern wurde auch die Testumgebung kontinuierlich auf dem aktuellen Stand gehalten. Alle Testserver wurden virtualisiert und schrittweise mit neuen Versionen von Betriebs- system, Verzeichnisdienst- und IDM-Software ausgestattet. Sehr bewährt hat sich das Vorgehen, alle Erweiterungen im Id-Portal und Neuimplementierungen von Konnektoren durchwegs zuerst in der Te- stumgebung zu entwickeln und dort ausführlich mit Real-Life-Datensätzen zu erproben. Ein Schwerpunkt der Arbeit lag im Bereich IT-Sicherheit. Auf den LDAP- und Webservern von LRZ- SIM kommen nun durchwegs DFN-signierte Serverzertifikate zum Einsatz. Kontinuierliche Betriebssys- tem- und Serversoftware-Updates sorgen für die Basissicherheit. Neben selbst programmierten dedizierten Überwachungstools wurde das zentrale Monitoring mit Cacti und Nagios auf alle zentralen Server, Konnektoren und Dienste ausgedehnt. Schließlich erfolgte eine unabhängige Sicherheitsüberprüfung des Id-Portals durch das Bayern-CERT.

12 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Schließlich konnte die Domain-Umstellung von lrz-muenchen.de auf lrz.de (für internetweit erreichbare Server) bzw. sim.lrz.de (für Server, die nur aus dem LRZ- oder Münchner Wissenschaftsnetz erreichbar sind) für alle Testrechner, Webserver und Shibboleth-Server durchgeführt und für die produktiven LDAP- Server vorbereitet werden. Für den nahtlosen Übergang wurden sowohl in den neu beantragten Zertifika- ten als auch im DNS die Namen mit den alten Domains als Aliase mitgeführt.

1.3.2.3 Identity Management und zentrale Benutzerverwaltung Das Id-Portal ist die nach außen am deutlichsten sichtbare Komponente der LRZ-Benutzerverwaltung und ermöglicht nicht nur Master Usern, alle Aufgaben rund um die Verwaltung der ihnen zugeteilten Kennungen effizient zu erledigen, sondern dient auch als Self-Service-Oberfläche für alle Benutzer. Viele Funktionen des Id-Portals konnten im Detail verbessert und benutzerfreundlicher gestaltet werden, nicht zuletzt auch durch das Feedback aus der täglichen Benutzungspraxis durch die LRZ-Hotline, die LRZ- Administratoren, die LRZ-Betreuer und die Master User. Zusätzlich zum Id-Portal, dem Webserver für interaktiven Zugang, wurde ein Server für sogenannte Webservices aufgesetzt, die im Rahmen des automatischen Datenaustauschs insb. mit TUM und LMU erforderlich waren. Über reine LDAP-Anfragen hinaus sind hier Dienste mit mehr serverseitiger Pro- grammlogik möglich, wie sie für die Generierung von Kennungen oder die Abfrage möglicher freier E- Mail-Adressen notwendig ist. Auch bei der Datenqualität der in LRZ-SIM verwalteten Einträge konnten durch vielfältige Maßnahmen Verbesserungen erzielt werden: Die Sammlung von Skripten zur Überprüfung des Datenbestands innerhalb eines Directorys sowie zwischen verschiedenen Directorys bzw. zwischen Directorys und angeschlossenen Plattformen wurde ständig erweitert. Die Überprüfungen zur Datenkonsistenz erwiesen sich insbesondere auch bezüglich der automatisch importierten Benutzerdaten als hilfreich, da neben TUM- und LMU-Konnektoren auch Daten der Grid-User-Administration (GUA) direkt per LDAP in LRZ-SIM- Verzeichnisse geschrieben werden. Damit erfolgt die Eintragung dieser Grid-Benutzerdaten ohne erweiterte Prüfung, wie sie sonst über das Id-Portal, die IDM-Konnektoren oder die Webservices möglich sind. Zu nennen sind hier die internen LRZ-IDs, die die Softreferenzen wechselseitig zwischen Kennungs-, Personen-, Projekt- und Organisationsobjekten bilden und deren Konsistenz nicht vom LDAP-Server erzwungen werden kann.

1.3.2.4 Integration von LRZ-Diensten und Plattformen Im Laufe des Jahres konnten einige weitere LRZ-Dienste und -Plattformen erfolgreich an die LRZ-SIM- Verzeichnisse angebunden und ins zentrale Identity&Access-Management integriert werden. Darunter befanden sich Systeme mit sehr großer Benutzerzahl wie die Mail- und Groupware-Plattform Exchange 2010. Neu hinzu kam die Anbindung folgender Dienste: • Die neue, zentrale LRZ-IT-Service-Management-Plattform (iET) verwendet LDAP- Authentifizierung und importiert Benutzerdaten per LDAP. Gespräche für spezielle Workflows wie die Bestellung von virtuellen Servermaschinen und die dafür notwendigen Attribute haben stattgefunden. • Für das bereits an LRZ-SIM angebundene Netzverantwortlichenportal NeSSI wurden diejenigen Netzverantwortlichen ermittelt, die noch keine LRZ-Kennung hatten. Die Berechtigungsvergabe selbst und der Workflow in der Netzabteilung werden SIM-seitig mit einem eigens entwickelten Webfrontend unterstützt. • Ein Kernsystem des LRZ-Betriebs, das Netzkomponenten-Management für Switches, Router und Gateways, wurden auf LDAP-Authentifizierung umgestellt. Dedizierte Gruppen zur Autorisie- rung auf einzelnen Komponenten sind ebenfalls über SIM-Attribute realisiert. • Das Monitoring-System Cacti war bereits als Plattform in LRZ-SIM aufgenommen. Umgekehrt wurde die Kopplung soweit ausgedehnt, dass für die LRZ-SIM-Verzeichnisdienste die LDAP- Antwortzeit – eine wichtige und kritische Größe für nahezu alle angebundenen Systeme – in den Cacti-Graphen online darstellbar ist. • Jedes Projekt kann für die Nutzung des Backup- und Archivsystems TSM freigeschaltet werden, Master User können selbst Kennungen zur TSM-Nutzung berechtigen. Details des Vergabepro- zesses wurden verbessert, so dass z.B. auch bei der Deprovisionierung die Löschung von Ken- nungen mit aktiven TSM-Knoten verhindert wird. • Mailattribute wurden nach Mandanten und Mailsystemen (TUM, LMU-Studenten, LMU-

Jahresbericht 2010 des Leibniz-Rechenzentrums 13

Weiterleitungen, externe Studenten und über Master User verwaltete Benutzer) getrennt und kön- nen an Kennungen, die mehrfache Rollen erfüllen, auch entsprechend mehrfach vergeben werden. • Die Provisionierung des zentralen Microsoft Active Directorys (MWN-ADS) wurde auf einen neuen Konnektor umgestellt (Novell Scripting Driver), mit dem auch Exchange-spezifische Vor- gänge angestoßen werden können. Damit wurde die Voraussetzung für die Produktivführung von Microsoft Exchange für LRZ-Kunden (insb. die LMU) geschaffen. Weiterleitungsadressen und Abwesenheitseinstellungen wurden nach LRZ-SIM geholt, werden nun dort verwaltet und in ein eigenes Forwarder-Directory provisioniert. • Für Eduroam, das System für komfortable europaweite VPN-Verbindungen, wurde ein weiteres, lizenztechnisch günstig zu betreibendes Active Directory aufgebaut, das ebenfalls direkt aus LRZ-SIM per Scripting Treiber befüllt wird. • In Zusammenarbeit mit der Gruppe HLR wurde der Workflow und das Webformular zur Bean- tragung von Linux-Cluster-Berechtigungen grundlegend neu gestaltet, um die Beantragung bei den Master Usern zu bündeln und die manuelle Verwaltungsarbeit auf einen Genehmigungsklick zu reduzieren. • Für die High-Performance-Computing-Plattformen wurde die Provisionierung der HPC- Datenbank (MySQL) auf die relevanten Benutzerkennungen reduziert und damit eine deutliche Erhöhung der Aktualisierungsfrequenz möglich. Darüber hinaus regelt ein neuer Prozess das Lö- schen von HPC-Projekten, unterstützt durch neue Attribute im Verzeichnis und neue Spalten in der HPC-Datenbank, um dauerhaft die Zuordnung von Kennungen auch zu ehemaligen Projekten verfolgen zu können. • Die Integration von Grid-Kennungen wurde vorbereitet und prototypisch für einen Teil der DEI- SA-Kennungen durchgeführt. Die Teilnahme an den Grid-Verbünden setzt voraus, dass deren jeweilige Benutzerverwaltungsinfrastrukturen verwendet werden. Um den doppelten Datenpflege- aufwand sowohl in den LRZ- als auch den jeweiligen Grid-Systemen einzusparen und die damit verbundenen Fehlerquellen zu vermeiden, soll die LRZ-SIM-Kopplung mit Grid-Systemen weiter ausgebaut werden.

1.3.2.4.1 CampusLMU-Anbindung Die im vergangenen Jahr vollständig überarbeitete Ankopplung von LRZ-SIM an den CampusLMU- Verzeichnisdienst wurde weiter ausgebaut: Die Menge der übermittelbaren Dateninhalte, insb. Mailattri- bute, wurde erweitert, um den von den Zielsystemen gebotenen neuen Möglichkeiten (mehrere Mailbo- xen, Exchange-Nutzung) Rechnung zu tragen. Die von CampusLMU gesteuerte Berechtigungsvergabe für LRZ-Dienste umfasst neben fakultätsweit vereinbarten Regeln (Autorisierung für VPN/Eduroam, Desktop-Management/PC, Mail und Linux- Cluster) nun auch pro Kennung individuell von CampusLMU festlegbare Autorisierungen (Entitlements). Dadurch werden die Workflows transparenter und im Support-Fall für den CampusLMU-Helpdesk besser nachvollziehbar, da die Berechtigungen explizit im CampusLMU-Verzeichnis hinterlegt sind. Eine neue erweiterbare Webservice-Schnittstelle auf LRZ-Seite bietet für CampusLMU zudem einen direkten, schnellen und sicheren Weg zur Abfrage relevanter Benutzerinformation (z.B. freie Mailadressen, neue LRZ-Kennung). Das Anlegen eines LMU-Accounts im Rahmen der CampusLMU-Erstregistrierung kann damit komplett abgeschlossen werden, ohne später dem Benutzer zusätzliche Aktionen am LRZ Id- Portal abverlangen zu müssen.

1.3.2.4.2 TUMonline-Anbindung Die Konzeption zur Provisionierung der relevanten Teile des TUMonline-Datenbestands in die LRZ- Benutzerverwaltung wurde auf technischer Ebene konkretisiert. Nach Klärung der datenschutzrechtlichen Aspekte wurde aus den Erfahrungen der TUMonline-Migration ein Weg gefunden, wie zwar die Identitäten (reale Personen) möglichst umfassend aus beiden Quellen konsolidiert werden können, dabei aber für bestehende Kennungen und die daran gebundenen Ressourcen (z.B. Mailadressen, Homedirectorys) ein für die Benutzer sanfter Übergang ohne Zeitdruck hin zu einheitlichen Kennungen möglich ist. Damit wird für alle TUM-Angehörigen die Pflege der Stammdaten einheitlich über TUMonline erfolgen und von dort übernommen werden können. Weitergehende Berechtigungen zu LRZ- Diensten werden dann nur noch den von TUMonline importierten und nicht den alten LRZ-Kennungen zugeordnet werden.

14 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Die Ankopplung von LRZ-SIM an den TUM-Administrationssatelliten befindet sich mittlerweile in intensiver Testphase und kann voraussichtlich bis Anfang 2011 produktiv genommen werden. Dadurch werden TUM-Angehörige auch weitere LRZ-Dienste – über VPN, Mail und Online-Speicher hinaus – ohne eine zweite LRZ-Kennung nutzen können. Für die lokalen Ansprechpartner an den Fakultäten, die Master User, bedeutet dies Entlastung von viel Routine- und unnötiger Doppelerfassungsarbeit. Für das LRZ wird es ein großer Fortschritt hinsichtlich der Aktualität und Gültigkeit der TUM-Benutzerdaten sein.

1.3.2.5 Betriebszustand Zusammenfassend kann festgestellt werden, dass auch das dritte Betriebsjahr des neuen Identity- Management-Systems LRZ-SIM wie erwartet eine Menge Entwicklungsarbeit sowohl für interne Verbes- serungen als auch für die Anbindung weiterer Plattformen und Dienste mit sich brachte. Darin zeigten sich aber auch die flexible Erweiterbarkeit der Architektur und das Potential für die Nutzung der neuen technischen Möglichkeiten. LRZ-SIM hat sich als moderne Identity&Access-Management-Lösung etabliert und wird in zunehmendem Maß auf Kundenseite wahrgenommen und geschätzt.

1.3.2.6 Kooperationen Durch die aktive Teilnahme am ZKI-Arbeitskreis „Verzeichnisdienste“ und am bayerischen Arbeitskreis „Meta-Directory und AAI“, sowohl in Tagungen als auch über Videokonferenzen, konnte hochschulüber- greifend Kompetenz, Wissen und Erfahrung für die Optimierung von Implementierungsdetails genutzt werden. Der Austausch von Konzepten und Erkenntnissen ist ein wichtiger Baustein dafür, dass das LRZ sowohl hinsichtlich der Anzahl der zu verwaltenden Benutzer als auch der zur Verfügung gestellten Dienste und Rechnerplattformen eine der im deutschen Hochschulumfeld aufwändigsten Identity&Access-Management-Lösungen mit sehr hohen Anforderungen erfolgreich betreibt.

1.3.2.7 Ausblick Der wichtigste erste Schritt für weitere Arbeiten wird die Produktivführung der TUMonline-Anbindung sein. Nach der langen und intensiven Vorbereitungsphase und den erfolgreichen Tests ist hier mit keinen größeren Hindernissen zu rechnen. Eine weitere Planung betrifft die Implementierung und den Einsatz von Gruppen als Autorisierungs- grundlage für Benutzer etlicher LRZ-Dienste. Neben einer Schema-Erweiterung wird die Hauptarbeit auf Design und Implementierung des Frontends im Id-Portal liegen. Schließlich ist für nachgelagerte Systeme und Verzeichnisse, die nicht einfach über LDAP authentifizieren, die Aufbereitung und Übergabe dieser zusätzlichen Daten zu planen und zu programmieren. Parallel dazu ist die Unterstützung von Funktionsobjekten zu planen, insbesondere für die stark nachgefragten Shared Mailboxen und Mailverteilerlisten für Exchange. Wie bei den Gruppen wird sich die Struktur an den schon in den TUM-Verzeichnissen implementierten Objekten orientieren. Die positiven Erfahrungen mit virtuellen Servern sollen für einen wichtigen LRZ-internen Dienst, den ID-Server, genutzt werden. Dessen Virtualisierung, zusammen mit einer Migration der Datenbasis auf eine SQL-Datenbank, sollte noch vor der Rechenzentrumserweiterung abgeschlossen werden. Die schon vorbereiteten OpenLDAP-Authentifizierungs-Server werden nach eingehender Testphase die Umstellung der restlichen Mailsysteme mit großem Benutzerbestand von Kerberos- auf LDAP- Authentifizierung erlauben, samt all den damit möglichen, wesentlich differenzierteren Autorisierungsop- tionen.

1.3.3 TUM-Verzeichnisdienste Nach dem planmäßigen Auslaufen der DFG-Förderung des Projekts IntegraTUM Ende 2009 (vgl. Bode, A., Borgest, R.: Informationsinfrastrukturen für Hochschulen, Springer Verlag 2010) wurden die am LRZ für die TUM entwickelten und betriebenen Hochschulverzeichnisdienste in der optimierten dritten Versi- on in den Regelbetrieb überführt. Trotz des reduzierten Personals war der nahtlose Übergang bei der Versorgung und Umstellung auf die neu konzipierte und vollständig vom neuen Campus-Management- System TUMonline gespeiste Directorystruktur für die Vielzahl angebundener Systeme zu bewerkstelli- gen.

Jahresbericht 2010 des Leibniz-Rechenzentrums 15

1.3.3.1 Weiterentwicklung von Datenmodell und Konnektoren Entgegen der ursprünglichen Planung musste das System der TUM-Directorys kontinuierlich weiterentwickelt werden, um die große Anforderungspalette auf Seiten der Datenabnehmer nach und nach abzude- cken. Das Datenmodell für die Speicherung von Identitäten und Autorisierungsgruppen, aber auch von Lookup-Tabellen für Studiengänge, Studienabschlüsse und Einrichtungen, musste in einigen Details erneut angepasst werden. Dies lag in neuen Erkenntnissen über die tatsächlichen von TUMonline provisionierten Werte begründet. Allerdings konnte eine abschließende Klärung der wichtigsten autorisierungsre- levanten Dateninhalte leider noch nicht erreicht werden, so dass hier auch zukünftig noch Änderungen notwendig werden. Im Einzelnen wurden folgende Anpassungen und Weiterentwicklungen an der Verzeichnisstruktur vorgenommen: • Nach eingehender Abstimmung mit der TUM konnte eine Schnittstelle und Schemastruktur zur Erweiterung der Verzeichnisdienste um Gruppen und Funktionsobjekte (speziell Shared Mailbo- xen für Exchange) festgelegt werden. • Mit den neuen Objektklassen im Schema wurde auch eine Anpassung der Konnektoren zu den Satellitenverzeichnissen und zu den abnehmenden Systemen erforderlich. • Die automatische Dateneinspeisung in das MWN-weite Microsoft Active Directory (MWN-ADS) musste für diese neuen Objekte, die u.a. auch in der dort angeschlossenen Zielplattform Exchange nötig sind, erweitert werden. Seit 2009 erfolgt diese Provisionierung mit dem Novell Scripting Driver und nachgelagerter Power-Shell-Skripte, deren Programmierung durch die LRZ-PC- Gruppe und in enger Abstimmung mit dem LRZ-Mail-Team erfolgt. • Bei dem ebenfalls aus TUMonline provisionierten Orgbaum konnte das Problem gelöst werden, wie ein dauerhaft eindeutiger Name mit dem Wunsch nach Umbenennung von Einrichtungen vereinbar ist: Für das Naming-Attribut einer Einrichtung wird deshalb die von TUMonline er- zeugte OrgUniqueId verwendet, so dass der Langname und auch das Kürzel ohne technische Sei- teneffekte fast beliebig geändert werden dürfen. Im Sommer 2010 wurde ein Audit der TUM-Directorys durch eine externe Beraterfirma durchgeführt. Es bescheinigte insgesamt eine hohe Kompetenz und Praxistauglichkeit bei Design, Implementierung und Betrieb der TUM-Directorys. Vorschläge für Verbesserungen betrafen einerseits die LDAP- Anbindungsmöglichkeiten für Linux/Unix-Systeme, andererseits Details wie eine Passwort-Policy, die sich nach Abstimmung mit dem Directory-Team jetzt überwiegend an den vom Bundesamt für Sicherheit in der Informationstechnik (BSI) empfohlenen Vorgaben orientiert. Für Vorbereitungen und Tests zum Aufbau eines zukünftigen zentralen Syslog-Servers am LRZ wurden die TUM-Verzeichnisse entsprechend konfiguriert, um die nötigen Log-Daten der LDAP-Server wie auch der IDM-Konnektoren verfügbar zu machen. Das Directory-Team war am LRZ-internen Workshop zur Evaluation des Syslog-Frontends Splunk ebenfalls beteiligt. Schließlich sei noch auf den Betrieb des Shibboleth Identity Providers für die TUM (TUM-IdP) hingewiesen, für den aufwändigere Anpassungen wegen Moodle- und Typo3-Hosting und besonders für Wiki-Spaces in enger Abstimmung mit dem TUM IT-Service-Zentrum (ITSZ) erfolgte, siehe dazu auch Abschnitt 1.3.4.3.

1.3.3.2 Angebundene Systeme Viele Einrichtungen können zur Authentifizierung ihrer Benutzer an lokalen Rechnern und Diensten direkt den zentralen Authentifizierungsserver nutzen. So konnten im Laufe des Jahres 2010 wieder viele neue Kunden für diesen Authentifizierungsdienst gewonnen werden. Zu den neuen Kunden zählen Lehrstühle und Einrichtungen aus allen TUM-Fakultäten, insbesondere auch Informatik, Mathematik, Medizin, Sport, Wirtschaftswissenschaften sowie Bau- und Vermessungswesen. Zunehmend mehr Betreiber von IT-Diensten an der TUM, von Webservern über CIP-Pools bis hin zu komplexen Content-Management-Systemen, haben die Vorteile von TUM-weit einheitlichen Kennungen erkannt und ihre Systeme an die zentralen Authentifizierungsserver angeschlossen. Trotz der umfangreichen Entwicklungs- und Beratungstätigkeit und entsprechend wenig Zeit für Systemadministration konnte dank der redundant ausgelegten Architektur und des Kundenzugangs über Service Load Balancer ein äußerst stabiler Betrieb der Verzeichnisdienste gewährleistet werden.

16 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Schließlich wurde auch rechtzeitig die Verfahrensbeschreibung für die Speicherung der Daten in den einzelnen Verzeichnisdiensten und die Weitergabe an nachgelagerte Systeme für die ermittelten Datenflüsse und das aktuelle Architekturkonzept angepasst und vom Datenschutzbeauftragten der TUM für den Endausbau der Verzeichnisdienste genehmigt.

1.3.3.3 Ausblick Auf Wunsch der TUM ist die Zuständigkeit und Verantwortung für den Dienstbetrieb der TUM- Verzeichnisdienste seit 1.1.2011 an das TUM IT-Service-Zentrum übergegangen. Die Servermaschinen mit Betriebssystem und Load-Balancer-Anbindung stellt nach wie vor das LRZ. Die tatsächliche Übergabe wird jedoch 2011 schrittweise erfolgen müssen; ein Betriebs- und Entwickler- team auf TUM-Seite, das die Aufgaben der bisherigen, am LRZ tätigen Mitarbeiter übernimmt, konnte nicht rechtzeitig aufgebaut werden. Die neuen TUM-Mitarbeiter müssen die einzelnen Bereiche der Di- rectory- und Systemadministration nun ohne längere Einarbeitungsphase primär in Grundzügen verstehen, um die Kontinuität des Betriebs gewährleisten zu können. Zu ihren Aufgaben wird mittelfristig auch die Fortführung der neuesten Entwicklungen bei Gruppen und Funktionsobjekten, später ggf. auch bei weiteren Dienstberechtigungen gehören, also durchaus Major Changes zusätzlich zum gewöhnlichen Tagesgeschäft des Dienstbetriebs.

1.3.4 AAI-Föderationen: Shibboleth Identity Provider Über die Rechenzentrums- und Hochschulgrenzen hinaus kommt dem föderierten Identity Management (FIM) auf Basis der Software Shibboleth steigende Bedeutung zu. Das LRZ betreibt seit 2008 im Rahmen der Authentifizierungs- und Autorisierungsinfrastruktur des DFN- Vereins (DFN-AAI) auf Basis der Software Shibboleth (https://www.aai.dfn.de/der-dienst/foederation) die Identity-Provider-Dienste (IdP) für die TUM, die LMU und das LRZ selbst. Die Shibboleth- Infrastruktur erlaubt die universelle Nutzung einer Vielzahl von Webdiensten und Webanwendungen lokaler und externer Anbieter mit der lokalen TUM-, CampusLMU- bzw. LRZ-Kennung und bietet darüber hinaus die Möglichkeit des Single Sign-On.

1.3.4.1 Betrieb und Administration der Identity Provider Mit dem Update auf die Shibboleth-IdP-Version 2.1.5 auf allen Servern kurz nach Freigabe wurde die aktuellste und sicherste Version installiert. Die Verfügbarkeit der Identity-Provider wird durch entsprechende Konfigurationserweiterungen für Nagios laufend überwacht, um einen stabilen, unterbrechungsfreien und performanten Betrieb zu gewährleisten. Der Ausbau der IdP-Server zu jeweils einem IdP-Cluster war noch nicht notwendig. Die bestehenden IdP- Server erwiesen sich als erstaunlich leistungsfähig, trotz z.B. Bestrebungen der TUM, Shibboleth auch für die Authentifizierung an TUM-lokalen Anwendungen einzusetzen. Da sich immer wieder spezielle Anforderung einzelner Service-Provider bezüglich Attribut-Ermittlung und -Filterung ergeben, ist für Entwicklung und Versuche ein neuer IdP-Testserver aufgesetzt worden, um den Produktionsbetrieb nicht zu stören.

1.3.4.2 DFN-AAI Die Zahl der deutschlandweit verfügbaren Webdienste in der DFN-AAI-Föderation wächst kontinuierlich, sowohl bei Hochschul- und Forschungseinrichtungen als auch bei kommerziellen Angeboten von Verlagen und Software-Anbietern. Bei der technischen Koordination der Single-Sign-on-Authentifizie- rung mit Shibboleth war die Beratung und Unterstützung für Bibliotheken und andere Dienstbetreiber an den Hochschulen durch das LRZ ein gefragter, aber ohne weiteres Personal nur unzureichend leistbarer Service. In einer eigenen Föderation bietet der DFN einen Short Lived Credential Services (SLCS, https://slcs.pca.dfn.de/gridshib-ca) für Grid-Dienste an, der seit 2009 bereits den LRZ-Benutzern zur Verfügung stand. In diese Föderation konnten Anfang 2010 nach den vertraglichen Vorbereitungen auch die Identity-Provider für TUM und LMU aufgenommen werden, wodurch nun ein wesentlich größerer Personenkreis einen unkomplizierten Zugang zu der sehr sicheren Authentifizierungsvariante über persönliche Zertifikate hat.

Jahresbericht 2010 des Leibniz-Rechenzentrums 17

1.3.4.3 Universitätslokale Angebote Die Shibboleth-Technologie und damit die am LRZ gehosteten Identity-Provider-Server für TUM und LMU kommen verstärkt für universitätsinterne Webdienste zum Einsatz, z.B. für das TUM-Wiki, für zentrale Anmeldeverfahren oder für Lehrstuhl-Informationssysteme. Eine wesentliche Triebfeder ist die höhere Sicherheit (Passwörter gelangen nicht zum Service-Provider) und Vertraulichkeit (Benutzer geben ihre Daten in jedem Einzelfall selbst frei), die die Shibboleth-Technologie gegenüber herkömmlicher LDAP-Authentifizierung bietet. Für die lokalen Service Provider waren jedoch teils dedizierte Konfigurationen zur Datenbereitstellung und -freigabe nötig, die über das übliche Maß in der DFN-AAI hinausgingen. Zum einen erhalten die ebenfalls am LRZ für TUM und LMU gehosteten E-Learning-System-Instanzen (Moodle) und Content- Management-Angebote (Typo3) jeweils einen über den Default-Umfang hinaus gehenden Attributsatz vom IdP. Zum anderen wurde in einem Pilotprojekt die Konstruktion dynamischer synthetischer Attribute für das TUM-Wiki (ein spezieller Username aus Vorname, Nachname und TUM-Kennung oder E-Mail- Adresse) erprobt und produktiv geführt. Weiterhin eignet sich die Shibboleth-Authentifizierung für Dienste, die sowohl TUM- als auch LMU- Benutzern offen stehen sollen (z. B. E-Learning-Angebote für gemeinsame Studiengänge), da vorab kein aufwändiger Austausch von Benutzerdaten erforderlich ist. In der IdP-Konfiguration waren diese Attri- butfreigaben wechselseitig für die jeweils andere Hochschule jedoch zu berücksichtigen und geeignet zu konfigurieren.

1.3.4.4 Virtuelle Hochschule Bayern (vhb) Nach der schon im Vorjahr möglichen Online-Registrierung bei der vhb mit Shibboleth-Authentifizierung ist die Anmeldung zu vhb-Kursen nun ebenfalls für alle Studenten von in der DFN-AAI organisierten Hochschulen produktiv geführt. Für den dritten Baustein, die Shibboleth-Authentifizierung für den Kurszutritt selbst, zeichnet sich nun organisatorisch wie technisch ein höherer Koordinations- und Implementierungsaufwand ab. So musste ein Konzept gefunden werden, das sowohl die Belange der vhb umsetzt (zuverlässige Nachverfolgbarkeit der Kursbuchung und -nutzung) als auch den nahtlosen Parallelbetrieb für alle teilnehmenden Hochschu- len beim Übergang vom bisherigen proprietären auf das neue standardbasierte Autorisierungsverfahren berücksichtigt. Nach intensiven Tests am LRZ hat sich aufgrund von Einschränkungen der Shibboleth- Architektur herauskristallisiert, dass eine Anbindung eines zentralen vhb-LDAP-Servers an alle Hoch- schul-IdPs nicht in Frage kommt – zu groß wären Verfügbarkeits- wie auch Datenschutzprobleme. Viel- mehr ist die Provisionierung der vhb-Kursbelegungsdaten direkt in die IDM-Systeme der Hochschulen unumgänglich (s. Abbildung 3) und befindet sich bereits in der Testphase. Unterstützt wird diese maßgeblich vom LRZ und der vhb gestaltete Entwicklung durch den bayerischen Arbeitskreis „Metadirectory und AAI“ und die Begleitung durch das Bayerische Staatsministerium für Wissenschaft, Forschung und Kunst. Schließlich musste noch in einem anderen Bereich im vhb-Umfeld eine Sonderlösung gefunden werden, und zwar für vhb-Kurse auf Moodle-Instanzen der LMU, zu denen der Zugang schon jetzt nur noch über Shibboleth möglich ist. Für Studenten, deren Heimathochschulen noch keinen Shibboleth-IdP betreiben, wurden Sonderkennungen im LMU-Zweig des Import-Export-Satelliten von LRZ-SIM angelegt.

1.3.4.5 Ausblick Ein arbeitsintensiver Bereich zeichnet sich bei der Implementierung und Koordination für den Shibbo- leth-Zugang zu vhb-Kursen ab. Das gefundene Konzept der Kursbelegungsdaten-Übernahme in die einzelnen IDM-Systeme der Hochschulen muss durch Beispielimplementierungen von Webservices und Beratung durch das LRZ begleitet werden, ebenso wie die Erweiterung der IdP-Konfiguration zur Auslie- ferung und Filterung der Kursdaten an die relevanten Kurs-Service-Provider. Auf Initiative des TUM IT-Service-Zentrums wird die Planung und Etablierung von koordinierten Work- flows bei Changes am TUM-IdP als weitere Aufgabe anfallen.

18 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Abbildung 3: Kursbuchung und Kurszutritt über das vhb-Portal mit Übernahme der Kursbuchungsdaten in die lokale Identity-Management-Datenbasis (hier LDAP-Server, Schritt 4 oben links) Quelle: W. Hommel (LRZ), A. Hummel (vhb)

1.4 E-Mail, Web-Dienste und Datenbanken

1.4.1 E-Mail-Services

1.4.1.1 Anbindung des Mail-Forwarders an die Benutzerverwaltung LRZ-SIM Nachdem in 2009 der Mail-Forwarder aufgebaut und an die Benutzerverwaltung TUMonline angebunden wurde, um unter den Domains tum.de bzw. mytum.de Mailboxen sowohl auf dem MyTUM-Mailserver als auch auf dem Exchange-Server haben zu können, wurde in 2010 auch die Verbindung zwischen der Be- nutzerverwaltung LRZ-SIM (Secure Identity Management) und dem Forwarder aufgebaut, um eine Ver- bindung zwischen dem POP/IMAP-Server mailin.lrz.de und Exchange herzustellen. Es wurden dazu die Informationen über Weiterleitungen und Abwesenheitsnotizen, die bisher lokal am POP/IMAP-Server gehalten wurden, nach LRZ-SIM transferiert und sind dort für Dienste des Id-Portals einfach zugreifbar (z.B. Self Services für Benutzer oder Anzeigefunktionen für die LRZ-Hotline bei der Bearbeitung von Problemen). Außerdem wurde die Möglichkeit geschaffen, für jede Mailbox festzulegen, auf welchem Message Store (mailin oder Exchange) sie sich befinden soll. Diese Informationen werden dann dem Forwarder über ein dediziertes Directory zur Verfügung gestellt. Der Forwarder kann somit entscheiden, ob eine E-Mail an einen der beiden Message Stores geschickt werden soll und/oder an einen externen Mailserver. Gleichzeitig übernimmt er die Benachrichtigung eines Senders, wenn der Empfänger eine Abwesenheitsnotiz geschaltet hat.

1.4.1.2 Anbindung von Exchange an das zentrale Identity Management des LRZ Mit der Anbindung des Mail-Forwarders an LRZ-SIM war eine der Voraussetzungen erfüllt, um Exchan- ge für weitere Nutzer im MWN, insbesondere für die Bayerische Akademie der Wissenschaften und die LMU München, bereitstellen zu können. Dazu musste aber zusätzlich auch Exchange an LRZ-SIM angebunden werden. Auch hier waren wiederum umfangreiche Arbeiten notwendig, um die Daten zwischen

Jahresbericht 2010 des Leibniz-Rechenzentrums 19

LRZ-SIM und dem Active Directory zu synchronisieren und Mailboxen auf Exchange automatisch einzu- richten oder zu löschen. Erste Pilotnutzer waren die Verwaltung der BAdW und die Tierärztliche Fakultät der LMU, deren Lehrstühle ab Juni sukzessive vom bisherigen Mailsystem mailin auf Exchange umgezogen wurden.

1.4.1.3 Aufbau einer Exchange 2010 Umgebung Parallel zu den Umzügen auf Exchange wurde ab Mai damit begonnen, eine Exchange 2010 Umgebung aufzubauen und die Migration von der bisherigen Version (Exchange 2007) vorzubereiten. Während die alte Umgebung nur für bis zu maximal 5.000 Nutzer ausgelegt war und so langsam an ihre Grenzen stieß, wurde die neue für bis zu 20.000 Nutzer konzipiert und komplett auf virtuellen Maschinen realisiert. Die Migration fand wie geplant Ende Oktober statt und verlief ohne größere Schwierigkeiten. Mit Exchange 2010 steht nun auch Benutzern, die nicht die Microsoft-Anwendungen Outlook bzw. Internet Explorer verwenden, die vollständige Funktionalität zur Verfügung, z.B. bei Verwendung von Firefox und der Web-Anwendung OWA (Outlook Web App).

1.4.1.4 Aufbau eines neuen Mailinglisten-Servers Ein weiteres wichtiges Projekt war der Aufbau eines neuen Mailinglisten-Servers auf Basis des Produkts Mailman. Damit wurde der in die Jahre gekommene Majordomo-Server abgelöst. Mailman bietet gegen- über Majordomo hauptsächlich den Vorteil, dass sowohl für Listen-Administratoren als auch für Nutzer der Listen eine Web-Oberfläche zur Verfügung steht, über die die gewünschten Einstellungen bequem vorgenommen werden können. Der Umzug auf den neuen Server wurde auch dazu genutzt, unter den bis dato existierenden Listen gründlich aufzuräumen: ca. 300 Listen, die schon lange nicht mehr benutzt wurden, wurden gelöscht. Zur automatischen Migration der Mailinglisten wurde eine Reihe von Pro- grammen entwickelt. Trotzdem waren wegen der Komplexität der Migration und der verschiedenartigen Modelle der Listenverwaltung in Majordomo und Mailman zahlreiche manuelle Nacharbeiten notwendig.

1.4.1.5 Massenmail-System für Hochschulstart Aus dem Projekt Hochschulstart kam die Anforderung, an einem Tag alle Studenten, die sich um einen Studienplatz beworben haben, über das Ergebnis per Mail zu informieren. Dabei wird davon ausgegangen, dass das dafür notwendige Massenmailsystem in der Lage ist, 400.000 E-Mails innerhalb von 24 Stunden zu versenden. Dies war über die vorhandene Infrastruktur nicht zu erreichen, so dass ein separa- tes Massenmailsystem auf Basis von zwei virtuellen Mailservern aufgebaut wurde. Alle E-Mails, die durch das Massenmailsystem laufen, werden mit einer DKIM-Signatur versehen, damit die Zielsysteme die Integrität des Mailheaders, insbesondere die Absendemailadresse überprüfen können. Bei manchen ISPs ist dies Voraussetzung, damit sie Massenmails in diesem Umfang akzeptieren. Die aufgebauten Sys- teme wurden intensiven Lasttests unterworfen, um die geforderte Performance sicherstellen zu können. Um Erfahrungen im Produktionsbetrieb des Systems zu erhalten, wurde der neu aufgebaute Mailinglisten- Server an das Massenmailsystem angebunden. In Zukunft soll das System auch für den Massenversand von E-Mails von Nutzern der ans MWN angeschlossenen Organisationen genutzt werden. Diese Kunden werden auf Antrag autorisiert, dieses System zu nutzen.

1.4.1.6 Statistiken

1.4.1.6.1 Spam- und Virenabwehr Das Gros der Spam- und Viren-Mails 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 Viren-Mails ausgefiltert (und die Empfänger darüber informiert) und die verbleibenden E-Mails markiert, ob es sich vermutlich um Spam-Mails handelt oder nicht. Diese Markierung kann dann dazu verwendet werden, die betreffenden E-Mails durch Konfiguration entsprechender Regeln im eigenen Mailprogramm auszufiltern. In der folgenden Graphik ist die Entwicklung von ausgefilterten Viren-Mails, markierten Spam-Mails und regulären erwünschten E-Mails (Ham-Mails) für die Jahre 2006 bis 2010 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, ist der Anteil der Ham-Mails seit Jahren relativ konstant. Der

20 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Anteil an Viren-Mails ist seit einiger Zeit so klein, dass man ihn in der Graphik nicht mehr erkennen kann. Die Werte liegen bei ca. 88 erkannten Viren pro Tag (Vorjahr: 80).

7000000

6000000

5000000

4000000 Ham

3000000 Spam Viren 2000000

1000000

0 Jan Apr Jul Okt Jan Apr Jul Okt Jan Apr Jul Okt Jan Apr Jul Okt Jan Apr Jul Okt

Abbildung 4: Monatliches Ham-, Spam- und Virenaufkommens in den Jahren 2006 bis 2010

1.4.1.6.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 164 Mailserver im MWN mit insgesamt 426 verschiedenen Maildomains in Anspruch.

Mailserver Einrichtung Domains im MWN

Ludwig-Maximilians-Universität München 49 107 Technische Universität München 100 220 andere Hochschulen und hochschulnahe Einrichtungen 28 117

Gesamt 177 444

Tabelle 9: Nutzung des E-Mail-Relaydienstes

1.4.1.6.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 eine virtuelle Maildomain eingerichtet, in der sich der Name der betreffenden Einrichtung widerspiegelt (z.B. jura.uni-muenchen.de) und Angehö- rige dieser Einrichtungen erhalten entsprechende Mailadressen. Die zu den virtuellen Domains gehören- den Mailboxen können sich sowohl auf dem POP/IMAP-Server mailin.lrz.de, als auch auf dem vom LRZ betriebenen Exchange-Server befinden. Die Entscheidung, an welchen Server eine E-Mail auszuliefern ist, übernimmt der sogenannte Forwarder, der sich die notwendige Information dafür aus der jeweiligen Benutzerverwaltung holt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 21

Seit Ende des Jahres 2010 unterstützt TUMonline organisationsspezifische Maildomains, d.h. neben den Mailadressen mit den Domains mytum.de und tum.de können Administratoren einer TUM- Organisationseinheit, z.B. ein Lehrstuhl oder auch eine ganze Fakultät, weitere Maildomains für ihre Nutzer konfigurieren. Seitdem dies möglich ist, werden neue TUM-Maildomains nur noch in TUMonline angelegt. Alte virtuelle Maildomains auf den POP/IMAP-Servern des LRZ werden sukzessive dorthin migriert. Die zugehörigen Mailboxen liegen dann entweder auf dem MyTUM-Mailserver oder auf dem Teil des Exchange-Servers, der zu TUMonline gehört. Auch hier sorgt der Forwarder dafür, dass eine E- Mail auf dem richtigen Mailserver landet. Aus Sicht des LRZ handelt es sich beim TUM-Mailserver um einen einzigen Mailserver mit beliebig vielen Aliasdomains. Daher die „1“ in der Spalte „virtuelle Mailserver“ in der untigen Tabelle. Ende 2010 waren am LRZ 227 (Vorjahr: 228) virtuelle Mailserver eingerichtet. Eine Aufteilung auf die Hauptnutzer ist der folgenden Tabelle zu entnehmen:

virtuelle Einrichtung Domains Mailserver Ludwig-Maximilians-Universität München 93 137 Technische Universität München (LRZ-SIM) 56 113 Technische Universität München (TUMonline) 1 24 Bayer. Akademie der Wissenschaften (inklusive LRZ) 42 75 andere Hochschulen und hochschulnahe Einrichtungen 35 48 Gesamt 227 397

Tabelle 10: Betrieb virtueller Mailserver

1.4.1.6.4 Nutzung der Message-Store-Server

1.4.1.6.4.1 Nutung der POP/IMAP-Server Ende 2010 gab es 119.489 Mailboxen (Vorjahr: 111.764) auf einem der fünf POP/IMAP-Server des LRZ. Nachfolgend 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.187 Technische Universität München 7.388 Bayer. Akademie der Wissenschaften (inklusive LRZ) 1.066 Hochschule München 256 andere bayerische Hochschulen 205 andere wissenschaftliche Einrichtungen 2.255 19.357 … die Fakultät Physik der Technischen Universität München 2.982 … das myTUM-Portal der Technischen Universität München 43.719 … Studenten der Ludwig-Maximilians-Universität München (CampusLMU) 51.903 … Studenten anderer Münchner Hochschulen 1.528

Gesamt 119.489

Tabelle 11: Nutzung der POP/IMAP-Messagestores

1.4.1.6.4.2 Nutzung des Exchange-Dienstes

22 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Im Jahr 2010 wurde der Benutzerbetrieb für den Exchange-Dienst auf die Ludwig-Maximilians- Universität ausgeweitet (zunächst pilotmäßig für die Fakultät Tiermedizin). Ende 2010 gab es auf dem Exchange-Cluster 5.012 Mailboxen (Vorjahr: 1.634), die sich wie folgt verteilten:

Exchange- Einrichtung Mailboxen Ludwig-Maximilians-Universität München 278 Technische Universität München 4.561 Bayerische Akademie der Wissenschaften 43 Leibniz-Rechenzentrum 130 Gesamt 5.012

Tabelle 12: Nutzung des Exchange-Dienstes

1.4.1.6.5 Weiterleitungs-Service Der oben bereits erwähnte Forwarder, der für die Verteilung von E-Mails an den richtigen Message Store 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 uni-muenchen.de bzw. lmu.de, bei der TUM um die Domain alumni.tum.de.

Einrichtung Weiterleitungen Ludwig-Maximilians-Universität München 15.376 Technische Universität München 3.989 Gesamt 19.365

Tabelle 13: Nutzung des Weiterleitungsdienstes für Maildomains

1.4.1.6.6 Nutzung von E-Mail-Verteilerlisten Wie weiter oben bereits erwähnt, wurde der Mailinglisten-Dienst des LRZ im Dezember 2010 auf das Produkt Mailman umgestellt. Diese Umstellung wurde auch zum Anlass genommen, gründlich aufzuräu- men: Insgesamt wurden 304 Listen, die schon lange nicht mehr benutzt wurden, gelöscht. Ende 2010 gab es 453 E-Mail-Verteilerlisten (Vorjahr: 661), die sich wie folgt verteilten: E-Mail- Einrichtung Verteilerlisten Ludwig-Maximilians-Universität München 112 Technische Universität München 159 Bayer. Akademie der Wissenschaften (inklusive LRZ) 145 andere Hochschulen und hochschulnahe Einrichtungen 37

Gesamt 453

Tabelle 14: Nutzung von E-Mail-Verteilerlisten

1.4.2 Webdienste Schwerpunkt beim Webhosting war 2010 der Ausbau des E-Learning für beide Universitäten, die jeweils nach relativ kurzer Pilotphase in den Produktionsbetrieb übergegangen sind, die TUM hochschulweit, die LMU mit einigen Fakultäten. Vor allem für diese Anwendungen wurde Shibboleth als neuer Dienst eingerichtet.

Jahresbericht 2010 des Leibniz-Rechenzentrums 23

Außerdem wurden die schon bestehenden Content-Management-Systeme Fiona für LRZ und BAdW sowie Typo3 für die TUM weiter ausgebaut.

1.4.2.1 E-Learning Im Bereich der Lehre an den Hochschulen ist ein klarer Trend zur verstärkten Nutzung von E-Learning- Systemen zu erkennen. Dadurch erhöhte sich auch die Nachfrage nach geeigneten Webumgebungen zur Realisierung deutlich. Somit wurden die im Vorjahr begonnenen Pilot-Projekte in diesem Bereich zu produktiven Lernumgebungen ausgebaut.

1.4.2.1.1 Moodle TUM Die umfangreichste Installation wurde für die TUM umgesetzt, die sich zum TUM-weiten Einsatz von Moodle entschieden hat. Betrieben wird die Lernplattform am LRZ in einer eigens dafür eingerichteten Webumgebung, bestehend u.a. aus dedizierten Webservern, Dateisystemen und Datenbanken. Dabei konnten die bereits bestehenden Konzepte für die Einrichtung von Webservern weitgehend auf das neue System übertragen werden, so dass es sich trotz Eigenständigkeit gut integriert. Der technische Betrieb wird vom LRZ in enger Absprache mit den Zuständigen an der TUM (ITSZ Medienzentrum) erbracht. Die Betreuung auf Applikations-Ebene, insbesondere die direkte Unterstützung der Moodle-Nutzer, liegt bei der TUM. Zum TUM-Moodle-System gehören mehrere Komponenten: Die zentrale Lernplattform selbst sowie ein Staging-System, das sowohl für Tests und Entwicklung, als auch für Support und Schu- lung verwendet wird.

1.4.2.1.2 Moodle LMU Bei der LMU erfolgt keine Zentralisierung auf eine gemeinsame Moodle-Umgebung, sondern es werden nach und nach einzelne Moodle-Instanzen nach den aktuellen Bedürfnissen der Fakultäten und Lehrstühle eingerichtet. Um eine allzu große Vielfalt zu verhindern, werden die Einrichtung und die Grundkonzepte der LMU-Moodle-Instanzen über den Leiter des Bereichs „Virtuelle Hochschule“ an der LMU koordiniert. Derzeit sind sechs Moodle-Instanzen für die LMU in Betrieb, die etwa zur Hälfte bereits produktiv eingesetzt werden.

1.4.2.2 Neues Dienst-Angebot im Webhosting: Shibboleth Die Nutzung der E-Learning-Systeme ist nur nach einem erfolgreichen Login durch nutzungsberechtigte Personen möglich. Gerade im Bereich E-Learning ist dieser Nutzer-Kreis jedoch oft nicht mehr auf die Hochschule beschränkt, an der ein Online-Kurs angeboten wird. Insbesondere über die VHB (Virtuelle Hochschule Bayern) werden zahlreiche Kursteilnehmer bayernweit auf Online-Kurse verteilt. Um die Verwaltung dieser Gast-Hörer auf technischer Ebene im E-Learning-System zu vereinfachen, wird sowohl auf den TUM- als auch den LMU-Moodle-Instanzen Shibboleth eingesetzt: • Shibboleth ermöglicht Nutzern, die nicht in die lokalen Verwaltungsstrukturen eingebunden sind, sich dennoch als berechtigte Nutzer in einer Moodle-Instanz anzumelden. Der Moodle-Nutzer wird in einem Shibboleth-fähigen Moodle für den Login-Prozess zu seinem eigenen „Herkunfts- ort“, seinem sogenannten Identity-Provider geschickt, kann sich dort mit seinen gewohnten Zu- gangsdaten ausweisen und wird dann wieder zurück zum Moodle geschickt. Dabei werden die notwendigen Eckdaten wie Name, Vorname, Loginname, Email-Adresse usw. automatisch an das Moodle übermittelt und in die lokale Moodle-Verwaltung aufgenommen. • Shibboleth ist außerdem ein Single-Sign-On-Verfahren. Das heißt, dass man nach einem Login beispielsweise in Moodle automatisch auch in einer anderen Applikation (z.B. einem Wiki, einem Hochschulportal. usw.) angemeldet ist, die ebenfalls Shibboleth-fähig ist. Auch für die Nutzer des TUM-Typo3-Systems (siehe weiter unten) soll Shibboleth zum Einsatz kommen. Derzeit wird an der TUM unter Mithilfe des LRZ ein entsprechendes Typo3-Modul entwickelt. Hier wür- de insbesondere auch die Single-Sign-On-Komponente zum Tragen kommen: Dozenten und andere Con- tent-Provider der TUM wären automatisch an der Lern-Plattform und auf den Webseiten, die sie verwalten, angemeldet, um Kurse zu ändern und Webseiten-Inhalte zu erstellen und anzupassen. Je mehr Shib- boleth-fähige Applikationen hinzukommen, umso interessanter wird dieser Aspekt natürlich. Um Applikationen Shibboleth-fähig zu machen, müssen eine Reihe von technischen Voraussetzungen erfüllt sein. Insbesondere muss applikationsseitig ein sogenannter Service-Provider betrieben werden, der zwischen der Applikation und dem Identity-Provider vermittelt. Der Betrieb solcher Service-Provider

24 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS) muss auf den Systemen laufen, auf denen auch die Applikationen liegen und wird daher als weitere Leis- tung im Rahmen des Webhosting erbracht. Im Fall von LMU und TUM ergibt sich außerdem die Situati- on, dass auch der Identity-Provider vom LRZ betrieben wird (siehe Bericht Identity Management), so dass hier gute Bedingungen zur Koordination zwischen beiden Komponenten herrschen. Da die Komple- xität des gesamten Shibboleth-Systems viele Absprachen erfordert, ist dies ein großer Vorteil.

1.4.2.3 Typo3 Die TUM unterstützt für die Webauftritte ihrer Fakultäten, Lehrstühle und Einrichtungen das Content- Management-System Typo3 und bietet dazu die Installation dieser Applikation und den Support auf einer vom LRZ bereitgestellten und gepflegten Webumgebung. Die Vorbereitungen und Absprachen hatten bereits im Vorjahr begonnen (wie berichtet). Das Gesamtsystem ist im Berichtsjahr mit Erfolg und in großem Umfang in Produktion gegangen. Es wurden bisher über 200 neue Webserver in dieser Umge- bung eingerichtet (siehe auch Statistik).

1.4.2.4 Performance der Webhosting-Umgebung Durch die zahlreichen neuen Webserver, die intensiven Gebrauch von Datenbanken machen – Moodle und Typo3 sind die am häufigsten eingesetzten Produkte dieser Art – haben sich neue Ansprüche an das Webhosting ergeben. Waren Zugriffe von den Webservern auf die Datenbanken früher eher die Ausnah- me, so sind sie jetzt die Regel. Dadurch werden die Netzlaufzeiten von Datenpaketen zwischen Daten- bank und Webserver relevant, während dies früher kaum eine Rolle spielte. Dies kann bei komplexen Setups zu deutlichen Leistungseinbußen im Gesamtsystem führen. Dieser Effekt erhöht sich noch dadurch, dass die meisten Zugriffe personalisiert sind – nach erfolgtem Login werden Webseiten entsprechend dem Nutzerprofil individuell angepasst ausgeliefert –, so dass die üblichen Caching-Methoden wenig bis gar nicht einsetzbar sind. Dabei ist es für das Laden einer Webseite oft von untergeordneter Bedeutung, ob viele oder nur wenige Nutzer das System nutzen, da allein zur Zusammenstellung einer einzigen Webseite hunderte von Verbindungen benötigt werden, deren Gesamtlaufzeit sich zu einer fühl- bar langen Zeit aufaddiert, je langsamer die Netzanbindung ist. Und nicht nur die Laufzeiten zur Daten- bank spielen dabei eine Rolle, sondern auch die Laufzeiten zu den Webdaten, die auf dem Dateisystem abgelegt sind. Die auf diesem Gebiet im Berichtsjahr gewonnenen Erkenntnisse müssen daher verwendet werden, um die Webumgebung den veränderten Bedingungen anzupassen und dem Nutzer weiterhin einen zeitgemäß ausreichend schnellen Zugang zu den Applikationen zu gewährleisten. Eine maschinelle Aufrüstung ist sicherlich auch notwendig, wird aber alleine nicht ausreichen. Dem Problem mit schnelleren Netzen zu begegnen ist ebenfalls keine Lösung, da die technischen Möglichkeiten hier bereits weitgehend ausge- schöpft sind. Daher müssen sowohl die Datenbanken als auch die Dateisysteme netztechnisch näher an die Webserver gebracht werden, um die Laufzeiten zu verringern. Das erfordert Änderungen im Web- hosting-Konzept, die sowohl für bereits bestehende als vor allem auch für neue Webserver-Pools berück- sichtigt und umgesetzt werden müssen. Der Zeitgewinn kann durch ein günstiges Setup durchaus einen Faktor 10 ausmachen.

1.4.2.5 Webhosting – Statistik Auf die zentralen WWW-Server am LRZ wurde im Jahr 2010 durchschnittlich ca. 51 Millionen Mal pro Monat (also etwa 19 Mal pro Sekunde) zugegriffen. Diese Zahl ist allerdings aus mehreren Gründen nur bedingt aussagekräftig. Zum einen ist eine echte Zählung der Zugriffe gar nicht möglich, da auf verschiedenen Ebenen Caching-Mechanismen eingesetzt werden (Browser, Proxy). Andererseits werden nicht Dokumente, sondern „http-Requests“ gezählt. Wenn also z. B. eine HTML-Seite drei GIF-Bilder enthält, so werden insgesamt vier Zugriffe registriert. 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. Die Zahlen für das LRZ enthalten auch die Zugriffe auf persönliche WWW-Seiten von Hochschul- angehörigen. Zusätzlich wird die Zahl der Seitenaufrufe, das ist die angeforderte Zahl der „echten“ Do- kumente, genannt. Als echte Dokumente gelten dabei Textdokumente, also keine Bilder oder CGI- Skripte. Die Zahl der Webserver hat sich gegenüber 2009 um 283 erhöht; das sind mehr als 50%; dieser Anstieg ist fast ausschließlich dem Typo3-Projekt der TUM zuzuschreiben, das eine Vielzahl kleiner Webserver

Jahresbericht 2010 des Leibniz-Rechenzentrums 25 umfasst. Der Umfang der ausgelieferten Daten stieg etwas stärker an als die Zahl der Zugriffe, nämlich um 25% auf ca. 2,3 TByte pro Monat. Seiten- Daten- Zugriffe Server aufrufe umfang in Mio. in Mio. in GByte Leibniz-Rechenzentrum 17,20 6,89 835,9 Ludwig-Maximilians-Universität München 4,69 0,65 224,2 Technische Universität München 17,52 1,76 741,6 Einrichtungen im Münchner Hochschulnetz 2,76 0,86 40,5 Einrichtungen im Münchner Wissenschaftsnetz 2,52 0,28 249,4 Bayerische Akademie der Wissenschaften 0,88 0,20 152,1 Sonstige 5,94 0,44 112,3 Gesamt 51,51 11,08 2356,1

Tabelle 15: Monatliche Zugriffe auf die WWW-Server am LRZ

Ende 2010 unterhielt das LRZ 16 virtuelle WWW-Server für eigene Zwecke. Für Hochschulen und hochschulnahe Einrichtungen wurden insgesamt 814 (Vorjahr: 531) virtuelle WWW-Server betrieben. Einrichtung Webserver 2010 Webserver 2009 Leibniz-Rechenzentrum 16 16 Ludwig-Maximilians-Universität München 114 112 Technische Universität München 541 273 Bayerische Akademie der Wissenschaften 27 27 Einrichtungen aus dem Münchner Hochschulnetz 24 26 (z. B. Hochschule für Politik) Einrichtungen aus dem Münchner Wissenschaftsnetz 29 26 (z. B. Zoologische Staatssammlung München) Andere (z. B. Bayerisches Nationalmuseum) 63 51 Gesamt 814 531 Tabelle 16: Anzahl virtueller WWW-Server

Die Unterstützung der Applikationsplattform Zope wurde weiter zurückgefahren. Zum Jahresende gab es noch insgesamt zwölf unabhängige gehostete Sites, und zwar zehn individuelle Zope-Instanzen mit individuellen Sites (meist Plone), sowie eine TUM-Zope-Instanz mit zwei elevateIT-Sites.

1.4.2.6 Content-Management für das LRZ selbst und die BAdW Das Content-Management-System Fiona der Fa. Infopark wird seit Mitte 2007 für die Verwaltung der Inhalte des Webauftritts der Bayerischen Akademie der Wissenschaften verwendet. Nachdem im April 2009 auch der Webauftritt des LRZ auf dieses System umgestellt und dabei überarbeitet wurde, folgte im September 2010 der interne Webserver. Das bestand aus zwei größeren Komplexen: • Die enthaltene Dokumentation sollte übernommen werden. Anders als beim externen Webserver ein Jahr vorher wurde nicht der gesamte Altbestand an Webseiten mitsamt seiner Gliederung übernommen. Vielmehr orientiert sich die Gliederung jetzt am für das IT-Servicemanagement neu entworfenen Dienstebaum, und es sollen nur aktuelle Texte übernommen und dabei auf ihre Richtigkeit überprüft werden. Diese Aufräumaktion in enger Zusammenarbeit mit dem Arbeits- kreis Informationsmanagement wird sich bis ins Jahr 2011 hinziehen. • Bestandteil des alten internen Webservers war auch der Publisher, also das bisherige Content- Management für Extern- wie Internserver. Das ist zwar mit der Migration des Internservers im

26 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Prinzip überflüssig geworden, einige speziellere Funktionen (E-Mail-Verteiler, LRZ- Mitteilungen) konnten aber nicht sofort ersetzt werden und werden noch bis ins Jahr 2011 in Be- trieb bleiben. Auch im Berichtsjahr lag nicht nur der Betrieb der Fiona-Software und der zugrundeliegenden Systeme, sondern auch die Unterstützung der Redakteure aus der BAdW und Anpassungen der Konfiguration an deren Wünsche beim LRZ. Hervorzuheben ist besonders die Schulung von Mitarbeitern der BAdW in der Nutzung und Konfiguration dieser Software. Mit der Schelling-Kommission wurde die pilotmäßige Mig- ration des Webauftritts einer Kommission der BAdW nach Fiona vorbereitet.

1.4.3 Datenbanken MySQL-Datenbanken sowie Oracle-Datenbanken bilden den Schwerpunkt der Datenbankdienste. Dane- ben wird Microsoft Access als Frontend verwendet und mehrmals im Jahr Kurse hierzu angeboten. Die Anzahl der Server, die MySQL-Datenbanken im Netz anbieten, wuchs auf 15 Einheiten an, so dass sich die Anzahl der darauf laufenden Instanzen auf 25 (Vorjahr 15) erhöhte. Einzelne Datenbanken wie z.B. die Patentdatenbank überschreiten zwischenzeitlich die 1 TB Datenbankgröße. Neben der CMS- Installation Fiona werden diverse Clientanwendungen für MySQL (WordPress, Moodle, Typo3, Joomla! etc.) unterstützt. Die für virtuelle Webserver der Münchener Hochschulinstitute eingerichtete Datenban- kinstanz wurde auf einen VMware-Rechner migriert. Diese Instanz umfasst 357 Schemata (Einzeldatenbanken) welche zum Datenmanagment der virtuellen Webserver benötigt werden. Hierbei handelt es sich um die MySQL Version 4.1. Seit Dezember 2010 werden allerdings Webserverdatenbanken ausschließlich mit der MySQL-Version 5 angeboten und installiert. Für die Version 5.0.51 wurden im letzten Jahr 167 Datenbanken zusätzlich angelegt. Wie bei allen anderen MySQL-Anwendungen am LRZ zuvor wird auch hier ein 7×24h-online-Betrieb durchgeführt; ausgenommen davon sind Wartungsfenster. Diese neu installierten Datenbanken dienen sowohl als Backend-Datenbanken für die Typo3-Anwendungen der TUM und LMU als auch für allgemeine Anwendungen (Drupal, Joomla! etc). Zusätzlich zu den vorhandenen Standarddatenbanken basierend auf MyISAM-Tabellen gewinnt der Ein- satz von transaktionsbasierten Tabellen in MySQL mit der zugehörigen InnoDB-Engine immer mehr an Bedeutung und wird im LRZ zunehmend standardmäßig eingesetzt. Eine Besonderheit hierbei sind die wesentlich aufwendigeren Sicherungs- und Restoreverfahren, die im MySQL-Umfeld zusätzliche Soft- ware wie InnoDB-Hotbackup bzw. ZManda benötigen. Diese Software wurde ebenfalls angeschafft, installiert und sodann in wichtigen Projekten eingesetzt. Anzuführen wären hier insbesondere die Lern- plattform Moodle der TU/ LMU sowie das Projekt Hochschulstart. Speziell die letzten genannten Projekte, die eine hohe Stabilität als auch Performance benötigen, wurden jeweils mit kommerzieller Enterprise-Software ausgestattet, wodurch ein bestmöglicher Support gewähr- leistet ist. Darüberhinaus wurden im Jahre 2010 Datenbanken für verschieden Inhouse-Awendungen MySQL- Datenbanken benötigt und installiert. Hierbei ist vor allem die aktuelle HPC Anwendung zu nennen. Für diese wurde eine neue Datenbank mit Replikation installiert. Das Projekt befindet sich derzeit im Test- stadium und wird etwa Mitte 2011 in Produktion gehen. Das Dienstangebot bei den Oracle-Datenbanken blieb weitgehend unverändert. Zwei neue Rechner für Oracle-Instanzen wurden beschafft, um ältere aus der Wartung fallende Maschinen zu ersetzen. Einige Dienste der Oracle-Instanz (z.B. das Trouble-Ticket-System des LRZ) liefen parallel unter der Anwen- dung Action Request Software (ARS) sowie dem neu beschafften System iET ITSM-Solution. Dieses Sys- tem arbeitet mit der Datenbank Microsoft SQL Server als Datenbank-Engine und löst im März 2011 das bisherige Trouble-Ticket-System ab. Am Jahresende 2010 betrieb das LRZ 25 Instanzen (Vorjahr: 15) von MySQL (2× MySQL 4.1 und 23× MySQL 5), die etwa 1,5 TB-Byte Daten (Vorjahr: 600 G-Byte) verwalten. Damit werden unter anderem 357 virtuelle Webserver (Vorjahr: 280) versorgt. Darüber hinaus finden die MySQL-Services hausintern in 34 Projekten intensiven Gebrauch. Auch die Performancedaten des HLRB II werden in einer MySQL- Datenbank verwaltet und dadurch konsolidiert im Internet angezeigt. Die MySQL-Datenbankserver verarbeiten derzeit permanent ca. 1200 Anfragen aus dem Netz pro Sekunde (Vorjahr: 1000).

Jahresbericht 2010 des Leibniz-Rechenzentrums 27

1.5 Grafik, Visualisierung, Multimedia

1.5.1 Virtual Reality (VR) Die bisherige Ausstattung des LRZ zur immersiven Visualisierung wissenschaftlicher Daten, deren Hauptbestandteil eine Zwei-Flächen-Holobench ist, genügt nicht mehr den Anforderungen der Benutzer. Eine umfangreiche Bedarfserhebung unter Lehrstuhlinhabern aus vielen Fachbereichen von LMU und TUM zeigte die Notwendigkeit, auch zukünftig eine angemessene Ausstattung zur immersiven Visuali- sierung zur Verfügung zu stellen. Insbesondere sind mittlerweile Projekte in Planung, die nur in einer echten Virtual-Reality-Umgebung realisiert werden können, bei der der Benutzer von der Projektion fast vollständig umgeben wird. Ein solcher Projektionsraum (der häufig als CAVE bezeichnet wird) ist seiner Natur nach ein interaktiver Arbeitsplatz für einen oder wenige Wissenschaftler. Daneben gibt es auch noch Bedarf für großflächige stereoskopische Präsentationen vor Gruppen im Rahmen von wissenschaftlichen Veranstaltungen. Deshalb wurde in 2010 ein Forschungsgroßgeräteantrag ausgearbeitet, in dem ein Visualisierungszentrum mit einer entsprechenden Ausstattung beantragt wird: eine fünfseitige CAVE mit Projektion auf die Sei- tenflächen, Boden und Decke, sowie eine großformatige 3D-Powerwall. Im Erweiterungsbau des „Zent- rums für Supercomputing“ wurde hierfür ein entsprechender Raum vorgesehen, der die spezifischen An- forderungen der beiden komplexen Projektionsanlagen erfüllt. Insbesondere wird in diesem neuen Visua- lisierungszentrum durch die außergewöhnliche Raumhöhe eine Bodenrückprojektion der CAVE ermög- licht werden, die jeglichen störenden Schattenwurf vermeidet, den Eindruck der Immersion verbessert und eine echte Besonderheit darstellt.

1.5.2 Streamingserver Das LRZ betreibt seit 2001 einen Streamingserver. Die Nutzung dieses Servers hat in den letzten Jahren kontinuierlich zugenommen. Insgesamt liegen derzeit auf dem Streamingserver mehrere tausend Filmbei- träge mit einem kumulierten Datenvolumen von 935 GByte – annähernd eine Verdoppelung in den vergangenen 12 Monaten. Die einzelnen Filme sind meist Aufzeichnungen von Vorträgen oder Vorlesungen mit einer Länge von 80-90 Minuten, aber auch teilweise kürzere Lehrvideos, die zum Beispiel die Ausbildung in der Medizin unterstützen. Vorlesungsaufzeichnungen werden normalerweise in drei Varianten erstellt und abgelegt, als hochaufgelöstes Video mit einer Bandbreite von ca. 1 Mbit/s, als niedriger aufgelöstes Video mit ca. 400 Kbit/s und einer Variante, die nur aus der Tonspur besteht und nur eine Bandbreite von ca. 50 Kbit/s benötigt. Der bisherige Darwin-Streamingserver basiert auf QuickTime und für die Wiedergabe der Medieninhalte ist das QuickTime-Plugin notwendig. Es wurde wiederholt nach einer weiteren Streaming-Lösung nachgefragt, bei der für die Wiedergabe stattdessen das Flash-Plugin zum Einsatz kommt. Dazu wurde im vergangenen Jahr ein Mediaserver von Wowza Media Systems aufgebaut, der seit dem Wintersemester in Produktionsbetrieb ist.

1.6 Serveradministration und Applikationsunterstützung Der Betrieb von Serversystemen für Internetdienste erfordert eine Reihe von Arbeiten, die inhaltlich eher zum Betriebssystem oder zur systemnahen Software gehören, die aber auf das Applikationsportfolio am jeweiligen Serversystem zugeschnitten sind. Ob dabei das Serversystem eine physische Maschine ist oder aber eine virtuelle, spielt auf dieser Ebene kaum eine Rolle. Zu diesen Aufgaben gehören beispielsweise • die Auswahl des erforderlichen Betriebssystemumfangs, je nach den Voraussetzungen der geplanten Anwendungen, • die Deaktivierung von nicht benötigten Netzdiensten aus Sicherheitsgründen und weitere Sicher- heitsmaßnahmen wie Zugangsbeschränkungen und Security-Patches, • die Überwachung der Verfügbarkeit und der Funktion auf Applikationsebene, • die Messung der Systemauslastung unter Berücksichtigung der Erfordernisse der Applikationen zum Tuning und zur proaktiven Ressourcenplanung, • die Erstellung von Operateuranleitungen zur Problembehebung,

28 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

• die Unterstützung und Beratung der mit der Applikation betrauten Mitarbeiter, um eine optimale Nutzung des Systems zu erreichen sowie • die Fehlersuche an der Schnittstelle zwischen Applikation und Betriebssystem. Da diese Systemadministration sowohl mit dem eigentlichen Rechnerbetrieb (Installation und Deinstalla- tion, Installation eines Basis-Betriebssystems, Firmware, Anbindung ans Rechnernetz, hardware- und netznahe Funktionsüberwachung) als auch mit der Applikationsadministration eng verwoben ist, können diese Aufgaben im einen oder im anderen Bereich angesiedelt sein, und es ist in jedem Fall eine enge Zusammenarbeit erforderlich. Die Ansiedlung beim Rechnerbetrieb bietet sich an, wenn die Applikatio- nen von den Endbenutzern oder von den Kunden des LRZ eingebracht werden (Mitarbeiter-Arbeitsplätze, Hosting/Housing, High-Performance-Computing), wenn eine hohe Anzahl gleichartiger Systeme vorliegt oder wenn die Applikationsadministratoren dem Betrieb organisatorisch benachbart sind. Bei den Netz- diensten mit ihrem eher individuellen Applikationsprofil hat es sich bewährt, die Systemadministration organisatorisch im Umfeld der Applikationen anzusiedeln.

1.6.1 Serveradministration in BDS Der Abteilung BDS oblag Ende 2010 die Administration folgender Serversysteme: • 38 (Vorjahr 21) virtuelle Maschinen mit Linux-Betriebssystem • 33 (unverändert) physische Maschinen mit Linux-Betriebssystem • 15 (Vorjahr 20) physische Maschinen mit Solaris-Betriebssystem • 211 (Vorjahr 160) Serversysteme für die IT-Infrastruktur des Bibliotheksverbundes Bayern (De- tails siehe Kapitel 1.10; diese Systeme werden in diesem Abschnitt nicht mehr betrachtet) Diese Maschinen wirken im Umfeld der Webservices (Webserver, Content-Management, verschiedene Backendserver), der Datenbanken, der Lizenzverwaltung und weiterer Netzdienste (FTP, Groupware). Sie beherbergen auch einige Dienste der Rechnerüberwachung und -steuerung (OVO, Konsolserver, Admi- nistratorengateways) sowie des Netzmanagements und der Netzüberwachung. Bei den virtuellen Systemen liegt der Rechnerbetrieb bei der Betreibergruppe der VMWare-Systeme in der Abteilung HLS; bei den physischen Systemen werden die Maschinen von den Systemadministratoren auch betrieben. Im Jahr 2010 ist neben den oben erwähnten Daueraufgaben folgendes durchgeführt worden: • Mehrere Dienste wurden von realer Hardware unter Solaris oder Linux auf virtuelle VMWare- Maschinen verlagert oder neu auf virtuellen Maschinen eingerichtet. Das spiegelt sich auch im gewachsenen Anteil virtueller Maschinen wider, wie er aus den Zahlen oben hervorgeht. • Die MySQL-Serverlandschaft wurde stark erweitert und auch neu strukturiert. Hintergrund ist die bedeutende Ausweitung des Angebots der E-Learning-Plattform Moodle für die beiden Universi- täten und des Content-Management-Systems Typo3 für die TUM. Allein hier sind acht weitere virtuelle Maschinen hinzugekommen. • Die E-Learning-Plattform Moodle insbesondere für die TUM hat darüber hinaus den Aufbau von sieben weiteren Servermaschinen erfordert. • Das Server- und Dienstmonitoring auf Applikationsebene, insbesondere mittels Nagios, wurde wesentlich ausgebaut und um eine Visualisierung der anfallenden Daten ergänzt. • Außerdem wurden die Anforderungen der Systemadministration in abteilungsübergreifende Ar- beitskreise eingebracht (siehe Kapitel 4): • Mit dem Arbeitskreis Informationsmanagement (siehe Abschnitt 4.4) wurden die Vorschläge zur Verbesserung des LRZ-Informationsmanagements weiter konkretisiert. Insbesondere wurde der Dienstebaum, wie er künftig dem Incident-Management zugrundeliegen wird, als Grundlage der Struktur in die interne Dokumentation eingeführt. • Mit dem Arbeitskreis Continuity (siehe Abschnitt 4.3) wurden die Vorgehensweisen bei geplanten und ungeplanten Betriebsunterbrechungen weiter spezifiziert.

1.6.2 Service für das Münchner Wissenschaftsnetz Wie schon in den Vorjahren gibt es Daueraufgaben nicht nur beim Betrieb der obengenannten Server, sondern darüberhinaus als Dienst im gesamten Münchner Wissenschaftsnetz:

Jahresbericht 2010 des Leibniz-Rechenzentrums 29

• Verteilung von Software im Rahmen des Sun Campus-Vertrages, Beratung der Anwender im MWN in Bezug auf den Sun Campus-Vertrag, • Unterstützung der Anwender bei der Nutzung der LRZ Lizenzserver; speziell bei Ansys und Mat- lab ist der Unterstützungsbedarf sehr hoch, • Unterstützung bei Beschaffung, Installation und Konfiguration von Hardware und Software, • Unterstützung und Beratung von Systemadministratoren im MWN bei Problemen zu Hardware und Software („bootet nicht mehr“, „Platte defekt, was tun?“, ...) sowie • Unterstützung von Systemadministratoren im MWN bei Security-Problemen oder bei Hackervor- fällen

1.7 Desktop-Applikationsservices Die zentralen Themen gruppieren sich nach wie vor um den Aufbau und Betrieb von Infrastrukturdiens- ten im Münchner Wissenschaftsnetz. Dazu gehört der Betrieb von Windows Servern für interne und externe Kunden, die Anbindung des „Speichers für die Wissenschaft“ an Arbeitsplatzrechner unter Windows und Linux, die Nutzung eines MWN-weiten Active Directories für Arbeitsplatzrechner bei Institutionen in einem delegierten Administrationsmodell, dem Aufbau eines mandantenfähigen Soft- wareverteilungstools und der Nutzung von Sharepoint 2010 als Kollaborationsplattform. Weitere (Pilot-) Kunden aus LMU und TUM konnten für diese Dienste im Life-Cycle-Management von Arbeitsplatz-PCs gewonnen werden. Insbesondere wird auch die LRZ-eigene PC-Landschaft (Pool, Kursräume, Spezialar- beitsplätze, Mitarbeiter-PCs, Server) nach und nach in die neue Management-Infrastruktur aufgenommen und dort betrieben. Das dient nicht zuletzt der Erfahrungssammlung für das eigene Dienstportfolio.

1.7.1 Sicherheitsdienste für Desktops im MWN

1.7.1.1 Antiviren-Service Auf der Grundlage eines Landesvertrages über die Antiviren-Software der Fa. SOPHOS hat das LRZ eine Service-Infrastruktur zur automatischen Verteilung und Installation von SOPHOS-Virensignaturen für alle Nutzer im Münchner Wissenschaftsnetz eingerichtet, verbunden mit entsprechenden Beratungsleis- tungen zur Nutzung für Endbenutzer und CID-Betreibern in Bayern. In ersten Quartal 2010 wurde die Infrastruktur von der Version 7.x auf die Version 9.x gehoben. Dadurch können nun auch 64-bit Systeme unterstützt werden. Das LRZ war dabei das erste der bayrischen Uni- Rechenzentren und konnte die gewonnen Erfahrungen weitergeben. Der neue Sophos Server wird als virtuelle Instanz im LRZ-VMware-Cluster betrieben. Die Anzahl der monatlichen Zugriffe verdeutlicht Abbildung 5. Es ist zu berücksichtigen, dass PC- Clientsysteme oft mehrmals am Tag zugreifen. Als jeweils ein Client werden auch sog. Proxys gezählt, die wiederum eine Weiterverteilung der Daten an ihre PC-Clientsysteme ermöglichen. Die tatsächliche Zahl von Clients wird auf ca. 25.000 geschätzt (weiterführende Serviceinformationen siehe: http://www.lrz.de/services/security/antivirus/).

1.7.1.2 Windows Software Update Service Als weiterer Basisservice für das automatische Update von Windows-Betriebssystemen und Microsoft Applikationen wie Internet Explorer oder Office wird der „Windows Software Update Service“ (WSUS) als MWN-weiter Dienst angeboten. Der Service ist seit Längerem mit guten Erfahrungen innerhalb des LRZ in Gebrauch und kann auch von allen Endkunden im MWN über das LRZ benutzt werden. Der Dienst wurde aktiv von rund 6.500 Rechnern genutzt. Die hohe Akzeptanz des Service im Münchner Wissenschaftsnetz verdeutlicht auch Abbildung 6 (weiterführende Serviceinformationen siehe: http://www.lrz.de/services/security/mwnsus)

30 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Abbildung 5: Zugriffe auf den Antiviren-Service im November 2010

Abbildung 6: Zugriffe auf den Windows Software Update Service im Jahr 2010

1.7.2 Active Directory im Münchner Wissenschaftsnetz 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 der Fileservices auf Basis von NetApp mit CIFS notwendig. Dieses AD ist so angelegt, daß 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 er- schließen und Verbesserungen im Funktionsumfang für Anwender und Administratoren nutzen zu kön- nen. 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, Gruppen, Funktionsken- nungen oder auch Ressourcen für Exchange eingetragen und verwaltet werden. Damit es nicht zu Na- menskonflikten kommt, wurde ein verbindliches Namenskonzept für Objekte im Active Directory entwickelt. Zur Erfüllung ihrer Aufgaben wird den Teil-Administratoren ein Set an Werkzeugen über zwei

Jahresbericht 2010 des Leibniz-Rechenzentrums 31

Terminalserver auf Basis von Windows Server 2003 und 2008 zur Verfügung gestellt. Die Einrichtung dieser Organisationsstrukturen wurde in 2008 für die TU München umgesetzt und wird stetig in Abspra- che mit der TU München angepasst. Für die LMU wird die Struktur bei Bedarf angelegt. Die Benutzer- konten und zentralen Gruppen werden über die beiden Metadirectories (SIM, TUM) am LRZ gepflegt. Dabei kommen Softwarelösungen der Firma Novell zum Einsatz. Mit diesem Active Directory können alle Clients ab Windows 2000 verwaltet, Mac OS X und LinuxSys- teme integriert werden. Momentan sind aus den drei großen Mandanten TUM, LMU und BAdW rund 1850 Rechner im AD integriert. Es wurden bisher rund 232 (160) Teiladministratoren aus 181 (105) Ein- richtungen registriert und in 2010 haben sich an der Infrastruktur rund 13.000 verschiedene Nutzer angemeldet. Dabei wurden Dienste wie das Ablagesystem oder die Groupware Exchange genutzt. In 2010 fand der Upgrade der Domäne auf Windows 2008 R2 statt. Dabei wurde die Anzahl der Domä- nen Controller auf drei reduziert. Hinzu kamen zwei Read only Domain Controller (RODC) an den Au- ßenstellen in Martinsried und Weihenstephan. Die RODCs gewährleisten auch bei einem Ausfall der Netzanbindung an das LRZ eine Anmeldung an den Clients.

1.7.2.1 Provisionierung der Benutzer in das Active Directory Seit 2009 erfolgt die Provisionierung der Benutzerkonten der TU München aus den Metadirectories in das Active 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 2010 wurden die Skripte angepasst, um weitere Funktionen erweitert, die Anbindung eines weiteren Metadirectories (LRZ-SIM) realisiert und für die Versorgung eines weiteren Active Directories eduroam.mwn.de übertragen.

1.7.2.1.1 LRZ-SIM Auf der Codebasis des IntegraTUM-Treibers wurden eigene Scripte für LRZ-SIM realisiert. Die wichtigste Erweiterung war hierbei, dass nun nicht nur Benutzerobjekte, sondern auch andere Objekte verarbeitet werden können. Dies war notwendig, da die Abbildung der Projekte in der Nutzerverwaltung von LRZ-SIM AD-seitig in Universal-Gruppen erfolgt. Außerdem mussten in vielen Bereichen die Funktionen von IntegraTUM angepasst werden, da die Daten in den beiden verschiedenen Directories einem unterschiedlichen Prozessablauf unterliegen. Bestes Bei- spiel ist hier das Löschen von Objekten, welches in LRZ-SIM zu einer direkten Löschung führt. Im In- tegraTUM-Treiber führt hingegen eine Änderung des Dienststatus zu einer Löschung im AD.

1.7.2.1.2 IntegraTUM Der Treiber wurde überarbeitet und die Funktionalität, dass beliebig verschiedene Objekte im Treiber verwendet werden können, aus dem LRZ-SIM Treiber übernommen. Dies geschah mit der Zielsetzung, im IntegraTUM-Treiber Objekte wie Gruppen oder Funktionsobjekte zu verarbeiten. Damit wurde die Voraussetzung geschaffen, um Exchange-relevante Objekte wie Verteiler und Shared Mailboxen über die in 2011 geplanten Erweiterungen in TUMOnline zu provisionieren.

1.7.2.1.3 Eduroam Für Eduroam konnte der LRZ-SIM Treiber im Wesentlichen übernommen werden, da eduroam hier auch über das LRZ-SIM-Metadir provisioniert wurde. Der Umfang der verarbeiteten Attribute wurde auf das Nötigste beschränkt, wodurch der Code deutlich gekürzt werden konnte. In allen Treibern hat die erweiterte Fehlerbehandlung Einzug gehalten. Dies beinhaltet u.a. die Einfüh- rung von Fehlercodes, Vereinheitlichung der Fehlermeldungen und eine Überarbeitung des Loggings. Ein wichtiges neues Feature ist, dass nun der Treiber abgebrochene Ereignisse erkennt und diese dann als Fehler ausgibt. Fehlermeldungen werden in der Windows Ereignisanzeige protokolliert. Eine direkte Be- nachrichtigung der Verantwortlichen erfolgt per E-Mail. bzw. wird über einen lokalen Agenten an den zentralen SCOM (System Center Operation Manager) weitergeleitet. Mit Hilfe eines Daily-Reports werden alle Ereignisse des Tages mit Statusangabe zusammengefasst und in einem eigenen Logfile gespeichert.

32 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

1.7.2.2 Active Directory Lightweight Directory Services - ADLDS Mit ADLDS bietet Microsoft die Möglichkeit, eine veränderbare Kopie eines Active Directories auf einem eigenständigen Server zu betreiben. Dabei kann nicht nur der Datenbestand selbst verändert werden, sondern auch das Schema beliebig erweitert werden. Änderungen werden aber nicht in das Quell- Verzeichnis zurück geschrieben. Diese Technologie wurde für die Telefonanlage am LRZ verwendet. Die VoIP-Telefone am LRZ lesen über einen LDAP-Zugriff aus dem ADLDS passend zur Telefonnummer den Vor- und Nachnamen aus und zeigen diesen im Display der Telefone an. Dabei wurde das Format der Telefonnummern aus dem Quell AD für die Telefonanlage angepasst. Eine zweite ADLDS-Instanz wurde für die Anbindung der Druckabrechnungssoftware Pcounter am ITW der TUM aufgebaut, kam aber dann nicht mehr zum Einsatz.

1.7.2.3 Network Policy Server - NPS In 2010 wurden die Möglichkeiten des NPS von Microsoft näher untersucht. Der NPS bietet die Mög- lichkeit einer Authentifizierung oder Autorisierung von Geräten oder Nutzern gegenüber einem Netzwerk Server, wie z.B. für IEEE 802.1x. In zwei Bereichen kam die Technik in 2010 unabhängig voneinander zum Einsatz.

1.7.2.3.1 Eduroam Der Dienst Eduroam ermöglicht Studenten und Hochschulmitarbeitern den Zugang zum Internet über WLAN über eine 802.1x Authentifizierung. Dabei werden Benutzerdaten, die auf der Client-Seite einge- geben werden, über das Netzwerk versendet und in einem extra dafür aufgebauten Active Directory eduroam.mwn.de und zwei installierten und konfigurierten NPS-Servern geprüft. Den Dienst nutzen im Jahr 2010 rund 300 verschiedene Nutzer.

1.7.2.3.2 MAC-Adress Authorization im LRZ Pool Um den Zugriff ins Netz im öffentlichen LRZ Pool von unbekannten Geräten zu verhindern, waren bislang MAC-Adressen fest an den jeweiligen Switchen hinterlegt. Mit der Umstellung auf NPS werden nun die MAC-Adressen der Rechner als Benutzerobjekte im Active Directory hinterlegt. Meldet sich ein Ge- rät an den jeweiligen Switchen, prüfen diese die Berechtigung, am Netz teilzunehmen gegenüber dem Active Directory ab. Die Verwaltung der Berechtigung konnte so ins AD verlagert und die notwendigen Rechte für die Verwaltung der Switches reduziert werden. In den nächsten Monaten sollen weitere Pools umgestellt und der Dienst an Externe weitergegeben werden.

1.7.3 Desktop Management Die PC-Gruppe hat unterschiedliche Modelle für die Bereitstellung von aktuellen Windows- Arbeitsplätzen für verschiedene Kundengruppen entwickelt. Die Lösungen reichen dabei vom vollwertigen Mitarbeiterarbeitsplatz über Terminalserverlösungen für Mitarbeiter bis zum virtuellen Desktop für Testzwecke. Für Studenten werden sowohl vollwertige Rechnerpools als auch auf Terminalserverlösun- gen basierende Pools angeboten. Im Rahmen des MWN-AD wird der Light-Desktop angeboten, bei dem Institutionen Rechner in die Infrastruktur integrieren können und so die Vorteile des zentralen MWN-AD für das Desktopmanagement mitnutzen können, ohne selbst die Infrastruktur zu betreiben. Die Administ- ration der integrierten Instituts-PCs übernehmen dabei wie bisher die lokalen Administratoren. Die verschiedenen Rechnergruppen setzen sich zahlenmäßig Ende 2010 wie in Tabelle 17 gezeigt zusammen. Bei den Kunden für den Remote Desktop Management Service in der ADS/LRZ-Domäne fanden in 2010 einige Umrüstungen statt: • LMU BIO: Aufbau eines Rechnerpools mit Windows 7 • BAdW: laufende Modernisierung der Hard- und Softwareausstattungen • LRZ: o laufende Modernisierung der Hard- und Softwareausstattung an den Clients o Beginn der Windows 7 Verteilung o Umzug der Clients in das MWN-AD o Umstellung von Pool und Kurs auf Windows 7 Auch im Jahr 2010 wurden viele Stunden für Kundenberatung erbracht, um das Angebot des zentralen Speichers und des „Desktop Light“ vorzustellen.

Jahresbericht 2010 des Leibniz-Rechenzentrums 33

Light Desktop Pool und Kurs Fully Managed Desktop LRZ 57 (57) 193 (189) BAdW 171 (173) TUM 1272 (582) 37 (37) LMU 153 (117) 35 (27) HMT 60 (60) HFF 8 (8) Summen 1425 (699) 197 (189) 364 (362)

Tabelle 17: Clients im MWN-AD

1.7.3.1 System Center Configuration Manager (SCCM) Um das Deployment und Management von Windows Desktops und Serversystemen zu optimieren, wurde der im vergangenen Jahr in Produktion gesetzte System Center Configuration Manager weiter ausgebaut und in die vorhandene Infrastruktur integriert. Der SCCM ist ein Produkt von Microsoft, das zu einer Vielzahl von Management-Produkten der System Center-Familie gehört. Er 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 letzte- ren Fall werden dabei auch Einstellungen und Nutzdaten migriert. Desweiteren ist es möglich, Software auf die gemanagten Clients zu installieren, aktualisieren oder deinstallieren. Ein integriertes Reporting gibt Aufschluss über die Erfolgsrate des Rollouts und etwaige aufgetretene Fehler. Zudem wurde im Jahr 2010 das Patchmanagement über den WSUS integriert, so dass alle Clients mit den jeweils aktuellen Pat- ches von Microsoft versorgt werden. Ein weiteres Ziel war es, das Produkt für eine Nutzung durch Teiladministratoren des MWNs freizuge- ben. Obwohl der SCCM in der aktuellen Version keine Mandantenfähigkeit im eigentlichen Sinn auf- weist, konnte hierzu für die Teiladministratoren eine Möglichkeit geschaffen werden, über die SCCM Console ihre jeweiligen Systeme zu managen. Für die Erprobungsphase konnten hierzu einige Lehrstühle gewonnen werden, um mit deren Feedback den Dienst weiter zu verbessern. Insgesamt gibt es nun je nach Gegebenheit und Anforderung mehrere Varianten für Administratoren, ihre Systeme zu managen und installieren: • Erstellung eines Muster-PCs: Hierbei erstellt der Administrator einen Muster-PC, der anschlie- ßend als Image „aufgezeichnet“ wird. Dieses Image kann nun in relativ kurzer Zeit auf eine Viel- zahl von Rechnern wieder aufgebracht werden. Das Verfahren eignet sich in erster Linie bei Pools und Kursräumen, kann aber auch bei einer Erst-/Grundinstallation von Mitarbeiterrechnern eingesetzt werden. • Bare-Metal Installation mit definiertem Software-Portfolio • Einspielen von Software-Paketen auf eine (Teil-)Menge der administrierten Rechner • Einsehen von Inventarinformationen, Hardwarekonfigurationen Software-Pakete, die sich bereits im Software Repository befinden, können jederzeit benutzt werden - entsprechende Lizenzierung durch den Kunden vorausgesetzt. Software, die 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 Standardsoftware, die aus Sicherheitsgründen aktualisiert werden muss (z.B. Mozilla Firefox, Adobe Flash). Um das verfügbare Software Repository stets aktuell zu halten und an die Bedürfnisse der Nutzer auszurichten, wurden im vergangenen Jahr durchgehend Software-Pakete aktualisiert sowie neue Software in das Repository eingepflegt. Insgesamt stehen derzeit 313 reine Software-Pakete bereit (Treiber-Pakete und Betriebssysteme nicht eingerechnet).

34 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Innerhalb des LRZ und der BAdW hat der SCCM den alten Deployment-Mechanismus über Microsoft Remote Installation Services (RIS) und Windows Deployment Services (WDS) im Jahr 2010 vollständig ersetzt. Dabei werden sowohl die Mitarbeiter-PCs und -Laptops als auch Serversysteme und virtuelle Maschinen über den SCCM installiert und gemanaged. Insgesamt, d.h. MWN-weit, werden vom System Center Configuration Manager 489 Systeme (im Vor- jahr 370) verwaltet. Für 2011 ist eine kontinuierliche Verbesserung des Dienstes vorgesehen. So sollen ein höherer Automati- sierungsgrad beim Deployment und Management erreicht werden. Ebenso soll die Mandantenfähigkeit weiter verbessert werden und die Bedienung für Administratoren vereinfacht werden.

1.7.4 Server Management Die PC-Gruppe betreut im Rahmen ihrer Tätigkeit auch zahlreiche Serversysteme. Zum einen zur Erbrin- gung der Hintergrunddienste für den Clientbetrieb, wie das MWN-AD, Exchange oder die Softwarever- teilung SCCM, zum anderen für andere Abteilungen oder für externe Kunden. Das letzte Jahr stand dabei im Zeichen der zunehmenden Server-Virtualisierung. Neue Server werden nur noch als virtuelle Instanzen in Betrieb genommen und zahlreiche Server auf physischer Hardware wurden virtualisiert. Dabei konnten Neuanschaffungen von Hardware, die aus der Garantie gelaufen war, vermieden und auch Stromkosten eingespart werden. Bislang sind die Erfahrungen mit den virtualisierten Ma- schinen zufriedenstellend. Nachfolgend werden einige der wichtigsten Veränderungen in 2010 im Bereich des Server Managements angeführt.

1.7.4.1 MS-SQL-Server Cluster Mit der Einführung des LRZ-VMware-Cluster wurde ein MS-SQL-Server Cluster auf Basis der Microsoft Cluster Services aufgebaut. Dabei wurde der Speicher für die Datenbanken über iSCSI angebunden. In den letzten Monaten kam es aufgrund von Netz- und NAS-Wartungen immer wieder zu größeren Unter- brechungen in der Verfügbarkeit des Clusters und der VMware-Management Werkzeuge. Um diese Ab- hängigkeiten aufzulösen, wurde in 2010 ein neues Cluster aus zwei physischen Maschinen auf Basis von MS-SQL 2008 R2 aufgebaut. Der Storage für die Datenbanken ist nun lokal angebunden. Somit wurde eine weitestgehende Abhängigkeit vom zentralen NAS und vom Netz aufgelöst. Die Datenbanken selbst werden entweder gespiegelt betrieben oder bei Datenbanken, wo dies nicht notwendig ist, werden diese nur auf einem der beiden Server betrieben. Mithilfe von internen Methoden des SQL-Servers werden dann die Datenbanken gesichert, bereinigt und anderen Wartungsschritten unterzogen. In 2011 sollen weitere MS-SQL-Datenbanken von älteren Systemen auf den leistungsfähigeren zentralen MS-SQL- Datenbankcluster umgezogen werden.

1.7.4.2 Citrix-Terminalserverfarm In 2010 stand die Erneuerung der auf Windows 2003 basierenden Citrix Farm an. Auf Basis von VMware wurden fünf virtuelle Server mit Windows 2008 x64 und Citrix Xenapp 5.5 aufgebaut. Drei der Server dienen dabei als Applikationsserver, ein Server fungiert als Webserver, der die Clients über https an die Applikationsserver weiterleitet und nun die veröffentlichten Anwendungen auch über ein Webinterface zur Verfügung stellt. Der fünfte Server agiert als Secure Gateway und ermöglicht den Zugriff auf die Citrix-Farm von außerhalb des MWN. Damit ist es den Mitarbeitern möglich, von überall auf ihre Daten bzw. „gepublishten“ Applikationen zuzugreifen und somit die Flexibilität zu erhöhen.

1.7.4.3 Exchange 2010 Im Rahmen der Migration auf 2010 war die PC-Gruppe intensiv in den Neuaufbau und die Migration der Exchange Infrastruktur eingebunden. Wichtigstes Ziel hierbei war das Auflösen von Abhängigkeiten von Hardware und Netz und die Aktualisierung der Betriebssysteme mit Windows 2008 R2. So konnte durch die Virtualisierung sämtlicher Serversysteme eine größere Flexibilität von Systemressourcen (CPU und Memory) und eine erhöhte Datensicherheit durch Snapshots gewonnen werden. Mit der Einführung von Database Availability Groups (DAG) in Exchange 2010 wurde auch das fehleranfälligere Single Copy Cluster von Exchange 2007 abgelöst.

Jahresbericht 2010 des Leibniz-Rechenzentrums 35

1.7.4.4 iET ITSM Das LRZ ist derzeit dabei, ein IT-Servicemanagement nach ISO/IEC20000 aufzubauen. Hier wurde als Tool-Unterstützung das Produkt „iET ITSM“ von iETSolutions ausgewählt. Neben der Betreuung der Systeme ist die PC-Gruppe zudem im LRZ Entwicklungsteam vertreten und kümmert sich um die In- tegration und Anpassung des Tools. Um einen langfristigen und stabilen Betrieb zu gewährleisten, wurde zu Beginn des Jahres ein Betriebs- konzept entwickelt und der Aufbau der Serversysteme durchgeführt. Für in-House-Entwicklungen und Anpassungen am Tool wurden hierzu zunächst Entwicklersysteme installiert. Später folgten jeweils ein Test-, Schulungs- und Produktionssystem. Alle Systeme können über eigens konzipierte Updatemecha- nismen auf den neuesten Stand gebracht werden. Damit im Tool immer aktuelle Kunden- und Kontakt- Daten vorliegen, wurde hierfür eine Schnittstelle zu LRZ-SIM (Secure Identity Management) als Ort der Wahrheit für Kundendaten programmiert. Des Weiteren wurde die Nutzer-Authentifizierung im Tool an LRZ-SIM gebunden. Somit können sich die Mitarbeiter (via Client) und Kunden (via Webportal) mit ihren persönlichen Kennungsdaten anmelden. Der Fokus von Anpassungen im Tool wurde im Jahr 2010 auf das Incident Management gelegt. Hierfür wurden die Formulare angepasst, Abfragen geändert und weitere Anforderungen gemäß der LRZ- Prozessdefinition umgesetzt. Als Pilotgruppe testete die Linux-Cluster-Gruppe (und später zusätzlich noch die HLRB-Gruppe) das Incident Management, das im Jahr 2011 das bisherige Ticketsystem ablösen soll. Parallel dazu wurde in einer Arbeitsgruppe, die sich aus allen Abteilungen zusammensetzte, ein CMDB- Konzept sowie deren Integration in iET ITSM entwickelt. Das Konzept wurde dazu in mehreren Proof-of- concepts auf Tauglichkeit und Erweiterbarkeit getestet und wird im Jahr 2011 umgesetzt.

1.7.4.5 VMware Infrastruktur Die PC-Gruppe ist auch am Betrieb der virtuellen Infrastruktur des LRZ beteiligt. Zum Einen erfolgt das Deployment von virtuellen Windows-Maschinen (Servern und Clients) ausschließlich durch die PC- Gruppe. Hierfür wird wie oben bereits beschrieben SCCM eingesetzt. Zum Anderen obliegt der Gruppe die Administration des zentralen vCenter-Servers, der für das Management der ESX-Hosts zuständig ist. Hier wurde im vergangenen Jahr ein Upgrade auf vSphere Version 4.1 vorgenommen sowie die dahinter liegenden Verwaltungsdatenbanken auf das neue SQL-Cluster verschoben. Seit vergangenem Jahr wurden die Kompetenzen weiter ausgebaut, so dass es nun einen Ansprechpartner in dieser Gruppe für die gesamte VMware-Administration gibt. Dies dient auf der einen Seite der Entlas- tung der Gruppe COS, die diese Aufgabe bisher alleine bewältigt hat, und sorgt andererseits für größere Redundanz bei etwaigen Störungen. Um die Kompetenzen nachhaltig auszubauen, nahmen zwei Mitglie- der an einer Schulung für vSphere 4.1 teil, die die Basis für die Zertifizierungsprüfung zum VMware Certified Professional (VCP) bildet. Die Zertifizierungsprüfung ist für das Jahr 2011 geplant.

1.7.5 Microsoft Office Sharepoint Services (MOSS) In 2009 wurde mit dem Aufbau einer Kollaborationslösung auf Basis von MOSS 2007/2010 begonnen und in 2010 fortgesetzt. Ziel ist zum einen die Ergänzung der Groupwarelösung von Exchange 2007/2010, da hier die public Folder entfallen sind und diese durch MOSS ersetzt wurden. Zum anderen bietet MOSS die Möglichkeit, für Gruppen die Zusammenarbeit zu verbessern, um z.B. gemeinsam an Dokumenten zu arbeiten oder die Zusammenarbeit besser über Gruppenkalender, Besprechungsbereiche, Benachrichtigungen, Wikis oder gemeinsame Aufgaben zu organisieren. Es gibt auch die Möglichkeit, komplexere Prozesse in Workflows abzubilden, die häufig in Verwaltungen zum Einsatz kommen. Der Zugriff auf die Ressourcen erfolgt webbasiert. Auf der bereits in 2009 aufgebauten MOSS-2007-Farm wurden weitere Sites angelegt, um weitere Erfah- rungen in der Zusammenarbeit zu gewinnen. Zu Beginn des dritten Quartals 2010 wurde die neue Version von MOSS 2010 veröffentlicht. Nach den bereits erfolgversprechenden Tests mit den Vorversionen des Produktes mit verbesserten Verwaltungs- und Bedienoberflächen wurde im Sommer rasch eine neue Farm auf Basis von MOSS 2010 aufgebaut. Es handelt sich dabei um einen Datenbankserver mit MS- SQL 2008 und einem dedizierten Server für die MOSS-Installation. Die Sites sind von außerhalb über ein Forefront Threat Management Gateway (TMG) zugänglich.

36 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Da der Dienst auch kostenpflichtig für Externe angeboten wird, wurde großes Augenmerk auf die Ab- trennung einzelner Mandanten (TUM, LMU, BAdW, LRZ-SIM) gelegt. Dies wird über eine Auftrennung der Mandanten im AD und verschiedene Proxy Accounts abgebildet. Aus dem Alltagsbetrieb ergab sich eine Auftrennung der einzelnen Sites in eigene Datenbanken, Ressource Pools und IIS-Websites mit individuellen Ports. Das erhöht die Modularität und es können so einzelne Sites unabhängig voneinander gesichert und wieder hergestellt werden. In enger Zusammenarbeit mit den Site-Nutzern fanden verschiedene Anpassungen von Sites statt. Der Nutzerkreis umfasste zum Ende des Jahres 2010 neben mehreren Sites für die Gruppenkoordination, Ausbildung und Hotline auch Sites für die Koordination zweier bayernweiter Arbeitskreise und auch zur Koordination mit externen Dienstleistern des LRZ für den neuen Höchstleistungsrechner. Zwei zahlende externe Kunden konnten auch gewonnen werden. Eine besondere Herausforderung stellte dabei eine komplexe Migration einer MOSS 2007 Site von einem externen Altsystem in die LRZ-Installation dar.

1.7.6 Tätigkeiten im Rahmen der Berufsausbildung Der PC-Gruppe waren in 2010 zunächst vier und dann, ab September, drei Auszubildende der Fachrich- tung Fachinformatiker Systemintegration (FISI) zugeordnet. Die Auszubildenden sollen dabei den Alltag eines Systemadministrators kennenlernen und auch projektorientiert arbeiten. Zwei Auszubildende konnten im Frühjahr/Sommer 2010 erfolgreich ihre Abschlussprüfung ablegen. Ein Auszubildender wurde vom LRZ übernommen. Die Themen der Abschlussarbeiten ergaben sich aus dem aktuellen Arbeitsum- feld und umfassten zum einen den Aufbau eines NPS Servers und zum anderen die Umstellung der Kurs- räume auf Windows 7 mit den entsprechenden Anpassungen im MWN-AD und dem SCCM. Seit Anfang Oktober werden die Auszubildenden auch in der Hotline/Beratung eingesetzt. Voran ging eine intensive Schulung der Auszubildenden zu den wichtigsten Diensten am LRZ sowie eine allgemeine Schulung im Umgang mit Kunden am Telefon. Im Rahmen eines zweiwöchigen Austausches im Herbst 2010 mit dem Wissenschaftszentrum Weihenste- phan (WZW) vermittelten die Auszubildenden am LRZ den Gästen vom WZW die vorher selbst über den Sommer erworbenen Kenntnisse zu Installation und Betrieb eines Active Directory. Weitere, wichtige Aufgaben der Auszubildenden in 2010 waren: • Migration der LRZ-Rechner in die neue Domäne ads.mwn.de • Softwarepaketierung • Erarbeiten von Dokumentation für den allgemeinen Betrieb • Mitarbeit im Life-Cycle Management der Rechner am LRZ • vierwöchiges Praktikum in der LRZ-Netzwartung

1.8 Server- und Benutzerzertifizierung nach X.509 Das LRZ ist mit mehreren Zertifizierungs- und Registrierungsstellen (CAs und RAs) in die Zertifizie- rungshierarchie „Global“ der Public-Key-Infrastruktur des Deutschen Forschungsnetzes (DFN-PCA) eingebunden, deren Wurzelzertifikat von einer kommerziellen CA (T-TeleSec Trust Center der Deutschen Telekom AG) beglaubigt wird. Damit gibt es dann keine Notwendigkeit für die Endbenutzer, das Wurzel- zertifikat explizit durch Import als vertrauenswürdig zu kennzeichnen, wenn das schon vom Hersteller der Software erledigt wurde. Das LRZ betreibt im Rahmen dieser Hierarchie eine Zertifizierungsstelle (CA) und Registrierungsstelle (RA) sowie für die beiden Münchner Universitäten jeweils eine Registrierungsstelle. Insgesamt gibt es am LRZ vier Registrierungsstellen, die derzeit neue Zertifikate ausstellen: • eine RA für die Bayerische Akademie der Wissenschaften einschließlich des LRZ selbst sowie für solche Einrichtungen im Münchner Wissenschaftsnetz, die keine eigene CA betreiben (102 neue Zertifikate im Jahr 2010) • eine Server-RA für die TU München (72 neue Zertifikate im Jahr 2010) • eine Server-RA für die LMU München (103 neue Zertifikate im Jahr 2010) • eine Server- und Nutzer-RA für das Grid-Computing im Münchner Wissenschaftsnetz und an der Universität der Bundeswehr München (zusammen 128 neue Zertifikate im Jahr 2010)

Jahresbericht 2010 des Leibniz-Rechenzentrums 37

Die drei erstgenannten gehören dabei jeweils zu einer CA bei der jeweiligen Einrichtung; die Grid-RA gehört zu einer CA, die von der DFN-PCA betrieben wird.

1.9 Bearbeitung von Missbrauchsfällen Das LRZ ist bei der DENIC eG (d.h. bei der Registrierungsstelle für Domains unterhalb der Top-Level- Domain „DE“) als Ansprechpartner für Domains des Münchner Wissenschaftsnetzes (MWN) eingetragen (u.a. für uni-muenchen.de, lmu.de, tu-muenchen.de und tum.de). Ähnliches gilt für die IP-Netze, die dem LRZ zugeteilt wurden. Damit ist das LRZ Anlaufstelle für sehr viele Anfragen und Beschwerden, die diese Domains bzw. IP-Adressen betreffen.

1.9.1 Statistik der Missbrauchsfälle Im Jahr 2010 nahm die Zahl der entdeckten Missbrauchsfälle gegenüber dem Vorjahr wieder zu (siehe Abbildung 7). Zum Einen kommen wegen der weitgehenden Kriminalisierung der Szene (d.h. der „Viren- Bastler“, Spammer und Hacker) nahezu ausschließlich „qualitativ hochwertige“ Schädlinge und Angriffs- Tools (Malware) zum Einsatz. Zum Anderen ist das Sicherheitsbewußtsein bzw. -verhalten zu vieler MWN-Benutzer nach wie vor unzureichend. Diesem setzt das LRZ diverse sicherheitsrelevante Dienste entgegen (siehe Abschnitt 1.7.1).

3000 1860 Gemeldete Fälle Vom LRZ selbst entdeckte Fälle 2500 1362

2000

1319 1500 1085 930 792 1000 377

500 64 309 944 916 243 572 324 393 44 53 85 239 292 258 0 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 Abbildung 7: Missbrauchsfälle im MWN

Die insgesamt 2.776 Abuse-Fälle des Jahres 2010 betrafen 3.124 MWN-Rechner. In diesem Rahmen erhielt das LRZ 1.227 Hinweise, Beschwerden, Anfragen usw. von außerhalb. Zum Glück verletzten nur bei ganz wenigen Sicherheitsvorfällen MWN-Benutzer absichtlich die Nut- zungsregeln; der überwiegende Teil der Fälle betraf Rechner, • die von Würmern, trojanischen Pferden, Botnet-Drohnen usw. befallen wurden; die eingedrun- genen Schädlinge versuchten dann ihrerseits, sich weiter zu verbreiten, oder der Rechner wurde zu einem Teilnehmer an einem Botnet und verursachte danach Schäden (z.B. durch Versenden von Spam-Mails). • die über aktuelle Sicherheitslücken angegriffen, kompromittiert und dann für weitere Angriffe missbraucht wurden.

38 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

Involvierte Eingegangene Anzahl Art der Vorgänge Rechner /Benutzer Beschwerden, der Fälle des MWN Anfragen usw. Fälle mit rechtlichen Aspekten: Verletzungen des Urheberrechts 649 677 686 Sonstige Fälle 2 2 2 Teilsumme 651 679 688 Sonstige kompromittierte Rechner: DFN-CERT: Automatische Warnungen 173 471 173 Port-/Vulnerability-Scans 5 5 8 Sonstige Beschwerden (u.a. DoS) 4 5 6 DFN-CERT: Sonstige gemeldete Fälle 3 3 3 Teilsumme 185 484 190 Organisatorische Vorgänge: Aktualisierung der Monitoring-Ausnahmelisten 26 30 3 Sonstige Fälle 9 7 8 Teilsumme 35 37 11 Fälle im Bereich „E-Mail“: Sonstige Mail-Fälle 11 3 23 Spam-Versand über kompromittierte Rechner 8 8 22 Unberechtigte Spam-Beschwerden 7 ‒ 7 Hinweise auf / Fragen zu Phishing-Aktionen 4 – 15 Teilsumme 30 11 67 Sonstige Fälle 15 9 15 Summe der gemeldeten Fälle 916 1.220 971 Tabelle 18: Missbrauchsfälle, die dem LRZ gemeldet wurden, oder organisatorische Vorgänge

Ca. 30% der bearbeiteten Fälle gehen auf Beschwerden, Hinweise, Anfragen usw. zurück, die dem LRZ von außerhalb geschickt wurden, oder auf organisatorische Vorgänge (siehe Tabelle 18). Bei diesen Fäl- len sind folgende Punkte besonders erwähnenswert: • Bei ca. 70% dieser gemeldeten Fälle handelt es sich um Verletzungen des Urheberrechts. Diese Beschwerden haben seit 2008 drastisch zugenommen (siehe Abbildung 8). Dabei werden Beschwerde-Mails von Organisationen verschickt, die im Auftrag von amerikanischen oder europäischen Rechte-Inhabern die wichtigsten File-Sharing-Netze kontinuierlich nach Verletzungen des Urheberrechts durchsuchen. Selbst wenn diese Fälle bis jetzt noch keine juristischen Konsequenzen haben, sind es keine Kavaliersdelikte; auch nach deutschem Recht ist es verboten, urheberrechtlich geschütztes Material (überwiegend Filme und MP3s und teilweise auch Software) in File-Sharing-Netzen anzubieten. Unabhängig davon verstößt es auch gegen die Nutzungsordnung des LRZ bzw. MWN. • Das DFN-CERT beobachtet und analysiert eine Reihe von Quellen, um Probleme zu entdecken, die sich auf Systeme der DFN-Anwender beziehen. Darüber hinaus werden eigene Sensoren betrieben, um die Informationsbasis weiter auszudehnen. Das DFN-CERT sammelt, korreliert und normiert diese Daten und stellt jedem DFN-Anwender den Zugriff auf diejenigen Daten zur Ver- fügung, die die eigene Einrichtung betreffen. Das LRZ nutzt seit März 2009 diesen Dienst „Automatische Warnungen“ und erhält in diesem Rahmen entsprechende Hinweis-Mails. Da an das MWN mehr als 80.000 Endsysteme angeschlossen sind, trifft beim LRZ an vielen Werktagen eine Warnung ein, die meist mehrere auffäl- lig gewordene IP-Adressen enthält.

Jahresbericht 2010 des Leibniz-Rechenzentrums 39

800 Fälle Beschwerden 686 700 649 617 600 570 500

400

300 267 239 200

100 37 28 44 54 9 9 21 20 9 10 0 2003 2004 2005 2006 2007 2008 2009 2010

Abbildung 8: Fälle wegen Verletzung des Urheberrechts

• Bei den Monitoring-Verfahren (siehe unten) gibt es zwangsläufig jeweils eine Ausnahmeliste mit Rechnern, bei denen das auffällige Verhalten legitim ist. Die Aktualisierung dieser Listen betraf überwiegend das „Mail-Monitoring“, weil es relativ viele legitime Ursachen für ein erhöhtes Mail-Aufkommen gibt: o Inbetriebnahme eines neuen Mail-Servers/-Gateways oder Servers für Mail-Verteiler o Regelmäßiges Verschicken von Rundbriefen mit vielen Empfängern o Verschicken von Benachrichtigungen durch ein System, das die korrekte Funktion / Ver- fügbarkeit von Diensten oder Rechnern überwacht Das LRZ geht i.a. aktiv auf die Betreiber von Rechnern zu, bei denen das Mail-Aufkommen vermutlich legitim ist (z.B. wenn im DNS-Namen die Zeichenfolge „mail“ vorkommt). Dies ist auch der Grund dafür, dass die Fälle dieser Gruppe nur selten von LRZ-Kunden initiiert werden. • Früher kam es häufiger vor, dass ein Rechner mehrere Monate oder evtl. sogar Jahre am Internet- Übergang gesperrt blieb, weil sich niemand gemeldet hat. In diesen Fällen wurde dann das Ent- sperren in einem gesonderten Fall bearbeitet. 2010 gab es nur noch drei derartige Fälle (Teil der „sonstigen organisatorischen Fälle“), weil diese Sperren inzwischen nach 90 Tagen automatisch aufgehoben werden. Das LRZ hat die Erfah- rung gemacht, dass nach 3 Monaten die Rechner meistens gesäubert oder neu installiert wurden. Traf dies nicht zu, wurden die Rechner erneut gesperrt. • Bei den unberechtigten Spam-Beschwerden treten im wesentlichen zwei Fälle auf: o Wenn ein Mail-System (z.B. die Mail-Server des LRZ) eine einmal angenommene E- Mail nicht zustellen kann, muss es laut Norm den Absender in einem Non-Delivery- Report (NDR) darüber informieren. Hat ein Spammer die eigene Mail-Adresse als Ab- sender von Spam-Mails missbraucht, erhält man manchmal NDRs zu diesen Spam-Mails, die man gar nicht selbst verschickt hat; in diesem Fall ist man ein indirektes Opfer des Spammers. Manche Empfänger fühlen sich durch diese nicht selbst ausgelösten NDRs derart beläs- tigt, dass sie sich beim Betreiber des korrekt arbeitenden Mail-Systems beschweren. o Manchmal erhält das LRZ Beschwerden über E-Mails, die nach Ansicht des LRZ einen legitimen bzw. seriösen Inhalt haben. In diesen Fällen handelte es sich meist um Rund- briefe einer Organisation des MWN oder um Beiträge eines seriösen Newsletters. Man- che Nutzer tragen sich selbst bei einem Newsletter ein, vergessen dies dann aber nach einiger Zeit und fühlen sich dann von Beiträgen des betreffenden Newsletters belästigt. • Auch 2010 wurden mehrere Phishing-Angriffe auf Mail-Accounts von MWN-Teilnehmern durchgeführt. Meist melden sich dann freundlicherweise MWN-Teilnehmer, um das LRZ auf

40 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

diese Angriffe aufmerksam zu machen. Leider hat sich immer noch nicht überall herumgesprochen, dass man nach einer Aufforderung per E-Mail niemals Account-Daten herausgeben darf. Entsprechende Schutzeinrichtungen bei den Mail-Systemen des LRZ verhindern aber, dass gestohlene Mail-Accounts in großem Umfang zum Versenden von Spam-Mails missbraucht werden können. Zu den von außerhalb gemeldeten Fällen kamen weitere, auf die das LRZ im Rahmen der Netzüber- wachung selbst aufmerksam wurde (siehe Tabelle 19). Die Monitoring-Verfahren am Internet-Übergang (d.h. am Übergang vom MWN zum X-WiN) sind trotz ihrer Einfachheit erstaunlich wirksam; folgende Indikatoren eignen sich erfahrungsgemäß sehr gut, um (sehr wahrscheinlich) kompromittierte Rechner zu entdecken: • Bei der ersten Gruppe ist der Indikator derart treffsicher, dass das LRZ riskiert, die auffällig ge- wordenen Rechner automatisch am Internet-Übergang zu sperren; die zuständigen Netzverant- wortlichen werden selbstverständlich ebenso automatisch sofort davon verständigt. o Der Rechner ist mit einem der folgenden Schädlinge infiziert: . Trojaner „Bredolab“ . Wurm „Conficker“ . Trojaner „Gozi“ . Botnet-Drohne „Mariposa“ . Botnet-Drohne „Torpig“ . Virus „Sality“ o „SSH-Angriff“ durch einen MWN-Rechner. In diesen Fällen öffnet der MWN-Rechner innerhalb kurzer Zeit viele SSH-Verbindungen zu anderen Rechnern im Internet. Ein kompromittierter MWN-Rechner . sucht dabei nach Rechnern mit einem aktiven SSH-Server, d.h. es handelt sich um einen SSH-Scan. . versucht sich per SSH bei einem anderen Rechner anzumelden. Dabei werden Kennungen ausprobiert, die bei vielen Systemen vorhanden sind (wie z.B. „root“, „admin“ oder „guest“). Als Passwort testet man eine Liste von Wörtern, die sehr oft als Passwort verwendet werden; es handelt sich also um einen Angriff auf „schlechte“ Passwörter. Es ist erschreckend, wie häufig man auf diese einfache Art in einen Rechner einbrechen kann. o Auf dem Rechner läuft ein FTP-Server, der auf einem Nicht-Standard-Port arbeitet (d.h. nicht auf dem allgemein üblichen Port 21). • Bei den restlichen Indikatoren werden Benachrichtigungs-Mails vorformuliert; ein Mitglied des Abuse-Response-Teams entscheidet jedoch jeweils, ob die E-Mail auch abgeschickt und der Rechner evtl. zusätzlich gesperrt werden soll. o Der MWN-Rechner öffnet innerhalb kurzer Zeit viele Mail-Verbindungen zu anderen Rechnern im Internet. Diese MWN-Rechner sind fast immer kompromittiert, wobei der Rechner zum Versenden von Spam- oder Phishing-Mails missbraucht wird. Dieses Monitoring-Verfahren wird kurz als „Mail-Monitoring“ bezeichnet. o Der MWN-Rechner öffnet innerhalb kurzer Zeit extrem viele Verbindungen zu anderen Rechnern im Internet. Durch zusätzliche Indikatoren kann man erkennen, ob es sich wahrscheinlich um einen massiven Port-Scan oder um einen Denial-of-Service-Angriff (DoS) handelt. o Der Rechner fällt durch einen außergewöhnlich hohen Datenverkehr auf. Es handelt sich dabei auch manchmal um Rechner, die für die Verteilung urheberrechtlich geschützter Daten missbraucht wurden. o Ein aktiver SSH-Server eines MWN-Rechners wird extrem oft kontaktiert. In diesen Fäl- len ist der MWN-Rechner (noch) nicht kompromittiert, sondern das Opfer eines Angriffs auf „schlechte“ Passwörter (siehe oben). Das Abuse-Response-Team weist den An- sprechpartner des MWN-Rechners auf den erfolgten Angriff hin und gibt ihm den Rat, in den Log-Meldungen des SSH-Servers nach erfolgreichen Anmeldevorgängen zu suchen; es könnte sich dabei um einen Einbruch handeln. Nur im Falle eines „SSH-Angriffs“ durch einen MWN-Rechner erfolgt die automatische Sperre sofort bei der ersten Auffälligkeit. Bei den übrigen Monitoring-Verfahren mit einer automatisierten Reaktion wird eine dreistufige Eskalation durchgeführt:

Jahresbericht 2010 des Leibniz-Rechenzentrums 41

1. Der Rechner fällt zum ersten Mal auf: Eine Informations-Mail wird verschickt. 2. Nach mindestens einem Tag fällt der Rechner erneut auf: Eine Erinnerungs-Mail wird verschickt. 3. Nach mindestens einem weiteren Tag fällt der Rechner noch einmal auf: Der Rechner wird gesperrt und eine entsprechende Benachrichtigung verschickt. Zu den aufgeführten Indikatoren gibt es natürlich jeweils eine Ausnahmeliste von bekannten „sauberen“ Rechnern, die dadurch vor einer Sperre geschützt werden.

Verfahren, Anzahl Anzahl durch das die verdächtigen Rechner entdeckt wurden der Fälle der Rechner Explizit erkannte Schädlinge: Wurm „Conficker“ 499 502 Trojaner „Bredolab“ 249 249 Trojaner „Gozi“ 174 174 Botnet-Drohne „Mariposa“ 128 128 Botnet-Drohne „Torpig“ 65 65 Sonstige Botnet-Drohnen 8 8 Virus „Sality“ 6 6 Teilsumme 1.129 1.132 Sonstige Monitoring-Verfahren: NAT-o-MAT (schwere Fälle) 427 427 Mail-Monitoring 125 161 „SSH-Angriff“ durch einen MWN-Rechner 68 68 FTP-Server auf einem Nicht-Standard-Port 38 38 Port-Scans 25 25 DoS 9 9 Extrem hoher Datenverkehr 9 9 „SSH-Angriff“ auf einen MWN-Rechner 7 7 Sonstige Angriffe 4 9 Teilsumme 712 753 False Positives: Sonstige False-Positives 15 15 Mail-Monitoring 4 4 Teilsumme 19 19 Summe der vom LRZ selbst endeckten Fälle 1.860 1.904 Tabelle 19: Kompromittierte Rechner, die vom LRZ selbst entdeckt wurden

Neben den Monitoring-Verfahren am Internet-Übergang verbessert auch noch der sogenannte „NAT-o- MAT“ (siehe Kapitel 3.4.1) durch automatisierte Mechanismen die Sicherheit des MWN. Es handelt sich dabei primär um ein transparentes NAT-Gateway, das bei den Rechnern mit privater IP-Adresse nicht konfiguriert werden muss. Zusätzlich zur Adressumsetzung sorgt ein „AutoMAT“ für eine Bandbreiten- regelung und verhindert weitgehend Angriffe auf andere Rechner durch Port-Scans, DoS und Spam- Versendung: Der NAT-o-MAT blockt automatisch kompromittierte Rechner, die den Betrieb beeinträch- tigen, und veranlasst den Besitzer eines derartigen Rechners durch geeignete Hinweise, seinen PC zu säubern. In schweren Fällen schickt der NAT-o-MAT außerdem noch eine Hinweis-Mail an die zuständigen Netz- verantwortlichen. In der Statistik werden nur diese Fälle gezählt. In den folgenden Fällen sperrt der NAT-o-MAT einen Rechner nach einer Vorwarung dauerhaft; das Aufheben der Sperre muss danach durch ein Mitglied des Abuse-Response-Teams erfolgen. • Einer der folgenden Schädlinge wird erkannt: Bredolab, Conficker, Gozi, Torpig, Sality

42 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

• SSH-Angriff • FTP-Server auf einem Nicht-Standard-Port Seit 2006 wirkt sich der NAT-o-MAT nicht mehr nur auf Rechner mit privaten IP-Adressen aus, die Dienste im Internet in Anspruch nehmen wollen. Durch ein geeignetes Policy-based-Routing werden auch sämtliche VPN- und Einwahlverbindungen (Modem, ISDN und M-net) zwangsweise durch den NAT-o-MAT geleitet. Dementsprechend nahmen auch die vom NAT-o-MAT erkannten Missbrauchsfäl- le drastisch zu. Bei den selbst entdeckten Fällen (siehe oben, Tabelle 19) sind folgende Punkte besonders erwähnenswert: • Der Wurm „Conficker“ tauchte im Oktober 2008 auf und treibt seit dieser Zeit auch im MWN sein Unwesen. Zu Beginn verbreitete sich Conficker ausschließlich über eine kritische Schwach- stelle, durch die er selbständig von außen in einen Windows-Rechner eindringen konnte. Micro- soft stellte schon Ende Oktober 2008 einen Security-Patch zum Schließen dieser Lücke bereit. Spätere Versionen von Conficker können sich zusätzlich noch über Netz-Laufwerke und Wech- seldatenträger (wie z.B. USB-Sticks) verbreiten. Auch nach mehreren Monaten nahm im MWN die Zahl der Neuinfektionen nicht ab. Deshalb wurde 2009 ein spezialisiertes Intrusion-Detection-System (IDS) in Betrieb genommen, mit dem man infizierte Rechner finden kann. Das IDS wurde später erweitert, um auch noch andere Schädlinge erkennen zu können. Trotz dieser Maßnahmen war Conficker im MWN auch 2010 immer noch sehr aktiv. • Auch 2010 waren die Spammer wieder sehr aktiv und haben viele kompromittierte Rechner im MWN dazu missbraucht, Spam-Mails zu verschicken (siehe das Mail-Monitoring). Dabei ist es keine Seltenheit, wenn ein Rechner mehr als 20.000 Spam-Mails pro Stunde verschickt. • Leider kann man bei den Monitoring-Verfahren, die beim LRZ eingesetzt werden, False-Positives nicht ganz vermeiden. Im Falle des Mail-Monitoring handelte es sich z.B. um lange Zeit vollkommen unauffällige Rechner, die plötzlich ein ungewöhnliches Mail-Aufkommen zeigten. In diesen Fällen gab es auch keine Hinweise für eine legitime Mail-Quelle: Die Rechner hatten weder einen aussagekräf- tigen DNS-Namen noch konnte auf dem Mail-Port ein Mail-Server kontaktiert werden. Zum Glück war in den meisten dieser Fälle das verdächtige Mail-Aufkommen der betroffenen Rechner nicht besonders hoch; die zuständigen Netzverantwortlichen wurden deshalb überwie- gend nur informiert und die Rechner nicht sofort gesperrt. Es handelte sich meist um erst kürz- lich in Betrieb genommene Mail-Server oder -Gateways oder um Rechner, von denen nur relativ selten (oder auch nur einmalig) Rundbriefe, Einladungen usw. an sehr viele Empfänger verschickt wurden.

1.10 IT Bibliotheksverbund Bayern Seit Mai 2008 ist das Rechenzentrum der Verbundzentrale des Bibliotheksverbundes Bayern (BVB) in das LRZ integriert. Es handelt sich mittlerweile um insgesamt 211 Betriebssysteminstanzen (Solaris, Linux, Windows), die teils auf physischen Maschinen, teils auf virtuellen realisiert sind. Ende 2009 wurden 143 Betriebssysteminstanzen gezählt, damit sind also in 2010 68 Betriebssysteminstanzen dazuge- kommen. Die physischen Maschinen und die Wirtssysteme für die virtuellen Solaris-Systeme werden dabei vom BVB-IT-Team betrieben, während die virtuellen Linux- und Windows-Systeme auf der VMWare-Farm des LRZ (siehe Abschnitt 2.7.1.1) laufen. Die Betreuung der Anwendungen geschieht nicht durch das LRZ, sondern durch die Verbundzentrale des BVB in der Bayerischen Staatsbibliothek. Zum einen dienen die Systeme als „Lokalsysteme“ der angeschlossenen Bibliotheken (alle Fachhoch- schulbibliotheken, sechs Universitätsbibliotheken, viele weitere staatliche Bibliotheken) und verwalten die Datenbanken mit den Katalogen, die Such- und Bestellmöglichkeiten (OPAC) für die Bibliotheksnut- zer, die Verwaltung der Ausleihe und zahlreiche weitere Dienste. Zum anderen wird eine Verbunddaten- bank von über 1 Terabyte Größe betrieben, die mit den lokalen Datenbanken abgeglichen wird, und die zur Suche im gesamten Verbund und für die Fernleihe aus anderen Bibliotheken gebraucht wird. Die eingesetzte Software ist hauptsächlich SISIS als Bibliothekssystem und Sybase als Datenbank auf den Lokalsystemen sowie Aleph als Bibliothekssystem und Oracle als Datenbank auf den Verbundsystemen. Als Suchmaschine wird Fast eingesetzt. Viele weitere Softwareprodukte für die zentrale Fernleihe, für kontextsensitive Verlinkung, für Web-Oberflächen, zur Digitalisierung, zur Langzeitarchivierung und für andere Aufgaben werden daneben eingesetzt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 43

Die Verbundsysteme und die Lokalsysteme dienen hauptsächlich den Bibliotheken des Bibliotheksver- bundes Bayern (BVB) und des Kooperativen Bibliotheksverbundes Berlin-Brandenburg (KOBV), mit dem eine enge Zusammenarbeit besteht. Nur einzelne Bibliotheken außerhalb dieses Bereiches werden mitversorgt.

1.10.1 Umsetzung Großgeräte-Antrag

1.10.1.1 Lokalsystemcluster Die Ablösung der bis zu acht Jahre alten Rechner der lokalen Bibliothekssysteme war dringend notwendig. Drei der mit Mitteln eines Großgeräte-Antrags beschafften Rechner vom Typ Sun M5000 wurden zu einem hochverfügbaren Cluster zusammengeschlossen. Auf diesem Cluster wurden virtuelle Solaris Be- triebssysteminstanzen (Solaris Container) installiert und hochverfügbar gemacht. Dorthin wurden die einzelnen lokalen Bibliothekssysteme migriert. Momentan werden auf diesem Lokalsystemcluster 66 solcher Solaris Container betrieben. Die flexible Verteilung der Dienste auf die Container ermöglichte auch eine Umstellung des Betriebskon- zeptes für den Hosting Betrieb der lokalen Bibliothekssysteme. So wurde eine Trennung von Datenbank und Weboberfläche erreicht. Dadurch konnte die Netzsicherheit erhöht werden und erreicht werden, daß die einzelnen Bibliotheken ihre OPAC-Weboberflächen anpassen und mit eigenen Zertifikaten für den verschlüsselten Zugang (https) ausstatten konnten. Außerdem wurden Skripte erstellt, die Klone der produktiven lokalen Bibliothekssysteme erzeugen. Dies war vor allem ein Wunsch der Universitätsbibliothe- ken, die bei umfangreichen Änderungen an den Datenbeständen ein Testsystem benötigen.

1.10.1.2 Verbundsystemcluster Auf Seiten des Verbundsystems ist schon seit 2004 ein System auf Basis von Solaris Cluster und Oracle RAC (Real Application Cluster) im Einsatz. Auch hier stand eine Erneuerung der Hardware mit zweien der Rechner vom Typ Sun M5000 aus Großgeräte-Mitteln an. Zusätzlich mussten Betriebssystem, Clus- tersoftware, Datenbanksoftware und auch die Anwendungssoftware Aleph500 in neuen Versionen installiert werden. Daher wurde das System von Grund auf neu installiert und der Umstieg auf die neue Hard- und Software durch eine Datenmigration realisiert. Durch den Einsatz von Zonenclustern und capped Containers konnte einerseits ein hochperformanter Datenbankcluster aufgebaut werden und andererseits konnte eine Lizenzkostenerweiterung für die Datenbanklizenzen vermieden werden. Das neue System wurde auch gleich in einen Netzbereich mit providerunabhängigen IP-Adressen gelegt und somit die Ausfallwahrscheinlichkeit weiter vermindert.

1.10.1.3 Suchmaschinencluster Verbundsystem Die Ende 2009 beschafften Bladesysteme für den Suchmaschinencluster wurden 2010 in Betrieb genommen. Die Performance wurde durch den Einsatz der neuen Hardware weiter verbessert. Durch die erweiterten Resourcen konnten auch weitere Suchindizes für andere Suchkriterien auf die Verbunddatenbank erzeugt werden.

1.10.1.4 Neuaufbau Citrix Farm Die Citrix Farm für die Nutzung der bibliothekarischen Spezialsoftware (Alephclient, Sisisclient, Win- IBW) wurde komplett neu auf Basis von XenApp 5 64bit auf vier virtuellen Maschinen der zentralen VMWare Farm aufgebaut. Für die meisten Nutzer ging ein Wechsel der Anwendungssoftware auf eine neue Version einher mit dem Wechsel auf die neue Citrix Farm. Der Umstieg verlief daher ohne Ein- schränkungen. Die alte Hardware (neun Server in einem Blade-Chassis) konnten abgeschaltet werden.

1.10.1.5 Migration und Update CDROM-Server Farm Auch die Hardware der CDROM-Server war veraltet. Hier wurden virtuelle Maschinen in die Umgebung (Citrix mit Erweiterungssoftware von H+H) einkonfiguriert und die CDROM Datenbanken sukzessive von H+H auf die neuen Rechner umgezogen. Die alte Hardware konnte abgeschaltet werden. Außerdem wurden zwei virtuelle VMWare Maschinen zur Installation künftiger CDROM Datenbanken erstellt. Durch die Nutzung von Snaphots unter VMWare konnte erreicht werden, daß die Installation von weiteren CDROM Datenbanken deutlich vereinfacht wurde.

44 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)

1.10.2 Rosetta Ende 2009 hat sich die Bayerische Staatsbibliothek für das Produkt "Rosetta-Digital Preservation Sys- tem" der Firma ExLibris zur Verwaltung der digitalen Langzeitarchive entschieden. Das LRZ ist hier in vieler Hinsicht strategischer Partner: Es stellt nicht nur die Server- und Archivtechnik, sondern wird voraussichtlich auch durch den Betrieb der Technik des Bibliothksverbundes Bayern künftig mit dem Be- trieb von weiteren Instanzen der Software für die anderen Mitgliedsbibliotheken betraut werden. Für die Projektphase wurde eine Schulungsumgebung unter VMWare bereitgestellt. Außerdem wurden VMWare Maschinen für die „Worker-Server“ der Test- und Produktivumgebung installiert. Für die künf- tige Produktivumgebung wurde auch ein Oracle Datenbankcluster auf zwei physischen Rechnern installiert.

Jahresbericht 2010 des Leibniz-Rechenzentrums 45

2 Entwicklungen und Tätigkeiten im Bereich der Hochleistungs- systeme (HLS)

2.1 Entwicklung in der Datenhaltung

2.1.1 Überblick

Die Architektur der Speichersysteme gliedert sich im Wesentlichen in zwei Bereiche, • den Bereich der Massenspeicher der Archiv- und Backupsysteme mit ihren Bandbibliotheken (Abschnitt 2.1.2), auf die sich unter anderem die Langzeitarchivierung (Abschnitt 2.1.3) ab- stützt, • und in den Bereich der Onlinespeicher (Abschnitt 2.1.4), bei denen wiederum zwischen NAS (Network Attached Storage)- und SAN (Storage Area Network)-basiertem Datenspeicher un- terschieden wird. Für Sicherungssysteme zweiter Ordnung sowie für die Archivierung von großen Datenmengen sind Bän- der als Datenträger unverzichtbar. Der Umfang der in den Bandbibliotheken des LRZ gespeicherten Da- ten wuchs im Jahr 2010 von 9.000 Terabyte auf 14.700 Terabyte an. Um den Zuwachs zu bewältigen wurden in erheblichem Umfang neue Kassetten beschafft und ein weiteres Archiv- und Backupsystem bestehend aus einer Bandbibliothek, Plattenspeichern, Servern und Netzinfrastruktur wurde im Daten- und Archivraum installiert. Durch das neue System wurde ein technisch veraltetes System aus dem Jahre 2003 abgelöst. Eine zusätzliche große Herausforderung in diesem Umfeld war der Übergang auf ein neues Software- Release und der dadurch bedingte grundlegende Wechsel der Datenbank-Architektur. Die Migration von 8 Milliarden Datenbankeinträgen zog sich über mehrere Monate und konnte im Herbst erfolgreich abgeschlossen werden. Die Zusammenarbeit mit der Bayerischen Staatsbibliothek wurde weiter ausgebaut. Dabei fungiert das LRZ als IT Service Provider in den Bereichen Serverhosting, Clusterhousing, Storagehousing einerseits und als Projekt- und Kooperationspartner in verschiedenen Projekten (BABS2, BSB-Google, Rosetta) andererseits. Nicht zuletzt bedingt durch die Vorarbeiten zu „Rosetta“, einem Projekt mit sehr ambitioniertem Zeitplan, für das in erheblichem Maß Speicherplatz benötigt wird, wurde sehr kurzfristig die Ersetzung des alten Speichersystems der BSB notwendig und auch erfolgreich umgesetzt. Die Bayerische Staatsbibliothek verfügt nun über 500 Terabyte Onlinespeicher am LRZ, der von verschiedenen Arbeitsgruppen und Pro- jekten genutzt wird. Dieser Speicher ist auch Ausgangspunkt für die Übertragung der Daten ins Langzeit- archiv des LRZ. Am LRZ selbst und an den Kommissionen der Bayerischen Akademie der Wissenschaften wird gemeinsam nutzbarer, hoch verfügbarer und optimal gesicherter Speicher auf Basis der NAS-Technologie eingesetzt. Dieser Dienst steht als Grundversorgungsangebot auch Mitarbeitern und Studierenden der TU Mün- chen und der LMU zur Verfügung und ersetzt dort immer häufiger lokale Lösungen. Die 2008 installierten NAS-Systeme wurden 2010 deutlich erweitert. Hinzu kamen weitere hochverfüg- bare Speichersysteme, die primär innerhalb der virtuellen Serverumgebung des LRZ genutzt werden. Insgesamt ist der zur Verfügung stehende Onlinespeicherplatz auf 2.000 Terabyte brutto angewachsen. Zusammen mit dem SAN-Speicherplatz beträgt die Bruttokapazität der Plattenspeicher 3.500 Terabyte verteilt auf etwas weniger als 5.000 Festplatten.

2.1.2 Archiv- und Backupsystem

2.1.2.1 Konfiguration Das Archiv- und Backupsystem des LRZ besteht aus zwei großen Systemen mit Bandrobotern: einem Hochleistungssystem HABS, das Anfang 2006 installiert und Ende 2007 und 2010 erweitert wurde, und einem System mit LTO-Bandlaufwerken in mehreren Bibliotheken (LABS), das 2010 neu installiert wur-

46 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS) de. Aus Gründen der Ausfallsicherheit befinden sich die Komponenten der beiden Systeme in getrennten Speichernetzen. Softwareseitig wird die gesamte Architektur mit dem Tivoli Storage Manager von IBM betrieben.

Archive and Backup System, Dec 2010 IBM SUN Brocade 10 GBit Ethernet

8 TSM Servers 8 TSM Servers 3 TSM Servers 3 TSM Servers 3 TSM Servers 3 machines 12 machines

TSM TSM IBM X3850x5 TSM TSM TSM TSM SUNFire 4270 TSM

SAN SAN Brocade 5400

Brocade 5400 Brocade Brocade Disk Cache Disk Cache Silkworm Silkworm Brocade 5400 4800 4800 SUN 6780 SUN FLX380 Brocade 5400 280 TB 520 TB

Library SUN SL8500 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 16 tape devices IBM LTO4 8 tape devices IBM LTO5 6,500 slots 6,500 slots

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

Abbildung 9: Überblick Archiv- und Backupsysteme

Die theoretische Gesamtkapazität der Systeme liegt bei 27 PB, die Peak-I/O-Leistung liegt bei 22 TB pro Stunde. Die wesentlichen Komponenten des Systems sind: • 16 Rechner (Vorwiegend Intel Nehalem EP und EX) • 4 Fibre Channel Switches (8 Gbit) und 2 Fibre Channel Direktoren (4 u. 8 Gbit) • 14 Storage Server mit insgesamt 800 TB verteilt auf 2176 Disks • 3 Tape Libraries mit insgesamt 21.500 Slots • 76 Tape Laufwerke (LTO-4, LTO-5, T10K) Abbildung 10 und Abbildung 11 zeigen die beiden Teil-Konfigurationen des LABS bzw. HABS im Detail. Der Name Hochleistungsarchiv HABS ist insofern irreführend, als durch die jüngsten Aufrüstungen am LABS dieses System einen höhere Leistung und Kapazität vorweisen kann als das HABS.

2.1.2.2 Veränderungen im Bereich Speichersysteme

2.1.2.2.1 Stilllegung eines veralteten Systems Die LTO-Technologie (LTO steht für linear tape open) hat sich in den vergangenen zehn Jahren nicht zuletzt wegen des offenen Standards zum Marktführer im Midrange-Bereich entwickelt. Am LRZ wird die Technologie beginnend mit LTO2 seit 2003 eingesetzt. Die Modellreihe ist zwischenzeitlich bei LTO5 angelangt. LTO2 entspricht weder leistungsmäßig noch kapazitiv länger dem Stand der Technik. Im Laufe des Jahres 2010 wurden sämtliche Daten von 11.000 LTO2-Bändern auf LTO4-Bänder kopiert. 40 LTO2-Bandlaufwerke wurden außer Betrieb genommen. Die älteste Bandbibliothek, die schon in der Innenstadt betrieben wurde und den Umzug nach Garching im Jahr 2006 mitmachte, wurde stillgelegt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 47

LTO Archive and Backup System 2010

Cur. tape capacity: 6.297 TB, 5.500 LTO-4 cartridges + 3795 LTO-5 cartridges Max. tape capacity: 17.250 TB, 11.500 LTO-5 cartridges Tape devices: 26 x LTO4 + 24 LTO5 drives Disk devices: 192 TB FC-AL, 262 TB SATA, 65 TB SAS

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

24 x 10 Gbit Ethernet

9 x Sun Fire X4270 3 x Sun Fire X4270 Pentium 4 2 x INTEL X5560 2.8 GHz Pentium 4 2 x INTEL X5560 2.8 GHz Pentium 4 Pentium 4 Pentium 4 72 GB Memory 16 GB Memory PentiumSn 4 Sn SunSSn 1Fire X4270Sn PentiumSn 4 Sn 4 x FC 8 Gbit Sn 4 x FC 8 Gbit PentiumSn 4 Sn Mgmt7 . Server PentiumSn 4 Sn 2 x 10 GbE (Failover) 1 XEON x 4 Core 2 x 10 GbE (Failover) PentiumSn 4 Sn Sn Sn SunSSn 1Fire X4270Sn Sn SLES 11 SLES 11 Worker7 Server 2 XEON x 4 Core TSM Server 6.2 TSM Server 6.2

48 x 8 Gbit FC

Storage Area Network

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

26 x 4 Gbit FC 56 x 8 Gbit FC 24 x 8 Gbit FC

5.000 slots total capacity: 7.500 TB SUN 6780 SUN 6780 FC-AL 65 TB FC-AL 65 TB IBM TS 3500 tape library 6.500 slots total SATA 87 TB SATA 87 TB 10 x LTO-4 + 8 x LTO-5 capacity: 9.750 TB

SUN 6780 IBM DS3500 FC-AL 61 TB SAS 65 TB SUN SL8500 tape library SATA 87 TB 16 x LTO-4 + 16 x LTO-5 Max library capacity: 17.250 TB uncompressed Cur. library capacity: 6.297 TB uncompressed 1028 disks, total capacity: 519 TB

Abbildung 10: LTO-Archiv-und Backupsystem LABS Ende 2010

48 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

High Performance Archive and Backup System 2010

Cur. tape capacity: 9.300 TB, 9.300 T10K cartridges Max. tape capacity: 10.000 TB, 10.000 T10K cartridges Tape devices: 26 x T10K-B Disk capacity: 280 TB FC-AL

National Munich Scientific Linux Compute Network Supercomputer Cluster HLRBII

Router MWN

10 Gbit

10GE-Switch Cisco 6509 HP E6600-24XG Switch 20 x 10 GbE Ports 24 x 10 GbE Ports

2 x 10 Gbit Ethernet HPC 9 x 10 Gbit Ethernet special 1 x 10 Gbit Ethernet HPC special

3 x IBM X3850 X5 1 x Sun Fire X4200 M2 4 x Intel Xeon X7550 2.0 GHz 2 x OPTERON Mgmt. Server 128 GB Memory DualCore 2.6 GHz Pentium 4 8 x FC 8 Gbit OPTERON Pentium 4 16 GB Memory WorkerOPTERONS1 Server 4 x 10 GbE (3 x trunk, 1 x HPC special) 2 x 2 core S1 Sn 4 x FC 4 Gbit XEON27 x X 27550 coreSn 7 1 x 10 GbE 4 x 8 Core SLES 11 TSM Server 6.2 SLES 11 TSM Server 6.2

4 x 4 Gbit FC 24 x 8 Gbit FC

13 x 2 Gbit FC Storage Area Network 13 x NAS Filer FC-Direktor FC-Direktor 96 Port 4Gb + 16 Port 8Gb 96 Port 4Gb + 16 Port 8Gb

26 x 4 Gbit FC 80 x 4 Gbit FC

SUN 6540 STK 6540 STK FLX380 STK FLX380 FC-AL 30 TB FC-AL TB FC-AL 25 TB FC-AL 25 TB

STK SL8500 tape library 26 FC tape drives Titanium B Max library capacity: uncompressed 10.000 TB SGI IS4500 SGI IS4500 SGI IS4500 SGI IS4500 Cur. library capacity: uncompressed 9.300 TB FC-AL 28 TB FC-AL 28 TB FC-AL 28 TB FC-AL 28 TB

SGI IS4500 SGI IS4500 FC-AL 28 TB FC-AL 28 TB 1148 disks total capacity: 280 TB

Abbildung 11: Hochleistungsarchiv- und Backupsystem HABS Ende 2010

Jahresbericht 2010 des Leibniz-Rechenzentrums 49

2.1.2.2.2 Beschaffung eines neuen Systems und Modernisierung Bereits 2009 wurde als Ersatz für das 2010 außer Betrieb genommene Archiv ein neues System im Rah- men einer Ausschreibung erworben. Dieses System wurde 2010 in zwei Phasen installiert und in den Produktionsbetrieb übergeführt. In der ersten Phase im Frühjahr wurden eine weitere Bandbibliothek mit 6.500 Stellplätzen, sowie Plattenspeicher und eine Serverfarm im Daten- und Archivraum aufgestellt. Die Bibliothek wurde mit 16 LTO4-Laufwerken ausgerüstet. Zum Ausschreibungszeitpunkt war LTO5 noch nicht verfügbar. In der zweiten Phase wurde die Bibliothek dann im vierten Quartal um 16 LTO5- Bandlaufwerke erweitert. LTO5-Laufwerke sind deutlich schneller als LTO4-Laufwerke und fassen die doppelte Datenmenge (800 GB). Die Rechner und auch andere Komponenten des Hochleistungsarchiv- und Backupsystems HABS aus dem Jahr 2006 wurden 2010 gegen neuere, leistungsstärkere Maschinen ausgetauscht. Dazu mussten die TSM-Serverinstanzen, die auf den Servern liefen, hardware- und betriebsystemseitig auf die neuen Sys- teme migriert werden. Ende 2010 wurde dann noch eine der Bandbibliotheken von IBM um 8 LTO5-Laufwerke aufgerüstet. In dieser Bibliothek wurden bis 2009 20 LTO2-Laufwerke betrieben. Diese wurden sukzessive durch LTO4- Laufwerke ersetzt, sodass nun in der Bibliothek ein Mischbetrieb zwischen LTO4 und LTO5 gefahren wird. Grundsätzlich haben die robotergestützten Bandbibliotheken eine deutlich längere Standzeit als die Bandlaufwerke selbst, bei denen sich die Technologie rasant weiterentwickelt.

2.1.2.2.3 Releasewechsel auf TSM Version 6 Die Software, mit der die Archiv- und Backupsysteme betrieben werden, wird mindestens einmal im Jahr auf allen Systemen aktualisiert. In der Regel sind für diese Releasewechsel nur kleinere Anpassungsarbei- ten und kurze Betriebsunterbrechungen notwendig. Der Upgrade von TSM 5 auf TSM 6 war anders. Kernstück einer jeden TSM-Serverinstanz ist die interne Datenbank, in der verzeichnet ist, welche Datei auf welchem Band in welcher Version zu welchem Zeitpunkt gespeichert wurde. In den TSM- Datenbanken liegen Informationen dieser Art zu 8 Milliarden Dateien. Mit TSM 6 wurde die proprietäre interne Datenbank durch die Datenbank DB2 ersetzt. Der Wechsel machte umfangreiche Anpassungsar- beiten sowie eine Konvertierung der Datenbanken, die jeweils mehrere Tage dauerte, auf das neue Format notwendig und zog sich über einige Monate.

2.1.2.2.4 Synchronisierung Kunden-DB mit zentralem Verzeichnisdienst Die in den Archiven gespeicherten Daten werden bestimmten Personen und Personengruppen bzw. Ein- richtungen zugeordnet. Die Pflege der Kontaktdaten der über 1100 Ansprechpartner auf Kundenseite ist eine ebenso wichtige wie zeitraubende Aufgabe beim Betrieb des Archiv- und Backupsystems. Die Fluk- tuation im Hochschulbereich ist sehr hoch, Ansprechpartner wechseln häufig. Bisher wurden die personenbezogenen Daten in einem eigenen, unabhängigen Datenbanksystem mit Webschnittstelle (DATWeb) verwaltet. Im Frühjahr 2010 wurden die Kontaktdaten mit dem zentralen Verzeichnisdienst des LRZ syn- chronisiert. Personenbezogenen Daten werden seitdem nur noch zentral gehalten. Dies erleichtert die Verwaltung der Kundendaten erheblich. Trotzdem erfordert die Pflege der Kontaktdaten auch weiterhin viel Aufmerksamkeit. Nur durch ständigen Kontakt mit den Kunden kann erreicht werden, dass sich die Archive nicht zu einem „Datenfriedhof“ entwickeln.

2.1.2.3 Statistik

Ende 2010 waren in den drei Libraries 14.700 Terabyte, verteilt auf 8 Milliarden Dateien gespeichert. Täglich wurden auf die Systeme durchschnittlich 40 Terabyte neu geschrieben, zu Spitzenzeiten mit einer Geschwindigkeit von 6 GB/Sek. Die Daten stammten von 6.800 Servern des MWN aus 430 Einrichtungen der Münchner Hochschulen.

Im Vergleich zum Vorjahr sind Last und Datenmenge erwartungsgemäß weiter gestiegen. Der Bestand an genutzten Kassetten in den drei Libraries lag Ende 2010 trotz Zukauf von weiteren 5.000 Stück mit 14.000 um 5.000 Stück niedriger als im Vorjahr (2009: 19.000). Die Differenz erklärt sich durch die Au-

50 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

ßerbetriebnahme von 11.000 LTO2-Kassetten. Die Gesamtanzahl der Kassetten ist nur bedingt als Indika- tor 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. 2010 wurden 1.260 Nodes neu registriert und 550 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 sinnvollen Umgang mit den vom LRZ zur Verfügung gestellten – für sie kostenlosen – Ressourcen anzuhalten. Ein eigens für diesen Zweck bereitgestellter Server erlaubt es den Kunden, sich direkt umfassend über den eigenen Datenbestand zu informieren. Gleichzeitig werden die Nutzer in regelmäßigen Abständen von diesem Server über die von ihnen verbrauchten Speicherressourcen via E-Mail informiert. Integriert sind Werkzeuge, die der betrieblichen Überwachung und Analyse der Systeme dienen. Nutzer mit besonders auffälligem Datenprofil werden direkt angesprochen. Alle Kontaktdaten werden zusätzlich regelmäßig auf ihre Aktualität überprüft. Entsprechend den Benut- zungsrichtlinien werden Daten, zu denen sich keine Ansprechpartner mehr ermitteln lassen, nach Ablauf einer festgelegten Frist gelöscht. Zur Erhöhung der Datensicherheit spiegelt das LRZ seine Archivdaten an das Rechenzentrum der Max- Planck-Gesellschaft in Garching (3,3 Petabyte) und umgekehrt (5,8 Petabyte). Den Zuwachs von Speicherbelegung und Dateneingang im Laufe des Jahres 2010 zeigen Abbildung 12 und Abbildung 13.

1.400.000 Backup 1.200.000 Archiv

1.000.000

800.000

600.000

400.000

200.000

0 Jan Feb Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Abbildung 12: Datenverkehr (Gigabytes/Monat)

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. Datensicherungen finden regelmäßig statt. Back- updaten werden dagegen häufig ins System geschrieben und die veralteten Daten werden automatisch aus dem Bestand gelöscht. Durch diese Dynamik erklärt sich die im Vergleich zur Archivierung deutlich hö- here Dateneingangsrate.

Jahresbericht 2010 des Leibniz-Rechenzentrums 51

14000

12000

10000

8000

6000

Backup 4000 Archiv

2000

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

Abbildung 13: Datenumfang in Terabytes

Die Entwicklung der letzten 15 Jahre zeigt Abbildung 14. Das Diagramm zeigt ein kontinuierliches expo- nentielles Wachstum des Datenbestands über die Jahre hinweg.

100.000.000 14.090.000 9.475.000

10.000.000 5.300.000 2.810.000 1.700.000 950.000 650.000

1.000.000 340.000 220.000 120.000 84.000

100.000 62.000 31.000 12.000 10.000 Speicherbelegung in TB in Speicherbelegung 1.000

1.000 500

100 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

Abbildung 14: Speicherbelegung 1995-2010

52 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

2.1.3 Langzeitarchivierung

2.1.3.1 Das LRZ als Service-Provider für digitale Langzeitarchivierung Veröffentlichungen in digitaler Form nehmen im Wissenschaftsbetrieb wie auch im gesellschaftlichen Leben einen immer höheren Stellenwert ein. Oft wird, wie z. B. bei Dissertationen und bei amtlichen Publikationen, auf ein gedrucktes Pendant ganz verzichtet. Während die Digitalisierung für die Nutzer den Zugang und den Umgang mit der Information beschleunigt und insgesamt erleichtert, entstehen aus organisatorischer, rechtlicher und technischer Sicht neue Herausforderungen. Die Objekte sollen nicht nur verwaltet und gespeichert, sondern auch langfristig zugänglich gemacht werden. Diese Aufgabe wird erschwert durch den raschen technologischen Wandel im Bereich der Hard- und Software und der 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), der BSB-Google Partnerschaft und der 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 Langzeitar- chivierung, das Bereitstellen von Onlinespeicher, 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 Mana- ger (TSM). TSM verfügt über alle wesentlichen Funktionalitäten, die für Langzeitarchivsysteme Voraus- setzung sind. Das Gesamtsystem deckt damit alle wichtigen Bereiche eines langfristig funktionierenden Archivs ab und folgt dem allgemeinen „Open Archival Information Systems“-Referenzmodell (OAIS). Weitere Details über die hier aufgeführten Langzeitarchivierungsprojekte können über die LRZ- Homepage im Bereich Projekte (http://www.lrz.de/projekte/langzeitarchivierung) gefunden werden. Abbildung 15 und Abbildung 16 zeigen die Entwicklung der Anzahl der Archivobjekte und des Datenvo- lumens des Langzeitarchivs von Januar 2005 bis Januar 2011. Der starke Anstieg der Dateianzahl ab März 2009 ist durch den Produktivbeginn der Archivierung der Google-Digitalisate zu erklären. Bisher wurden von der BSB mehr als 560 Millionen Objekte mit einem Datenvolumen von mehr als 290 TByte am LRZ archiviert. Der Datenzuwachs im Jahr 2010 betrug ca. 260 Mio. Dateien mit einem Volumen von 90 TByte. In Abbildung 16 ist dieser Anstieg weniger auffällig, da die Größe der einzelnen Google- Digitalisate im Vergleich zu den übrigen Digitalisaten eher gering ist. Die aus Sicherheitsgründen erstell- te Zweitkopie auf einem weiteren Magnetband verdoppelt in der Praxis die Objektanzahl und das Daten- volumen. Sie ist in den Diagrammen nicht berücksichtigt.

Abbildung 15: Objektanzahl im LRZ-Archiv

Jahresbericht 2010 des Leibniz-Rechenzentrums 53

Abbildung 16: Datenvolumen im LRZ-Archiv

Die gespeicherten Daten werden auf Systemen aufbereitet, archiviert und als Webpräsenz bereitgestellt, die zum großen Teil auf der virtuellen Serverplattform des LRZ betrieben werden. Zu diesen Systemen gehören unter anderem die Verkündungsplattform Bayern, der Webserver der Bayerischen Landesbiblio- thek oder ein Server, der die Volltextindizierung der Digitalisate steuert, um nur einige Beispiele zu nennen. Die Anzahl dieser am LRZ für die Staatsbibliothek gehosteten virtuellen Linux-Server ist im Jahr 2010 von 13 auf 27 angewachsen.

2.1.3.2 Projekt BABS2 Start für das DFG-geförderte Projekt BABS2 war Oktober 2008. Das Projekt wurde am 20.01.2011 mit einem sehr gut besuchtem Workshop mit dem Thema „Langzeitarchivierung von Retrodigitalisaten: Handlungsfelder und Praxis“ erfolgreich abgeschlossen. Das rege Interesse von über 80 Teilnehmern am Workshop zeigt die Relevanz der im BABS2 behandelten Thematiken für die Praxis. Ein Ziel von BABS2 war der prototypische Ausbau und die Evaluierung eines vertrauenswürdigen und skalierbaren digitalen Langzeitarchives. Die Entwicklungen der letzten Jahre haben gezeigt, dass die Zuwächse an digitalen Daten, die der Lang- zeitarchivierung zugeführt werden, schwer abschätzbar sind. Dies zeigt sich sehr deutlich im Bereich der digitalen Sammlungen der BSB, wo exorbitante Steigerungen zu verzeichnen sind, und alle Prognosen früherer Jahre immer wieder nach oben korrigiert werden mussten. Als Hauptdatenlieferant sind die Google-Digitalisate anzusehen. Auch entsteht durch die anlaufende Pflichtablieferung elektronischer Publikationen eine nur schwer abschätzbare Menge weiterer Daten. In 2010 wuchs das Datenvolumen von 194 TB auf 290 TB und die Archivobjektanzahl von 305 Mio. auf 560 Mio. Dateien. Für die wichtige Frage nach der Skalierbarkeit bezüglich Datenvolumen und insbesondere bezüglich der Anzahl der archivierten Dateien eines digitalen Langzeitarchivs wurden im Projekt BABS2 Lösungsansätze gesucht. Die Ergebnisse aus den umfangreichen Skalierungstests flossen in das umgesetzte Konzept für ein ska- lierbares Langzeitarchivierungssystem für die Massendigitalisierung ein und führten zur Realisierung einer erweiterbaren Speicherschicht bestehend aus einem Onlinespeicher (Festplatten) und einem Archiv- und Backupsystem mit Magnetbändern als Speichermedien. Als Onlinespeicher wird ein NAS-System (Network Attached Storage) verwendet, das durch zwei getrennte Speicher-Controller (Filer-Köpfe) redundant aufgebaut ist, und den Ausfall einzelner Komponenten ohne Betriebsunterbrechung abfangen kann. Da sehr große Speicherbereiche im Petabyte-Bereich nicht zu realisieren sind, werden diese großen Bereiche aus vielen kleinen Speicherbereichen (so genannten Volumes) mit einer Größe von vier bis sechs Terabyte zusammengesetzt. Ähnliches gilt auch bei der Datensicherung. Die Sicherung (Backup oder Archivierung) sehr großer Speicherbereiche ist nicht zu empfehlen, da gerade hier an das Wiederein- spielen der Sicherung in einem Desaster Fall gedacht werden muss, was viel zu lange dauern würde. Des- halb wurde auch innerhalb des Backup- und Archivsystems durch so genannte TSM-Nodes eine zu den

54 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Volumes analoge Organisation umgesetzt. Abbildung 17 zeigt eine Detailansicht der skalierbaren Spei- cher- und Archivumgebung.

Abbildung 17: Aufbau einer skalierbaren Archivierungskomponente

2.1.3.3 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 Entschei- dung wurde auch dadurch beeinflusst, dass das bislang verwendete Systeme Digitool der Firma Exlibris nicht mehr weiterentwickelt wird. Eine wesentliche Anforderung an das neue Langzeitarchivsystem Ro- setta war der Anspruch, dass pro Tag mindestens 1.000 Bücher in das System eingefügt werden können. Mittelfristig ist geplant, den bisher archivierten Datenbestand (290 TB; 560 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 ganz erheblich von 137 TB auf 586 TB erweitert. Das LRZ betreibt für die BSB die Komponenten des Langzeitarchivsystem Rosetta (virtuelle Server, Onlinespeicher und Archivspeicher).

2.1.3.4 Projekt BSB-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 zunächst drei virtuelle Server bereit, die sich um den Download, die Verarbeitung, Archivierung und Bereitstellung der Daten im Internet kümmern. Die Originaldateien, die die BSB von Google erhält, werden im Archiv- und Backupsystem des LRZ abgelegt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 55

Abbildung 18: Rosetta-Speicherarchitektur Die Dateien, die im Internet angeboten werden, werden am LRZ auf einem NAS-System gehostet. Die Umwandlung aller originalen Bilddateien in jeweils zwei Bilddateien mit niedriger Auflösung geschieht am LRZ auf dem Linuxcluster. Schematisch dargestellt ist die Infrastruktur sowie der Workflow in Ab- bildung 19:

Abbildung 19: Workflow im Google Projekt

56 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Ende 2008 wurden von Google die ersten Digitalisate bereitgestellt. Bis Ende 2010 wurden rund 210.000 Bücher heruntergeladen und verarbeitet, der Bestand an Archivdaten im Google-Projekt ist so bis Ende 2010 auf fast 90 TB angewachsen:

100 90 80 70 60 50 40 30 20 10 0 Juli Juli Mai Mai Juni Juni April April März März August August Februar Februar Oktober Oktober Januar '09 Januar '10 Januar Dezember Dezember November November September September Abbildung 20: Archivierte Daten in Terabyte

Im Oktober 2010 wurden auch die Google-Volumes unterbrechungsfrei auf das neue NAS-System der BSB umgezogen.

2.1.3.5 Münchner Arbeitskreis Langzeitarchivierung Der Münchener Arbeitskreis Langzeitarchivierung ist auf Initiative der Bayerischen Staatsbibliothek und der Generaldirektion der Staatlichen Archive Bayerns entstanden und vereint Institutionen aus dem Raum München, die sich aktiv mit der Langzeitarchivierung elektronischer Medien befassen. Der Arbeitskreis bietet die Möglichkeit eines Informations- und Erfahrungsaustausches auf lokaler Ebene und fördert den Transfer von Wissen über Methoden und Techniken. Bei den etwa halbjährlich stattfindenden Treffen an wechselnden Orten werden jeweils andere Themenschwerpunkte gesetzt. Ein ausgewähltes Thema war „Langzeitarchivierung von Objekten aus Massendigitalisierungsprojekten an der BSB“. Eine detailliertere Beschreibung der einzelnen Projektinhalte im Bereich der Langzeitarchivierung ist auf der LRZ-Homepage (http://www.lrz.de/projekte/langzeitarchivierung) zu finden. Auch wenn im Kontext der Kooperation mit der Bayerischen Staatsbibliothek der größte Teil der Aktivi- täten bezüglich der digitalen Langzeitarchivierung stattfindet, sollte die Zusammenarbeit mit anderen Einrichtungen wie dem Bayerischen Bibliotheksverbund (siehe Abschnitt 1.10) und der Bibliothek der Technischen Universität München, die die Speicher des LRZ für den bibliothekseigenen Medienserver nutzen, nicht unerwähnt bleiben.

2.1.4 Online-Speicher

2.1.4.1 Network Attached Storage

2.1.4.1.1 Homogene NAS-Umgebung Die NAS-Systeme am LRZ haben sich als Speicherplattform aufgrund ihrer Stabilität, Ausfallsicherheit und hohen Datensicherheit durch die Spiegelung auf ein Replikationssystem seit mehreren Jahren be- währt und als strategische Plattform etabliert. Die rapide wachsenden Datenmengen erfordern auch eine

Jahresbericht 2010 des Leibniz-Rechenzentrums 57 gute Skalierbarkeit der eingesetzten Systeme. Abbildung 21 zeigt exemplarisch die Speicherentwicklung wichtiger Systeme im Jahr 2010.

Abbildung 21: Links: NAS-Speicherentwicklung von Juni 2010 bis Januar 2011. Rechts: Speichereinsparung durch Datendeduplizierung

Datendeduplizierung wird für den VMWare-Datenspeicherbereich produktiv eingesetzt. Bei der Datende- duplizierung wird der Datenbestand nach gleichen Blöcken durchsucht. Sind Doubletten vorhanden, wird ein solcher Block nur einmal gespeichert und die doppelten Datenblöcke freigegeben. Die Deduplizierung bringt in diesem Bereich eine Einsparung von über 40% (grüne Kurve). Abbildung 22 zeigt die Konfiguration der Speicherinfrastruktur der Primärspeichersysteme (Produk- tivsysteme) inklusive der Replikations- und Backupsysteme. Zwischen Primär- und Replikationsspeicher- systemen findet mit SnapMirror eine asynchrone Spiegelung der Daten statt, im VMWare-Umfeld, wie unten beschrieben, eine synchrone Spiegelung. Zur weiteren Erhöhung der Datensicherheit werden die Daten von den Replikationssystemen zusätzlich über NDMP (Network Data Management Protocol) auf Magnetbänder gesichert. Die Primär- und Replikationssysteme befinden sich aus Sicherheitsgründen dar- über hinaus in getrennten Brandabschnitten des Rechnergebäudes.

Abbildung 22: Primärsysteme, Replikation und Backup

2.1.4.1.2 Hochverfügbarer Speicher für virtuelle Server Im Frühjahr 2010 wurden Speichersysteme für die neue VMWare-Infrastruktur und für ein Hochleis- tungs-NAS-System für den HPC-Bereich in Betrieb genommen. Voran ging eine Ausschreibung im Vor- jahr.

58 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Um die notwendige hohe Verfügbarkeit bei der Speicherversorgung der neuen VMWare-Infrastruktur zu erreichen, wurde ein System beschafft, das seine Daten synchron spiegelt und zusätzlich repliziert. Als nutzbarer Speicherplatz stehen VMWare seit Frühjahr 2010 ca. 55 TByte zur Verfügung. Für die Replika- tion der Daten wurde das vorhandene Replikationssystem, das 2007 beschafft wurde, entsprechend erweitert. Abbildung 23 zeigt das beschaffte System, das in räumlich getrennten Brandabschnitten aufgebaut und installiert wurde.

Abbildung 23: Hochverfügbares NAS-System für VMWare inkl. Replikation und Backup

2.1.4.1.3 Hochleistungs-NAS-System für HPC-Anwendungen Der Linux-Computecluster des LRZ mit derzeit mehr als 500 Knoten bietet eine Grundversorgung mit HPC-Diensten für Wissenschaftler sowohl für die Münchner Universitäten als auch für andere bayerische Hochschulen. Zusätzlich zu den LRZ-eigenen Rechnern integriert der Linux-Computecluster weiterhin externe Projekte wie D-Grid, das LHC-Tier-2-Zentrum oder die Archivprojekte der Bayerischen Staats- bibliothek, deren Rechner in die Gesamtinfrastruktur eingebunden sind. Da in der Vergangenheit das für den Linux-Computecluster verwendete parallele Dateisystem Lustre häufiger zu Ausfällen geführt hat, wurde entschieden, dieses System zu ersetzen. In der erwähnten Ausschreibung von 2009 wurde ein ska- lierbares und für hohen Durchsatz optimiertes NAS-Speichersystem für die Speicherung von großen Da- tensätzen beschafft und im Frühjahr 2010 in Betrieb genommen. Das Speichersystem hat sich hervorragend in die am LRZ bereits vorhandene NAS-Speicherinfrastruktur integrieren lassen und besteht aus sechs FAS3170 (2 Nodes je Chassis) der Firma Netapp und verfügt über eine nutzbare Kapazität von knapp über 150 TB. Bereits einige Monate später wurde das System auf 300 TB erweitert.

2.1.4.1.4 Speicher für die Wissenschaft Das LRZ bemüht sich um die Bereitstellung von Speicherkapazitäten für alle Studierenden und Mitarbei- ter der Hochschulen. Die derzeitige Infrastruktur für die Speicherung von Dateien und Dokumenten an den Hochschulen ist dezentralisiert und die Qualität der angebotenen Dienstleistungen schwankt in Ab- hängigkeit von der zuständigen Teileinheit, verfügbaren Budgets und den für den Betrieb verantwortlichen Mitarbeitern. Die innerhalb des Projektes IntegraTUM (Projektende September 2009) evaluierten und ausgearbeiteten technischen Grundlagen und Randbedingungen für hochschulweite Bereitstellung

Jahresbericht 2010 des Leibniz-Rechenzentrums 59 von Speicher wurde erfolgreich umgesetzt und seit Mitte 2008 in den Produktivbetrieb überführt. Das LRZ stellt seit dieser Zeit eine einfach zu bedienende, sichere und zentral administrierte Speicherlösung bereit. Durch eine enge Kopplung mit Verzeichnisdiensten verfügen alle Mitarbeiter und Studierenden sowohl über persönlichen Speicherplatz als auch über den Zugang zu Projektablagen. Gemeinsamer Pro- jektspeicherplatz 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 hoch- schulweiter Dienste mit sicherem, hochverfügbarem Speicherplatz. Der zentrale Speicher wird gut angenommen, was die stetig steigende Anzahl der eindeutigen Benutzer-Kennungen (ohne Funktions- und lokale Benutzerkennungen) mit simultanen Zugriffen zeigt (siehe Abbildung 24). Die Zugriffe haben sich innerhalb des Jahres 2010 von ca. 650 auf fast 1.200 simultane Zugriffe fast verdoppelt.

Abbildung 24: Durchschnittliche Anzahl von simultan zugreifenden Kennungen von Jan 10 bis Jan 11

Für das im Dezember 2007 beschaffte Speichersystem, bestehend aus einem Primärspeichersystem (2 x FAS6070) und einem Replikationssystem (FAS6070) wurden Ende 2009 Erweiterungen beschafft. Die Bruttokapazitäten des Primärsystems wurden Anfang 2010 von 68 TByte auf 117 TByte und des Replika- tionssystems von 68 TByte auf 305 TByte (dient auch als Replikationssystem für die VMWare Speicher- infrastruktur) erhöht. Die Infrastruktur des Speichers für die Wissenschaft ist in Abbildung 25 dargestellt.

Abbildung 25: Infrastruktur des Speichers für die Wissenschaft

60 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Der für die Speichersysteme beschaffte innovative Flashspeicher von 4 TB dient als intelligenter Read- Cache. Durch den Einsatz dieser Technologie kann festplattenbasierter Speicher für Random-Read- intensive Workloads wie File-Services optimiert und effizienter genutzt werden, da durch den Cache die Anzahl der Platten-IOs reduziert wird. Somit können günstigere Speichermedien (SATA anstelle FC Plat- ten) eingesetzt werden. Der Einsatz der Flashspeicher hat sich in der Praxis bewährt.

2.1.4.1.5 Speicher für Hochschulstart.de

Das LRZ hat sehr kurzfristig das Hosting für das Projekt Hochschulstart.de übernommen. Für das Projekt wurde im Herbst 2010 ein hochverfügbares Speicher-Cluster (2 x NetApp FAS 3170, 50 TB) mit syn- chroner Spiegelung beschafft und installiert (siehe Abschnitt 2.9).

2.1.4.2 Storage Area Network Wie in den meisten großen Rechenzentren wird auch am LRZ sowohl ein Storage Area Netzwerk (SAN) als Grundlage für einen effizienten Transport von großen Datenmengen, insbesondere für die Datensi- cherung, als auch die NAS-Architektur zur Bereitstellung von Plattenspeicher eingesetzt.

HRR

HRLBII

128AFS Port 8 x NAS 128 Port Home

NSR AFS 2 x NAS 6 x NAS 2 x NAS 2 x NAS 2 x NAS 16AFS Port mass Linux SFS BSB LRZ 16 Port storage HPC

DAR LABS NAS HABS NAS 63 Port 64 Port AFS Mirror 122AFS Port Mirror 64 Port 64 Port SFS 122 Port LRZ

Abbildung 26: SAN/NAS-Topologie

Das ursprüngliche Speichernetz, dessen Anfänge auf das Jahr 2000 zurückgehen, wurde vor einigen Jah- ren in mehrere sogenannte Fabrics aufgeteilt, um so eine höhere Verfügbarkeit gewährleisten zu können. Es werden nun getrennte Fabrics für das Hochleistungsarchiv HABS, das LTO-Archiv- und Backupsys- tem LABS, das verteilte Filesystem AFS und das SAN-Filesystem des Bundeshöchstleistungsrechners betrieben. An die SAN-Fabrics sind die Storageserver, ein Teil der NAS-Filer, alle Bandlaufwerke der Libraries und alle Serversysteme mit hohem Datenverkehr, insbesondere die File- und Backupserver angeschlossen. Abbildung 26 zeigt die Topologie des Netzwerks auf den verschiedenen Stockwerksebenen des Rechner- gebäudes. Gut zu sehen ist die Anbindung der diversen NAS-Filer, über die der sogenannte NDMP- Backup läuft. Die Sicherung über NDMP wird mittelfristig zu Gunsten einer Sicherung über das LAN zurückgefahren, da sich die LAN-Sicherung kostengünstiger umsetzen lässt. Insgesamt gibt es vier getrennte, sogenannte Fabrics im Speichernetz:

Jahresbericht 2010 des Leibniz-Rechenzentrums 61

• Redundantes SAN für das Hochleistungsarchiv: Basis sind zwei FC-Direktoren mit je 96 Ports. Die Direktoren werden als zwei getrennte Fabrics betrieben, um ein Höchstmaß an Ausfallsicherheit (redundant fabric) zu gewährleisten. • SAN für das LTO-Archiv- und Backupsystem: Die Verkabelung der 4 FC-Switches (4x32 Port) des LABS bildet eine Mesh-Struktur. • Redundantes SAN für AFS: Zwei 16 Port FC-Switches sorgen für die redundante Storageanbindung der AFS-Fileserver. • SAN für das CXFS-Filesystem des HLRB II. Als Storageserver werden ausschließlich Plattensysteme eingesetzt, deren Controller von LSI Logic stammen. Da die Geräte im Laufe mehrerer Jahre über verschiedene Ausschreibungen beschafft wurden, sind die Modellnamen trotzdem recht unterschiedlich: • StorageTek D280 Der Storageserver D280 der Firma STK hat zwei 2 Gbit Fibre-Channel-Anschlüsse ins SAN, über die eine aggregierte Leistung von 800 MB/s erreicht wird. Intern sind die Systeme mit 146- Gigabyte-Platten bestückt und ebenfalls über Fibre Channel verkabelt. Die Gesamtkapazität be- trägt 14 Terabyte. Der Plattenplatz der Systeme wird von den AFS-Fileservern und einem MySQL-Server genutzt. • StorageTek Flexline 380 Storageserver Die Storageserver Flx380 der Firma STK haben acht 4 Gbit Fibre-Channel-Anschlüsse ins SAN, über die eine aggregierte Leistung von 1600 MB/s erreicht wird. Intern sind die Systeme sowohl mit 146-Gigabyte-Platten als auch 300-Gigabyte-Platten bestückt und ebenfalls über Fibre Chan- nel verkabelt. Die Gesamtkapazität beträgt 115 Terabyte. Der Plattenplatz der Systeme wird aus- schließlich von den Rechnern der TSM-Serverinstanzen genutzt. Die 146-Gigabyte-Platten werden als Speicher für die TSM-Datenbanken verwendet, die 300-Gigabyte-Platten für die Platten- pools der Server. • SGI IS4500 Die 6 Storageserver vom Typ SGI IS4500 mit insgesamt 170 TB Kapazität kamen im Frühjahr 2010 dazu. Die Geräte wurden vorher am Linux-Computecluster des LRZ für das parallele File- system Lustre genutzt. Lustre wurde wegen seiner Instabilität durch eine NAS-Lösung ersetzt und die SGI-Storageserver wurden vom NSR in den DAR umgezogen und leisten nun als Cache für das Archiv- und Backupsystem gute Dienste. • SUN StorageTek 6780 Zu Beginn des Jahres wurden drei Controllerpärchen mit insgesamt 516 TB Plattenplatz (FC und SATA) für das neue Archiv- und Backupsystem LABS 2.0 installiert.

2.1.4.3 AFS Seit 1992 wurde am LRZ das verteilte Filesystem AFS (Andrew Filesystem) eingesetzt. Es 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- 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 abgeschlossen ist. Nach und nach wurden die Speicherbereiche verschiedener Dienste aus AFS herausgelöst, zunächst der Mailbereich, der am wenigsten mit der speziellen Filesys- temarchitektur von AFS zurechtkam, dann die Daten der Computecluster. 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. Heute liegen noch 800 GB in diesen Homeverzeichnis- sen, etwa ebenso viele Daten sind noch in allgemeinen Verzeichnissen, Webbereichen u.ä. gespeichert. Die Räumung aller Bereiche wurde im Laufe des Jahres weiter vorangetrieben und soll Ende 2011 abgeschlossen sein.

62 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

2.1.5 Daten- und Archivraum

Im Rechnerwürfel des LRZ steht im Augenblick für die Geräte des Archiv- und Backupbereichs nahezu ein gesamtes Stockwerk mit 560 m2 Nutzfläche zur Verfügung, der sogenannte Daten- und Archiv-Raum (DAR, vgl. Abbildung 27). Die Dimensionierung erlaubte bisher eine optimale Aufstellung der Geräte. Die sicherheits-technischen und klimatischen Randbedingungen waren gut geeignet für die langfristige, sichere Aufbewahrung großer Datenmengen.

Abbildung 27: Daten- und Archivraum

Mit einer durchschnittlichen Leistungsaufnahme von unter 50 KW ist der Raum ein Aushängeschild für Green-IT. Der geringe Energiebedarf ist darauf zurückzuführen, dass in diesem Raum primär Bandbiblio- theken, deren Stromverbrauch gemessen an der Speicherkapazität sehr gering ist, stehen. An dem für das Jahr 2012 geplanten Supercomputer der nächsten Generation werden deutlich mehr Daten anfallen als bisher, für die Nearlinespeicher bereitgestellt werden muss. Es wird erwartet, dass für den neuen Supercomputer während seiner Standzeit Speicher in der Größenordnung von 100 PB bereitgestellt werden muss. Ein Grobkonzept für eine mehrstufige Installation der dazu notwendigen Komponenten wurde festgelegt. Der Daten- und Archivraum wird dazu an den Erweiterungsbau angebunden. Umfang- reiche Staubschutzmaßnahmen sind während der Bauarbeiten notwendig, um die Staubbelastung für Kas- setten und Bandlaufwerke so gering wie möglich zu halten. So wird zum Beispiel im Raum ständig ein gewisser Überdruck gegenüber der Außenhaut erzeugt.

2.2 Entwicklungen bei den Rechensystemen

2.2.1 Höchstleistungsrechner in Bayern (HLRB II: SGI Altix 4700)

2.2.1.1 Kennzahlen des Systems

Anzahl SMP Knoten 19 CPUs pro Knoten 512 Anzahl Prozessoren 9728 (=19*512) Peakperformance pro CPU 6.4 GFlop/s* Peakperformance pro Knoten 3.3 TFlop/s** Peakperformance des Gesamtsystems 62.3 TFlop/s** LINPACK 56.5 TFlop/s ** Hauptspeicher pro Knoten 2056 GByte Hauptspeicher des Gesamtsystems 39064 GByte Plattenspeicher 660 TByte Tabelle 20: Kennzahlen des HLRB II: SGI Altix 4700

Jahresbericht 2010 des Leibniz-Rechenzentrums 63

Abbildung 28: SGI Altix 4700 im Höchstleistungsrechnerraum (HRR) des LRZ

2.2.1.2 Betriebliche Aspekte Im Berichtsjahr 2010 konnte die Betriebsstabilität und die Verfügbarkeit durch das Einspielen kleinerer Software Updates durch SGI weiter erhöht werden. Ab November 2010 traten jedoch nach einem Up- grade Performanceprobleme mit dem parallelen Filesystem auf, die im Berichtsjahr nicht gelöst werden konnten. Die Verfügbarkeit des Systems ist in Abbildung 29 dargestellt. Mit ca. 97% Verfügbarkeit kann man bei einem so großen System sehr zufrieden sein. Die Gründe für die Ausfälle sind in Abbildung 30 dargestellt.

Abbildung 29: Übersicht über die Verfügbarkeit (Monatsmittel) des HLRB II (SGI Altix 4700)

64 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

HLRB II unavailability statistics 2010

1.00%

0.90%

0.80%

0.70%

0.60%

0.50%

0.40% unavailability [%] 0.30%

0.20%

0.10%

0.00%

Erläuterungen: DIMM: Memorybausteine CPU: Central Processing Unit Blade: Platine POD: Power On Discovery (Fehler beim Selbsttest nach Power On) Router: Dual- oder Quad-Dense-Router IRU: Individual Rack Unit(Enclosure für bis zu 16 Blades) L1: Kontrolleinheit für eine IRU PS: Power Supply, Netzteil NUMA Link: Fehlerfortpflanzung auf andere Partitionen 10GigE: Netzwerkkarte xpc: Cross Partition Communication Software CXFS or RAID: Plattenfehler OS: Fehler im Betriebssystem user: durch Benutzer verursachte Störung Maintenance: Stillstandszeiten durch (geplante) Wartungen

Abbildung 30: Gründe für Ausfälle des HLRB II

2.2.1.3 Nutzungsübersicht Die Schwerpunkte der Arbeiten in diesem Jahr lagen auf der Stabilisierung des Betriebs und der Optimie- rung und Skalierung von Benutzerprogrammen. Das Angebot an Chemiesoftware und mathematischen Bibliotheken wurde wiederum erweitert. Neue Compilerversionen wurden getestet und installiert. Der HLRB II zeigte ab Frühjahr 2010 einen sehr stabilen Betrieb, wobei vor allem die Anzahl der softwarebe- dingten Ausfälle deutlich zurückgegangen ist. Die abgegebene Rechenzeit (ausgedrückt in Core*Stunden) des HLRB II sind in Abbildung 31 dargestellt. Im Jahr 2010 wurden am HLRB II ca. 68 Mio. Core*Stunden abgegeben. Berücksichtigt man die Service- und die Interaktivknoten nicht, so sind das etwa 83% der maximal abgebbaren Rechenzeit. Der Anstieg der abgegebenen Rechenzeit ist auf mehrere Faktoren zurückzuführen:

Jahresbericht 2010 des Leibniz-Rechenzentrums 65

• Weniger und lokalisiertere Systemabstürze • Weniger und kürzere Wartungen Eine weitere Steigerung der abgegebenen Rechenleistung ist im letzten Betriebsjahr nicht zu erwarten.

Abbildung 31: Abgegebene Rechenzeit des HLRB II (in Core-Stunden)

Abbildung 32: Mittlere Rechenleistung des HLRB II in GFlop/s. 2006 und teilweise 2007 vor Upgrade auf Phase2 Die mittlere Rechenleistung des Systems hat in diesem Jahr einen deutlichen Einbruch erlitten (siehe Abbildung 32). Dies ist zum einen auf die stark gestiegene Anzahl von neuen Projekten zurückzuführen, zum anderen auch darauf, dass auf Grund der Personalknappheit und der Inanspruchnahme der Mitarbei-

66 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS) ter für die SuperMUC-Beschaffung weniger gezielte Optimierungen von Benutzerprogrammen durchge- führt werden konnten. Die Verteilung der abgegebenen Rechenzeit auf einzelne Jobklassen ist in Abbildung 33 dargestellt. Der Schwerpunkt der Nutzung liegt immer noch zwischen 128 und 512 Prozessorkernen. Es sind daher deutlich mehr Anstrengungen notwendig, um die Applikationen für die Nutzung zukünftiger Rechnergenera- tionen mit mehr als einhunderttausend Cores vorzubereiten und zu optimieren.

Abbildung 33: Verteilung der Rechenzeit nach Jobgröße (Legende gibt die Anzahl von Cores an)

Wartezeiten von Jobs 120

100

80 2006 60 2007 40 Wartezeit (h) Wartezeit 2008 20 2009 0 2010

Jobgröße (Cores) Abbildung 34: Wartezeiten der Jobs Die durchschnittlichen Wartezeiten in Abhängigkeit von der Jobgröße sind in Abbildung 34 dargestellt. Zum einen sieht man das Anwachsen der Wartezeiten für kleine bis mittlere Jobs aufgrund der zunehmenden Überbuchung der Maschine, zum anderen auch den Effekt von administrativen Maßnahmen, große Jobs (ab ca. 1024 und darüber) zu bevorzugen und deren Wartezeiten in Grenzen zu halten. Für

Jahresbericht 2010 des Leibniz-Rechenzentrums 67

Jobs größer als 4096 Cores sind solche Maßnahmen aber nicht mehr sinnvoll, da sie zu großen Leerstän- den auf der Maschine führen würden. Für solche Jobs sind lange Wartezeiten unvermeidbar.

2.2.1.4 Nutzungsstatistik Die Anzahl der aktiven Nutzer des HLRB II hat sich im Bereichtszeitraum nur noch leicht erhöht. Die Anzahl von Projekten ist leicht zurückgegangen.

Number of Users and Projects 600 527 514 510 500

389 400

300 Users Projects 196 200 186 180 135 139

100 62

0 2006 2007 2008 2009 2010

Abbildung 35: Entwicklung der Anzahl aktiver Benutzer und Projekte

Die Verteilung der Rechenzeit auf die einzelnen Fachgebiete ist in Tabelle 21 aufgeführt. Die zeitliche Entwicklung in den einzelnen Fächern ist in Abbildung 36 dargestellt. Bemerkenswert für 2010 ist die wachsende Bedeutung der Biowissenschaften. Die Aufschlüsselung der Rechenzeitabgabe nach der Herkunftsregion der am HLRB II durchgeführten Projekte ist in Tabelle 22 angegeben. In dieser Statistik sind neben deutschen Bundesländern auch Staaten aufgeführt, die in DEISA (Distribu- ted European Infrastructure for Supercomputing Applications) aktiv sind. Für die Projekte aus Deutsch- land, die in DEISA und oder von virtuellen Organisationen in D-Grid durchgeführt wurden, kann kein eindeutiges Bundesland zugeordnet werden; sie wurden deshalb in einem eigenen Punkt „Deutschland“ zusammengefasst. Die zehn größten Projekte am HLRB II sind in Tabelle 24 aufgeführt. Kritisch ist im Berichtsjahr zu ver- merken, dass auf Grund der stark gestiegenen Anzahl von neuen Projekten der Anteil der größten Projek- te an der Rechenzeit stark zurückgegangen ist. In früheren Jahren lag dieser bei ca. 10%. Diese Situation ist sehr unbefriedigend und muss mit der Inbetriebnahme des neuen Höchstleistungsrechners beseitigt werden.

68 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Fachgebiet % CPU-h CPU-h Jobs Jobs Computational Fluid Dynamics 31.5% 21337381 18.8% 12864 Astrophysics/Cosmology 14.5% 9836460 8.4% 5703 Chemistry 9.7% 6568450 14.6% 9991 Biophysics/Biology/Bioinformatics 9.5% 6427534 7.2% 4902 Physics - Solid State 7.3% 4914823 9.7% 6630 Physics - High Energy Physics 6.7% 4556832 7.6% 5170 Geophysics 5.9% 4002677 3.8% 2571 Engineering - others 3.3% 2257973 3.6% 2460 Informatics/Computer Sciences 3.0% 2044633 7.2% 4942 Met/Clima/Oceanography 2.8% 1921560 2.8% 1918 Grid Computing 2.3% 1585952 0.4% 276 Support 1.0% 659318 14.6% 9995 Electr. Engineer. 0.9% 618049 0.3% 210 Physics - others 0.8% 520296 0.7% 472 Medicine 0.7% 468998 0.3% 184 Tabelle 21: Verteilung der Rechenzeit nach Fächern am HLRB II im Jahr 2010

Abbildung 36: Zeitliche Entwicklung des Anteiles der Fachgebiete an der Gesamtrechenzeit

Jahresbericht 2010 des Leibniz-Rechenzentrums 69

Land 2006 2007 2008 2009 2010 Gesamt Bayern 49.3% 52.9% 40.5% 45.7% 49.2% 46.6% Baden-Württemberg 8.9% 11.6% 10.1% 16.5% 14.0% 13.2% Brandenburg 3.8% 9.7% 14.7% 14.1% 5.3% 10.8% Nordrhein-Westfalen 8.1% 5.9% 14.3% 6.3% 7.3% 8.6% Thüringen 4.4% 5.6% 6.2% 4.1% 2.9% 4.5% Deutschland (VO) 0.0% 6.9% 3.6% 1.6% 5.6% 4.1% Niedersachsen 4.0% 1.6% 2.4% 2.0% 7.4% 3.6% Berlin 5.6% 0.8% 2.4% 4.5% 4.0% 3.2% Hessen 1.4% 1.1% 2.2% 3.1% 1.8% 2.2% United Kingdom 7.2% 0.8% 0.4% 0.3% 1.3% 0.9% Spanien 0.0% 0.4% 1.0% 0.9% 0.0% 0.6% Italien 0.9% 1.1% 0.7% 0.5% 0.0% 0.5% Niederlande 0.0% 0.6% 1.0% 0.0% 0.1% 0.4% Mecklenburg-Vorpommern 6.3% 0.6% 0.1% 0.0% 0.0% 0.3% Hamburg 0.0% 0.0% 0.0% 0.0% 0.8% 0.2% Sachsen-Anhalt 0.0% 0.3% 0.3% 0.0% 0.0% 0.1% Finnland 0.0% 0.0% 0.0% 0.3% 0.0% 0.1% Tabelle 22: Verteilung der Rechenzeit nach Ländern am HLRB II

Tabelle 23 gibt die institutionelle Zugehörigkeit der Projekte wieder. Institutionelle Zugehörigkeit 2006 2007 2008 2009 2010 Gesamt Universitäten 80.6% 61.9% 62.9% 69.3% 72.7% 67.7% Helmholtz-Gemeinschaft 0.1% 6.9% 8.2% 14.7% 10.7% 10.4% Max-Planck-Gesellschaft 3.7% 18.4% 21.3% 10.6% 8.7% 13.9% Deisa 14.8% 5.7% 6.0% 3.7% 7.0% 5.8% Leibniz-Rechenzentrum 0.7% 2.4% 0.8% 1.7% 0.9% 1.3% D-Grid 0.0% 4.7% 0.8% 0.0% 0.0% 1.0% Fraunhofer Gesellschaft 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% Tabelle 23: Verteilung der Rechenzeit nach institutioneller Zugehörigkeit am HLRB II

Nr. Projekt Principal Investigator/ Project Title % CPU CUM Institution 1 h0351 Krüger/TU München Density Functional Investigations of Complex Chemical 3.9% 3.9% Systems 2 pr47he Shishkina/DLR Göttingen High-resolved numerical simulations of turbulent non- 3.5% 7.4% Oberbeck-Boussinesq Rayleigh-Benard convection 3 h1021 Müller/Uni Jena Dynamics of binary black hole systems 2.8% 10.2% 4 h0983 Stemmer/TU München Large Scale CFD for Complex Flows 2.8% 13.0% 5 h006z Schierholz/DESY Zeuthen Simulation of N_f equal 2+1 lattice QCD at realistic 2.8% 15.8% quark masses 6 h0485 Götz/Uni Erlangen Hyper-Scale waLBerla 2.8% 18.5% 7 h019z Igel/Uni München Computational wave propagation 2.2% 20.7% 8 h0323 Schäfer/Uni Regensburg Dynamical lattice QCD with Ginsparg-Wilson-type 2.2% 22.9% fermions 9 pr95ba Uhlmann/Uni Karlsruhe Interface-resolved direct numerical simulation of 2.1% 25.1% turbulent channel flow with suspended solid particles 10 h1061 Wassen/TU Berlin Investigation of turbulent drag reduction by flexible 2.1% 27.2% lamellas Tabelle 24: Die zehn größten Projekte und ihr Anteil an der Gesamtrechenzeit am HLRB II im Jahr 2010

70 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

2.2.2 Linux-Cluster

2.2.2.1 Weiterentwicklung des Systems Für das Berichtsjahr sind im Wesentlichen Anstrengungen zur Konsolidierung des Betriebs sowie die Inbetriebnahme neuer Hardware zu verzeichnen. Nachdem 2009 das parallele Dateisystem Lustre immer wieder größere Störungen verursacht hatte, wurde Anfang 2010 seine Ablösung durch NAS-basierten Speicher mit erheblich verbesserter Metadatenleistung durchgeführt. Das Dateisystem läuft seitdem praktisch ohne Probleme. Die seit 2003 bzw. 2005 betriebenen Itanium-Systeme vom Typ McKinley und Madison des Clusters wurden im November 2010 außer Betrieb genommen; für diese Systeme waren schon seit einiger Zeit keine Ersatzteile verfügbar und ihr Energieverbrauch war im Verhältnis zur abgegebenen Rechenleistung zu hoch. Ähnliches gilt für die seit 2004 betriebene Altix 3700 mit 128 Madison Prozessorkernen, die ebenfalls außer Betrieb ging. Im Gegenzug sind zwei neue, von SGI gelieferte Systeme nach ausführlicher Hard- und Software- Evaluierung im Rahmen des PRACE Projektes in das Cluster integriert worden: eine auf der Nehalem-EP Architektur basierende SGI ICE mit 64 über Infiniband vernetzten Knoten mit je zwei 4-core Sockeln (also 512 Cores) und einer Spitzenrechenleistung von etwas mehr als 5 TFlop/s sowie ein auf NUMA- link-Technologie basierendes großes Shared-Memory Ultraviolet 1000 System mit 256 Nehalem-EP Cores, 512 GByte Hauptspeicher und einer Spitzenrechenleistung von etwa 2 TFlop/s. Ein weiterer Aus- bau der parallelen Cluster-Kapazität wurde durch die DFG im Sommer 2010 genehmigt und soll nach Abschluss der erforderlichen Beschaffungsverfahren Anfang bzw. Mitte 2011 in Benutzerbetrieb gehen (siehe unten).

2.2.3 Tests und Prototypen Das LRZ wurde von Intel als eines von wenigen Zentren weltweit ausgewählt, um vorab die neue Intel MIC-Architektur zu testen (Many Integrated Cores). Ab Mai stand dem LRZ ein "Knights Ferry"- Prototyp für Tests zur Verfügung, erste Ergebnisse wurden in dem nicht-öffentlichen PRACE-Deliverable "Final Technical Report and Architecture Proposal" dokumentiert. Weiterhin wurden Tests von spezieller Beschleuniger-Hardware, insbesondere von NVIDIA GPGPUs, Analysen zur Performance und Anwendbarkeit neuer Programmiersprachen und -paradigmen für hochparallele Systeme und eine Evaluierung der Programmierumgebung HMPP ("Hybrid Multicore Parallel Programming Workbench“) sowie des PGI Accelerator Compilers, die beide die Programmierung von GPGPUs wesentlich vereinfachen, durchgeführt. Beta-Tests von Intels neuer datenparalleler Program- miersprache "Intel Array Building Blocks (ArBB)“, Mitwirkung an der ausgedehnten Beta-phase für den 12.0 Compiler mit Coarray-Funktionalität sowie die Einladung des LRZ zur Mitwirkung am Intel Soft- ware Customer Advisory Board zeigen, dass das LRZ ein begehrter Partner ist. Arbeiten zur synthetischen Performance-Modellierung der Applikationen runden diesen Arbeitsbereich ab.

2.2.4 Linux MPP Erweiterung Ein Antrag zur Ersetzung der Itanium-Komponenten im Linux-Cluster wurde Anfang 2010 erstellt und nach Jahresmitte genehmigt. Es werden ein großes MPP-System und ein großes Shared Memory System für das Cluster beschafft. Die Beschaffung des MPP-Anteils musste noch 2010 erfolgen, deshalb war es trotz des hohen Arbeitsaufwandes für die SuperMUC-Ausschreibung zusätzlich nötig, für diese Beschaf- fung Unterlagen und Benchmarks zusammenzustellen und die Angebote der Hersteller auszuwerten. Wie auch beim SuperMUC legte das LRZ hierbei großen Wert auf Energieeffizienz und die mögliche Nutzung der Warmwasserkühlung im neuen Rechnerwürfel. Den Zuschlag für die Lieferung von 1824 Infiniband- vernetzten AMD-Cores für das Cluster erhielt die Firma Megware mit ihrem innovativen Warmwasser- Kühlungskonzept. Das neue Cluster soll mit der MPI Software „Parastation“ der Firma Par-Tec betrieben werden; es wird eine deutliche Zunahme der parallelen Job-Größen auf dem Cluster zulassen.

Jahresbericht 2010 des Leibniz-Rechenzentrums 71

2.2.4.1 Nutzungsstatistiken für das Linux-Cluster Kategorie Institution/Fachbereich Anzahl Jobs % Jobs Core-h % Core-h LRZ LRZ 113830 1.39 750217 2.56 BAY Hochschule Ingolstadt (FH) 229 0.00 21983 0.07 BAY Universität Regensburg 113952 1.39 2384465 8.12 BAY Universität Erlangen 59210 0.72 862948 2.94 BAY Universität Würzburg 83612 1.02 382926 1.30 BAY Universität Bayreuth 11162 0.14 913868 3.11 BAY Katholische Universität Eichstätt 11217 0.14 213659 0.73 BAY Universität Augsburg 1582 0.02 53253 0.18 LCG LCG (Large Hadron Collider Computing Grid) 3412774 41.55 5332378 18.17 HLR Fraunhofer ITWM - HPC department 47 0.00 442 0.00 HLR Astrogrid 17314 0.21 149626 0.51 Kör Bayerisches Staatsministerium für Wissenschaft, 703621 8.57 137547 0.47 Forschung und Kunst Kör Hochschulnahe Einrichtungen 399 0.00 36833 0.13 HSM Feinwerk- und Mikrotechnik 4475 0.05 138867 0.47 TUM Maschinenwesen 16846 0.21 2775163 9.46 TUM Chemie 150306 1.83 1641675 5.59 TUM Mathematik 15879 0.19 848987 2.89 TUM Wissenschaftszentrum Weihenstephan 96063 1.17 606210 2.07 TUM Bauingenieur- und Vermessungswesen 755730 9.20 392107 1.34 TUM Elektrotechnik und Informationstechnik 25138 0.31 214941 0.73 TUM Wirtschaftswissenschaften 7457 0.09 111205 0.38 TUM Informatik 385005 4.69 212104 0.72 TUM Zentralbereich 659 0.01 60121 0.20 TUM Medizin 1380 0.02 46363 0.16 LMU Betriebswirtschaft 26 0.00 2517 0.01 LMU Zentrale Einrichtungen und Verwaltung 294 0.00 1659 0.01 LMU Physik 1779629 21.67 8026341 27.35 LMU Chemie und Pharmazie 10010 0.12 1111469 3.79 LMU Geowissenschaften 3139 0.04 786248 2.68 LMU Medizinische Fakultät 33133 0.40 266123 0.91 LMU Biologie 365179 4.45 513331 1.75 LMU Mathematik, Informatik und Statistik 20981 0.26 113530 0.39 LMU Volkswirtschaftliche Fakultät 350 0.00 121032 0.41 Sonstige Sonstige 13059 0.16 119875 0.41 Summe LCG (Large Hadron Collider Computing Grid) 3412774 41.55 5332378 18.17 Summe Technische Universität München 1454463 17.71 6908875 23.54 Summe Ludwigs-Maximilians-Universität 2212748 26.94 10942252 37.28 Summe Sonstige Bayerische Hochschulen 280964 3.42 4833102 16.47 Summe total 8213687 100.00 29350013 100.00 Tabelle 25: Linux-Cluster Nutzung nach institutioneller Zugehörigkeit und Fachgebiet

2.2.5 Remote Visualisierungsserver Die auf dem HLRB II oder dem Linux-Cluster erzeugten Datensätze erreichen inzwischen oftmals eine Größe, die eine Visualisierung auf PCs oder einfachen Workstations nicht mehr gestattet. Der Dienst „Remote-Visualisierung“ wird daher von den Benutzern sehr gut angenommen, was an der auf hohem Niveau liegenden Auslastung der Hardware-Reservierungen abzulesen ist, so dass Anwender bereits tem- porär vom automatischen Reservierungssystem abgewiesen werden mussten. Das Remote- Visualisierungssystem RVS1 für HLRB II Benutzer läuft seit Inbetriebnahme stabil. Die beiden aus D- GRID Mitteln für den Linux-Cluster neu beschafften Remote-Visualisierungs-Server GVS1 und GVS2 liefen Anfang des Jahres recht instabil. Als Ursache wurden BIOS-Probleme gefunden, die verhinderten, dass die Maschinen in der gekauften Vollbestückung (8 CPU-Module und 4 Grafikkarten) korrekt arbeiten konnten. Der Hersteller lieferte deswegen im Juni zwei zusätzliche Server-Gehäuse. Die CPU-Module und Grafikkarten konnten dann auf vier Maschinen verteilt werden, die seither stabil laufen. Insgesamt stehen den Anwendern nun fünf Server (RVS1, GVS1-4) mit zusammen 80 Cores und insgesamt zwölf Hochleistungsgraphikkarten zur Verfügung. Sämtliche Visualisierungs-Server sind auch per Grid- Zertifikat benutzbar. Wegen der hohen Nachfrage nach GPGPU-Programmierung (speziell NVIDIA CU-

72 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

DA) wurde hierfür ein dediziertes CUDA Testsystem angeschafft (1 Workstation mit Intel Nehalem EX, 1 Tesla C1060 Karte und 1 GeForce 9800 Grafikkarte).

2.3 Aktivitäten zur Beschaffung des neuen Petascale-Rechners SuperMUC Nach mehr als einjähriger Vorbereitung konnte die Beschaffung des nächsten (europäischen) Höchstleis- tungsrechners unter dem Dach des Gauß-Zentrums für Supercomputing als Wettbewerblicher Dialog zwischen Februar und Dezember 2010 durchgeführt und zum erfolgreichen Abschluss gebracht werden. Dafür wurden die im letzten Jahr begonnen Arbeiten an den Verdingungsunterlagen und der Bench- marksuite Anfang dieses Jahres abgeschlossen. Nach über zwanzig jeweils ganztägigen Einzelverhand- lungen mit anfänglich fünf Bietern erhielt am Ende das Angebot der Firma IBM den Zuschlag. Ein Mig- rationssystem soll Mitte 2011 in Betrieb gehen, der Hauptteil des SuperMUC genannten Systems soll bis Ende Mai 2012 betriebsbereit sein und über drei PFlop/s Spitzenrechenleistung verfügen. Der gesamte Beschaffungsvorgang ist in Tabelle 26 noch einmal dargestellt. In Anwesenheit von Staatsminister Dr. Wolfgang Heubisch unterzeichneten am 13.12.2010 Prof. Dr. Arndt Bode, Vorsitzender des Direktoriums des Leibniz-Rechenzentrums (LRZ) der Bayerischen Aka- demie der Wissenschaften, und Martin Jetter, Vorsitzender der Geschäftsführung der IBM Deutschland GmbH, den Vertrag hierzu. Damit kommt im Frühjahr 2012 einer der leistungsfähigsten und der wohl effizienteste Rechner der Welt nach Garching. Der „SuperMUC“ genannte Rechner wird mehr als 110.000 Prozessorkerne neuester Bauart der Firma Intel aufweisen und damit eine Leistung von drei Petaflop/s erreichen, das sind drei Billiarden Rechenoperationen pro Sekunde – eine Drei mit 15 Nullen. Eine neuartige, von der Firma IBM in Deutschland entwickelte Hochtemperatur-Flüssigkeitskühlung und eine ausgefeilte Wärmerückgewin- nung sorgen für eine optimale Energieausnutzung. Minister Heubisch betonte bei der Vertragsunterzeich- nung: „Das Leibniz-Rechenzentrum in Garching wird mit dem neuen Höchstleistungsrechner zum Vorrei- ter einer energieoptimierten Computertechnik.“

Abbildung 37: Foto von der Vertragsunterzeichnung für SuperMUC, v.l.n.r.: Staatsminister Dr. Wolfgang Heubisch, Prof. Dr. Arndt Bode, LRZ, Martin Jetter, IBM, Andreas Pflieger, IBM, Prof. Dr. Dietmar Willoweit, Präsident der Bayerischen Akademie der Wissenschaften

Jahresbericht 2010 des Leibniz-Rechenzentrums 73

Vorgang Datum/Vom Bis Markterkundung Feb 09 Dez 09 Informationspapier für Hersteller Mrz 09 Mrz 09 Herstellerbesuche des Direktoriums Mrz 09 Kolloqium für Herstellerfirmen Mai 09 Technische Einzelbesprechungen mit Firmen Jun 09 Dez 09 Sitzung der Kommission für Informatik zur Benennung des Jul 09 Auswahlgremium Hersteller-Konzept für Petascale-Rechner am LRZ Dez 09 Benchmarks (Vorbereitung) Mai 09 Mai 10 Auswahl Benchmarkprogramme Mai 09 Erstellung herstellerfähiger Versionen Mai 09 Dez 09 Eignung auf verschiedenen Architekturen testen Mai 09 Dez 09 Auslieferung der Benchmarksuite an Hersteller Jan 10 Durchführung von Tests durch Hersteller Jan 10 Mai 10 Beschaffungsprozess Dez 09 Dez 10 Verdingungsunterlagen (erste Iteration) erstellen Dez 09 Jan 09 Bestätigung der Verdingungsunterlagen durch Jan 09 Auswahlgremium Wettbewerblicher Dialog Feb 10 Nov 10 Ankündigung Feb 10 Versendung der Vergabeunterlagen Feb 10 Abgabefrist für Teilnahmeanträge (8 Anträge) Feb 10 Prüfung der Teilnahmeanträge Feb 10 Auswahl der Dialogteilnehmer (Bull, CRAY, HP, IBM, SGI) 09.03.2010 Erste Dialogphase (3 Verhandlungsrunden mit 5 Teilnehmern) Mar 10 Jul 10 Schärfung der Leistungsbeschreibung durch LRZ Jun 10 Erstellung der Angebote durch Firmen Jun 10 Jul 10 Auswertung der Angebote Jul 10 Auswahl der Shortlist (2 Bieter: IBM, SGI) 28.07.2010 Zweite Dialogphase (3 Verhandlungsrunden mit 2 Teilneh- Aug 10 Nov 10 mern) Finale Leistungsbeschreibung vom LRZ erstellt Sep 10 endgültige Angebotserstellung durch Firmen Sep 10 Okt 10 Rechnerauswahl Nov 10 Sitzung der Auswahlkommission (Entscheidung für IBM) 10.11.2010 Vertraggestaltung 15.11.2010 13.12.2010 Frist GWB §101a 15.11.2010 20.11.2010 Vertragsgestaltung und -verhandlungen 20.11.2010 12.12.2010 Vertragsunterschrift 13.12.2010 Tabelle 26: Beschaffungsvorgang für den nächsten Höchstleistungsrechner SuperMUC

Mit dem SuperMUC wird die bewährte Linie der auf vollwertigen Prozessoren basierenden, universell einsetzbaren Höchstleistungsrechner am LRZ konsequent fortgesetzt. SuperMUC wird den jetzigen, 2006 in Betrieb genommenen „HLRB II“ ersetzen und erneut den Sprung an die technologische Spitze schaffen. Mit 3 Petaflop/s Spitzenrechenleistung, 320 Terabyte Hauptspeicher und 12 Petabyte Hintergrund- speicher wird SuperMUC zu den leistungsfähigsten Universalrechnern der Welt gehören, wenn er Mitte 2012 in Betrieb geht. Die Architektur des SuperMUC lässt trotz der imposanten Zahl von mehr als 110.000 Prozessorkernen einen stabilen Dauerbetrieb und sehr gute Skalierung erwarten. Über das Gauß Zentrum für Supercompu- ting (GCS) können Wissenschaftler in Bayern, Deutschland und darüber hinaus den neuen Höchstleis- tungsrechner bruchlos und ohne Änderung an den bisherigen Programmierkonzepten nutzen. Über die Infrastruktur PRACE (Partnership for Advanced Computing in Europe) eröffnet SuperMUC weitere neue Möglichkeiten für Wissenschaftler in 21 europäischen Mitgliedsstaaten. Revolutionär ist das neue Kühlkonzept. Die aktiven Komponenten wie z.B. Prozessoren und Memory werden unmittelbar mit Wasser gekühlt, das über vierzig Grad warm sein darf. Diese „Hochtemperatur-

74 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS) flüssigkeitskühlung“ und eine hochinnovative Systemsoftware zur energieeffizienten Leistungssteuerung ermöglichen es, den Anstieg des Energieaufwands und damit der Betriebskosten so gering wie möglich zu halten und darüber hinaus alle LRZ-Gebäude mit der Abwärme des Rechners zu heizen. „SuperMUC“ steht für unerreichte Energieeffizienz im Sinne des Green Computing und für Spitzenleistung in der Re- chenkapazität durch massive Parallelität der universell einsetzbaren Multicore-Prozessoren.

Abbildung 38: Prof. Arndt Bode (LRZ) und Martin Jetter (IBM) mit einem Prototypen für ein Bauteil des SuperMUC. Die Kupferrohre zur Zu- und Abführung der Kühlflüssigkeit sind klar zu erkennen. Die Investitions- und Betriebskosten für fünf bis sechs Jahre einschließlich der Stromkosten für den Su- perMUC werden 83 Mio. Euro betragen, die das Land Bayern und der Bund zur Hälfte finanzieren, ebenso wie die 50 Mio. Euro für die bereits laufende Gebäudeerweiterung des LRZ. Darüber hinaus fördert Bayern weitere begleitende Projekte wie z.B. das Bayerische Kompetenznetz für Wissenschaftlich- Technisches Höchstleistungsrechnen KONWIHR mit seinen mehr als 25 überregionalen Anwendungen. Wissenschaftsminister Dr. Wolfgang Heubisch bezeichnete den SuperMUC als Investition in die Zukunft: „Leistungsfähige Rechner und Software sind heute der Schlüssel für wissenschaftliche und technologische Konkurrenzfähigkeit. Das Leibniz-Rechenzentrum in Garching wird mit dem neuen Höchstleis- tungsrechner zum Vorreiter einer energieoptimierten Computertechnik.“

2.4 Software und User Support im Bereich Hochleistungsrechnen

2.4.1 Software für Linux-Cluster und Höchstleistungsrechner Im Software-Portfolio erfolgten Aktualisierungen und Erweiterungen; aus dem Bereich der Quantenche- mie sind neue Releases von NAMD, CASTEP, Gamess, Gaussian, Molpro, NWChem, Amber, CP2K und VASP sowie zusätzliche Pakete wie Abinit, ACESS oder Schrödinger zu nennen. Im Bereich der Ent- wicklungssoftware sind Verbesserungen bei der Fortran 2003 und OpenMP 3.0 Unterstützung (Intel Compiler) sowie der direktivengesteuerten Programmierung von Beschleunigerkarten (PGI Compiler) und neuere Versionen der Werkzeuge zur Fehlersuche und -behebung (Totalview, Forcheck, Valgrind) eingeführt worden. Die MPI Implementierung der Firma Intel wurde im Hinblick auf die Skalierbarkeit erheblich verbessert und dient auch als Grundlage für eine erste Implementierung des im neuen Fortran 2008 Standard integrierten parallelen PGAS-Programmiermodells „Coarrays“.

Jahresbericht 2010 des Leibniz-Rechenzentrums 75

2.4.2 Supportanfragen Die deutlich gesteigerte Anzahl von Nutzern und der große Job-Durchsatz am HLRB II und am Linux- Cluster haben zu einer weiteren Steigerung von Supportanfragen geführt, die nur mittels des Troubleti- cket-System gezielt abgearbeitet werden können (siehe Tabelle 27). Diese Möglichkeit der Kontaktauf- nahme wurde von den Benutzern sehr gut angenommen und hat die Kontaktaufnahme via Email fast komplett ersetzt. Die deutlich gestiegene Anzahl von Anfragen, teilweise von recht unerfahrenen Benut- zern führt zu einer deutlich gesteigerten Arbeitsbelastung der Mitarbeiter, vor allem, da diese Anfragen unvermittelt in den Arbeitsablauf eindringen. Da die Supportgruppe für den HLRB und das Linux-Cluster der größte Nutzer des Troubleticket-Systems am LRZ ist, hat sie auch als erste das neue Incident Mana- gementsystem IeT ITSM eingeführt.

2008 574 2009 625 2010 838 Tabelle 27: Anzahl Troubletickets im Bereich Hochleistungsrechnen

2.4.3 Einführung des neuen Incidenttools Im September wurde der Pilotbetrieb des neuen ITSM Tools von IeT Solutions im Rahmen des Incident Managements für das Linux-Cluster und kurze Zeit später auch für den HLRB gestartet. Das neue Ser- vicedesk-Tool bietet dem Anwender deutlich mehr Möglichkeiten mit dem LRZ zu interagieren und den Zustand eines Incidents einzusehen. Zahlreiche Probleme und Konfigurationswünsche mussten hierzu vom ITSM Team gelöst werden.

2.4.4 Benutzerverwaltung Die Workflows für Benutzerverwaltung und Antragstellung am Linux-Cluster und HLRB konnten weiter verbessert und automatisiert werden. Durch das am LRZ nun eingeführte Single Identity Management ist jetzt ein leichterer Zugriff auf Benutzerdaten und die Validierung von Benutzern für verschiedene Dienste möglich. So wurden das HLRB- und Linux-Web-Antragsformular neu generiert und bereits vorhandene Informationen können bei der Bearbeitung zur Erleichterung für den Master-User eingeblendet werden.

2.4.5 Kurse und Ausbildung Das Aus- und Weiterbildungsangebot konnte auch im Berichtsjahr erheblich erweitert werden. Der hohe Wissensstand und die Güte der Kurse am LRZ drückt sich auch dadurch aus, dass Dr. Bader aus der Gruppe Hochleistungsrechnen im Fortran-Standardisierungskommittee WG5 mitarbeitet und auf der Su- percomputing-Konferenz in New Orleans zu ersten Mal mit einem Tutorial zum Thema PGAS-Sprachen (Partitioned Global Address Space) vertreten war. Außerdem wurde Herr Bader zu einem Vortrag über PGAS Konzepte in Fortran und UPC am IDRIS in Frankreich eingeladen. Es zeigt sich aber auch, dass das Kursangebot mit der jetzigen Personalkapazität nicht mehr weiter ausgebaut werden kann, obwohl es gerade in der jetzigen Umbruchzeit mit vielen neuen Ansätzen (neuen Programmiersprachen, Multi- und Manycores, GPGPUs) sehr viele Themen zur Ausbildung gäbe. Das LRZ wird hier deshalb versuchen, in Zusammenarbeit mit Firmen und anderen Rechenzentren die Attraktivität seines Kursangebotes weiter aufrecht zu erhalten.

2.4.5.1 Programmiersprachen und Programmentwicklung Großen Zuspruch fanden ein neuer Fortran-Grundlagenkurs sowie die bereits etablierte Fortgeschritte- nenveranstaltung, die jetzt als jeweils einwöchige Blockveranstaltung regelmäßig durchgeführt werden. In Zusammenarbeit mit dem RRZE fand eine einwöchige Einführung in die wissenschaftliche Program- mierung mit C++ statt. Für die inzwischen auch zunehmend im wissenschaftlichen Bereich genutzte Ent- wicklungsumgebung „Eclipse“ gab es eine eintägige Veranstaltung, die in Zukunft durch eine Einführung in die Nutzung dieser Software im Bereich des parallelen Programmierens (Eclipse PTP) ergänzt werden soll. Die Integration von Parallelität in klassischen Programmiersprachen im Rahmen des „Partitioned

76 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Global Address Space“ (PGAS) Konzeptes wurde in einer eintägigen Veranstaltung mit den Themen coarray Fortran (CAF) und unified parallel C (UPC) behandelt. Der Kurs „Eclipse: C/C++ programming (with a slight Fortran touch)“ vermittelte sowohl erste Schritte in Eclipse für C, C++ und FORTRAN als auch im Grid computing, denn in den Übungen wurden Grid Zertifikate (SLCS) und Grid middleware (gsissh-Term mit VNC für remote visualization) für den Zugang verwendet.

2.4.5.2 Parallelisierung und Optimierung Der traditionell jährlich stattfindende Workshop zum parallelen Programmieren und Optimieren (abwech- selnd in München und Erlangen) wurden neu strukturiert, und fortgeschrittene Themen wurden in eine separate Veranstaltung ausgegliedert. Sehr gut besucht war der in Zusammenarbeit von HLRS sowie den Universitäten Kassel und Lübeck am LRZ durchgeführte Workshop zur Programmierung mit MPI, OpenMP und parallelen Bibliotheken sowie angewandter linearer Algebra für iterative Verfahren. Etliche Veranstaltungen wurden auch in Zusammenarbeit mit Firmen durchgeführt, beispielsweise mit Intel eine Schulung zu Multicore und zum neuen parallelen Programmiermodell „Array Building Blocks“. Außer- dem fand eine Reihe von eintägigen Veranstaltungen mit Fokus auf spezielle Tools zur Performance- Analyse und zu Debugging statt; dies erfolgte in Zusammenarbeit mit den Tool-Entwicklern aus dem Forschungszentrum Jülich bzw. der Firma Allinea. Das wachsende Interesse an der Nutzung von Gra- phikkarten zur Beschleunigung von Algorithmen kam in einer hohen Teilnehmerzahl bei einer Veranstal- tung zum Thema GPGPU („General Purpose Graphics Processing Unit“) zum Ausdruck.

2.4.5.3 Fluid-Dynamik Die Community der CFD-Anwender um das Open-Source-Programm OpenFOAM hat sich auf einer vom LRZ organisierten Veranstaltung getroffen und ihre Projekte vorgestellt. OpenFOAM entwickelt sich immer mehr zu einer wichtigen Applikation am LRZ und es werden vom LRZ Anstrengungen unternommen, diese Applikation auf neuartige Architekturen zu portieren.

2.4.5.4 Life Sciences und Visualisierung In Kursen zu Molecular Modelling gab es eine Einführung in die Simulation von Molekülen mit unterschiedlichen Software-Paketen auf dem Supercomputer am LRZ (Maestro, Desmond, VMD, NAMD, Gromacs). Dies beinhaltete auch eine Einführung in die Remote Visualisation Services am LRZ; außer- dem werden Hands-on Sessions mit Beispielanwendungen gegeben. Der Kurs konzentrierte sich auf Bio- moleküle und Ziele der Life-Science-Community. Eine weitere Veranstaltung gab es zum parallelen Pro- grammieren und Visualisierung mit der statistischen Programmierumgebung R. Im Kurs "Wissenschaftli- che 3D-Animation mit Blender" lernten die Kursteilnehmer, selbst hochwertige Filme zur Darstellung ihrer wissenschaftlichen Arbeit zu erstellen. Weiter zu erwähnen sind: Eine allgemeine Einführung in die Nutzung der Cluster- und Visualisierungssysteme am LRZ sowie die Behandlung spezieller Themen aus dem Bereich Visualisierung in Zusammenarbeit mit dem Rechenzentrum der Max-Planck-Gesellschaft.

2.5 Öffentlichkeitsarbeit

2.5.1 Supercomputing Konferenzen in Hamburg und New Orleans Für den Auftritt auf den Supercomputing-Konferenzen ISC10 in Hamburg und SC10 in New Orleans wurde ein neuer Messestand entworfen, dessen herausragende Neuerung ein geteiltes Display mit vier großen HD-Monitoren darstellt. Das Display wird mit Informationen, Filmen, Animation oder Simulatio- nen beschickt, die alle Bereiche des LRZ vorstellen und zudem einen Ausblick auf den Neubau und den SuperMUC bietet. Und natürlich führt auch wieder Frankie (eine vom LRZ für Schulungszwecke weiter- entwickelte virtuelle Figur) durch das LRZ, dabei wird auf dem Display auch ein virtuelles 3D- Laboratorium gezeigt, durch das sich Messebesucher frei bewegen können. In der virtuellen Welt werden die verschiedenen Anwendungsgebiete des Höchstleistungsrechnens anschaulich gezeigt. Auf den Mes- severanstaltungen in Hamburg und New Orleans zeigte das LRZ auch Live-Demonstrationen aus dem Bereich der Molekularen Simulation zu Remote Visualisation und Computational Steering mit einem Force-Feedback System, das aus Komponenten zusammengestellt wurde, die quer über den Atlantik verbunden waren. Das Force-Feedback-System vermittelt dem Anwender einen Eindruck von Kräften, z.B.

Jahresbericht 2010 des Leibniz-Rechenzentrums 77 innerhalb von Molekülen oder mechanischen Strukturen. Als Rechenserver wurde der HLRB II benutzt, die Remote Visualisierung wurde im GVS-Cluster des LRZ berechnet und die 3D-Displayausgabe und die Force-Feedback-Steuerung konnte in New Orleans am Messestand interaktiv von den Messebesu- chern bedient werden.

2.5.2 Wissenschaft im Dialog/Tag der offenen Tür Am Tag der Offenen Tür wurde die im Haus entwickelte 3D-Präsentation "Frankie goes to LRZ", die schon auf der Ars Electronica in Linz 2009 gezeigt wurde, erheblich erweitert und auf der mobilen 3D- Stereo-Projektionsanlage des LRZ vorgeführt. Frankie ist ein kleines „elektronisches Flughörnchen“, das in einer simulierten Welt verschiedene virtuelle Orte besucht, an denen Aktivitäten und Ergebnisse am LRZ, wie zum Beispiel Molekülsimulationen, in unterhaltsamer Weise dargestellt werden. Ein Schüler- praktikant hat diese Simulation noch um Einsichten in den Rechnerwürfel und um ein virtuelles Labor erweitern können. Die Resonanz beim Publikum war hervorragend, was sich auch in einer Veröffentli- chung in der Zeitschrift "Aviso" des Bayerischen Staatministeriums für Wissenschaft und Kunst nieder- geschlagen hat. In diesem Zusammenhang ist auch der Vortrag bei der Vortragsreihe der Sprecher der BAdW zu nennen: „Was Wissenschaftler aus Computerspielen machen (können)“.

2.5.3 Berichtsband Viel Arbeit erforderte die redaktionelle Fertigstellung, die drucktechnische Aufbereitung und Veröffentlichung des 780-seitigen Berichtsbandes "High Performance Computing in Science and Engineering" der die Ergeb- nisse des Ende 2009 durchgeführten "HLRB and KON- WIHR Review Workshops" darstellt: S. Wagner, M. Steinmetz, A. Bode, M. M. Müller (Edi- tors): "High Performance Computing in Science and Engineering, Garching/Munich 2009", Transactions of the Fourth Joint HLRB and KONWIHR Review and Results Workshop 780 p., Hardcover, ISBN 978-3-642- 13871-3, 2010. Dieses Buch stellt ausgewählte Ergebnisse dar, die am gegenwärtigen Höchstleistungsrechner in Bayern erzielt wurden. Die abgedeckten Forschungsbereiche umfassen die Bereiche Informatik, Fluiddynamik, Astrophysik, Hochenergiephysik, Geo-Wissenschaften, Festkörper- physik, Chemie und Biowissenschaften. Das Buch liefert einen Überblick über das breite Anwendungsspektrum von Problemen, die eine Nutzung von Höchstleistungs- rechnern erfordern. Jede Projektbeschreibung umfasst Informationen über den jeweiligen wissenschaftlichen Hintergrund, die erzielten Resultate und die eingesetzt numerischen Methoden. Das Buch bietet auch Einblicke in die erreichte Rechenleistung, in die Skalierbarkeit der Anwendungen und welche Verbesserungen bei den eingesetzten Algorithmen erreicht werden konnten.

2.5.4 InSiDe und Quartl

InSiDe (Innovatives Supercomputing in Deutschland) ist die Zeitschrift des Gauss Centre for Supercom- puting (GCS). Das LRZ hat zu den beiden Heften des Jahrgangs Nutzerartikel, Projekt- und Systembe- schreibungen beigetragen. Die Zeitschrift wird an zahlreiche Institutionen und Personen, sowie die Nutzer der Höchstleistungsrechner verschickt. Ferner wurden Beträge für das Quartl, das Mitteilungsblatt von KONWIHR und der Bavarian Graduate School of Computational Engineering (BGCE) verfasst.

78 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Online-Ausgaben sind verfügbar unter: http://inside.hlrs.de/htm/editions.htm bzw. http://www5.in.tum.de/wiki/index.php/Quartl

2.5.5 Sonstige Aktivitäten im Umfeld des Hochleistungsrechnens

19.01.2010 Besuch einer chinesischen Delegation 20.01.2010 DGI Monitoring Task Force 26.01.2010 Besuch einer Delegation der Universität Innsbruck 03.02.2010 Microsoft Uni Roadshow 2010 10.02.2010 DEISA WP 3,4,6,8 All Hands Meeting 19.02.2010 GSCS Meeting in Bonn zu Öffentlichkeitsarbeit 24.02.2010 Vortrag Prof Wettig Regensburg: QPACE - A massively parall supercomputer based on Power XCell 8i processors and network FPGAs 01.03.2010 - PRACE Prototype and Language Workshop 02.03.2010 03.03.2010 Stratos-Treffen 12.03.2010 Führung durch Rechnergebäude für Verband Deutscher Ingenieurinnen 19.03.2010 NGI-DE Meeting 22.04.2010 Girls‘ Day 2010 05.05.2010 Prospect Management Board Meeting 17.05.2010 - DRIHM (Distributed Research Infrastructure for HydroMeteorology) Workshop 18.05.2010 31.05.2010 - International Supercomputing Conference 2010, Hamburg 03.06.2010 Informationsstand 07.06.2010 Besuch Minoru Nomura, Affiliated Fellow, Science and Technology Foresight Center (STFC), National Institute of Science and Technology Policy (NISTEP), Mnistry of Education, Culture, Sports, Science and Technology, Japan. 29.06.2010 – DEISA Review Rehearsal 30.06.2010 01.07.2010 Brooking Institut, President Metropolitan, Policy Program Bruce Katz, Washington DC 12.07.2010 KONWIHR Review Workshop 16.07.2010 Besuch einer Delegation Huawei Research Unit, China

Jahresbericht 2010 des Leibniz-Rechenzentrums 79

30.07.2010 OpenFoam Anwendertreffen 02.08.2010 - DRIHM Proposal Meeting 04.08.2010 30.08.2010 - PRACE 1IP Kickoff-Meeting 31.08.2010 27.09.2010 - DGSI" (D-Grid Scheduler Interoperability) Plenar Meeting 28.09.2010 08.10.2010 Dr. Kusnezov, National Security Science and Technology, Washington DC 08.10.2010 Besuch einer Delegation der University of Aizu, Japan 13.10.2010 PROSPECT e.V. Mitgliederversammlung 14.10.2010 Exascale Meeting 18.10.2010 Richtfest Gebäudeerweiterung (Minister Herrmann) 18.10.2010 - IGE Kickoff Meeting 19.10.2010 25.10.2010 Besuch des Russischen Staatsministers für Kommunikation und Massenmedien Igor Shchegolev 08.11.2010 Besuch einer irakischen Delegation 13.11.2010 - Supercomputing 2010 Conference New Orleans 19.11.2010 Informationsstand, Tutorial: Introduction to PGAS (UPC and CAF) and Hybrid for Multicore Programming (R.Bader) 06.12.2010 - Besuch einer chinesischen Delegation 08.12.2010 07.12.2010 Besuch des European Institute for Urban Affairs (Prof. Evans Liverpool) 07.12.2010 Stratos Management Board Meeting & General Assembly 13.12.2010 Unterzeichnung SuperMUC Vertrag und Pressekonferenz

2.6 Projekte und Kooperationen

2.6.1 PRACE Innerhalb des PRACE Software-Arbeitspakets widmete sich das LRZ vorrangig der Evaluierung der Per- formance und Produktivität paralleler Programmiersprachen. Die Untersuchungsergebnisse zu RapidMind wurden in einem Artikel veröffentlicht, die umfassende Produktivitätsstudie zu zwölf Programmierspra- chen wurde als wissenschaftliches Poster auf der ISC10 angenommen. Frau Christadler stellte die Ergeb- nisse der Studie in mehreren Vorträgen vor, unter anderem bei der Internationalen Supercomputing- Konferenz in Hamburg ("PRACE: Open Dialog with European Tier-0 Users"). Zum Thema "New Languages & Future Technology Prototypes" lud das LRZ Anfang März mehr als 60 Teilnehmer zu einem PRACE Workshop ein. Das Booklet des Events fasst alle Vorträge zusammen. Im August waren dann mehr als 120 PRACE Mitarbeiter aus 20 verschiedenen Nationen am LRZ zu Gast, als die PRACE First Implementation Phase (das EU-Projekt PRACE-1IP) gestartet wurde. Auch hier übernimmt das LRZ wieder die Leitung des "Future Technology“ Arbeitspakets; außerdem zeichnet es verantwortlich für die Koordinierung der Subtasks zum Thema "Programming Techniques for High Per- formance Applications".

80 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Unter Leitung des LRZ lud die PRACE advisory group for Strategic Technologies (STRATOS) auf der ISC10 in Hamburg 15 HPC-Technologiefirmen ein, PRACE eine Aktualisierung der entsprechenden Produktroadmaps zu geben. Diese Informationen dienen unter anderem als Grundlage für die im PRACE- 1IP-Projekt zu definierenden HPC-Technologieprototypen. STRATOS war außerdem aktiv an der Orga- nisation des 2. European Workshop on Supercomputing Centre Infrastructure im Oktober 2010 in Dourdan, Frankreich beteiligt. In dieser Veranstaltung wurden den eingeladenen Vertretern von europäi- schen HPC-Zentren die aktuellen Entwicklungen zur Steigerung der Energie- und Kühlungseffizienz von Rechenzentren aufgezeigt. Im Rahmen eines Vortrages stellte Herbert Huber den LRZ-Erweiterungsbau sowie die Arbeiten des LRZ zur Steigerung der Kühlungseffizienz und deren geplante Umsetzung im Erweiterungsbau vor. Arndt Bode ist der deutsche Vertreter im PRACE Council, dem Leitungsgremium von PRACE.

2.6.2 DEISA2 LRZ-Mitarbeiter nahmen an DEISA2 Technical Meetings in Amsterdam, Barcelona, Bologna, Brüssel, Helsinki, Paris und Stuttgart, an DEISA Training Sessions in London und Edinburgh, dem DEISA Sym- posium in Amsterdam, sowie an zahlreichen DEISA-Videokonferenzen teil und beteiligten sich aktiv an Diskussionen in über 20 DEISA-Mailinglisten. DEISA2 läuft bis April 2011. Abbildung 39 zeigt die Teilnehmer an diesem Projekt.

Abbildung 39: Teilnehmer am DEISA2 Projekt. Mit gestrichelten Linien sind die vier assoziierten Partner CSCS (Schweiz), CCRT/CEA (Frankreich), KTH (Schweden) und JSCC (Russland) gekennzeichnet. Quelle: http://www.deisa.eu/

Das LRZ beteiligt sich dabei insbesondere an den Service Activities „Technologies“, „Application Enab- ling“ und „Operations“ sowie einer Joint Research Activity „Integrated DEISA Development Environ- ment“. Das LRZ betreibt für DEISA neben der Rechen-Ressource HLRB II auch deren Anbindung an das dedizierte DEISA-Netzwerk, einen Client für das gemeinsame Dateisystem GPFS, die Middlewares Glo- bus und UNICORE für den Benutzerzugang, sowie Dienste zur Benutzerverwaltung, Budgetierung, und Funktionsüberwachung der Benutzerdienste. Mit der zunehmenden Nutzung der DEISA-Infrastruktur spielt die Dienstgüte in DEISA eine immer grö- ßere Rolle. In 2010 wurden mehrere Maßnahmen unternommen, um dieser wachsenden Bedeutung ge-

Jahresbericht 2010 des Leibniz-Rechenzentrums 81 recht zu werden. Um eine stärkere Kontrolle der Service-Qualität in der DEISA Infrastruktur zu gewähr- leisten und um sicherzustellen, dass auftretende Schwierigkeiten zeitnah gelöst werden, wurde ein Trou- ble Ticket-System verwendet. Im Rahmen der Verbesserung der Service-Qualität wurden DEISA-Dienste (z.B. accounting, MyProxy, Unicore6) auf virtuelle Maschinen umgezogen und mit Hilfe des Monitoring- Tools Nagios überwacht. Das Monitoring-Werkzeug Inca wird erfolgreich für die Versionsprüfung des DEISA Common Produc- tion Environment (DCPE), für die Funktionsüberwachung der Middleware sowie für die Konsistenzprü- fung der Benutzerdaten eingesetzt. Die zentralen Inca-Komponenten werden für ganz DEISA am LRZ betrieben. Zahlreiche Updates und Änderungen der Infrastruktur wurden durchgeführt. Dazu zählen die Upgrades zu den neuesten Versionen, die Integration neuer DEISA Ressourcen, die Implementation einer Schnittstelle zwischen Inca und dem DEISA Trouble Ticket System sowie die Weiterentwicklung von Nutzungs- und Verfügbarkeitsreports. Inca führt regelmäßig mehr als 1.000 Tests auf 19 Ressourcen durch. Um die DEISA Inca Infrastruktur stetig zu verbessen, wurden die Inca Reporter für die Überwa- chung des General Parallel File Systems (GPFS) in Produktion genommen. Um eine zeitnahe Behandlung von Problemen und Änderungswünschen zu gewährleisten, pflegt das LRZ einen engen Kontakt mit dem Inca Entwickler-Team am San Diego Supercomputing Center (SDSC). Wie sich herausgestellt hat, ist eine frühzeitige Information von Administratoren und Benutzern über zukünftige Dienstausfälle durch Wartungen, Anpassungen, Erweiterungen, etc. sehr wichtig. Nur so kön- nen die von diesen Diensten abhängigen Personen angemessen darauf reagieren und z.B. auf andere Sys- teme ausweichen. Zur Automatisierung dieser Informationsmechanismen erarbeitete die Arbeitsgruppe DMOS, die vom LRZ geleitet wird, ein Konzept und begann mit der Implementierung des DMOS Sys- tems. DMOS stellt ein einfach zu bedienendes graphisches Benutzerinterface zur Verfügung, das Benut- zern aktuell in Wartung befindliche Systeme anzeigt und Administratoren einen einfachen update der Wartungsinformationen erlaubt. Da DMOS im Hintergrund eine SQL Datenbank benutzt, können War- tungsdaten leicht importiert und zu anderen Systemen, wie z.B Inca, exportiert werden. Nach der Produk- tivführung von DMOS wird ein Adaptor für Inca entwickelt werden, sodass zukünftig Wartungen mit der feinen Granularität des Services-Levels (bisher konnten nur ganze Systeme als „in Wartung“ angezeigt werden) in Inca angekündigt werden können. Das LRZ leitete die Untersuchung des neuesten Globus Releases GT5 auf seine Eignung zum Produkti- onseinsatz in DEISA. Das LRZ führte für DEISA-Benutzer Globus-Schulungen in Edinburgh und in London durch. Außerdem beteiligt sich das LRZ an den Aktivitäten im Bereich von Remote Visualizati- on, Cloud-Computing und Virtualisierung sowie zur Evaluierung von Monitoring-Tools. Viel zusätzliche Funktionalität wurde in das PTP Framework eingebaut. Die in 2009 entdeckten Sicherheitslöcher konnten geschlossen werden. Unterstützung für das DEISA Common Production Environment (DCPE) wurde eingebaut; UNICORE und das Performance-Analyse tool Paraver wurden eingebunden und getestet. Im Rahmen des WP9, „Enhancing Scalability“, wurde anhand des Quanten-Chromodynamic-Codes BQCD die Skalierbarkeit und Performanz eines Hybrid-Codes untersucht. Dazu wurden mehrere DEISA- Maschinen wie IBM BlueGene/P, CRAY und SGI Altix verwendet. Zusätzlich wurden in 2010 Beschleu- nigerkarten (GPGPUs) auf Ihre Eignung untersucht und mit den Ergebnissen vom Vorjahr verglichen, um ihre Auswirkungen auf Perfomance und Skalierbarkeit zu verstehen. Die Grid- und HPC-Enabling Arbeiten für die Projekte aus dem aktuellen DECI-6-Call werden erstmals von allen DEISA Sites mit dem in 2009 vom LRZ entwickelten und in DEISA etablierten Enabling- Arbeitsablauf verfolgt und gemanagt. Die HPC-Applikationen der Projekte AirFloPS, CatTIO2, COSUF, DiParTs, DNArecog, GlobUS, MeMGenA und PaRAdiSE wurden mit Home-Site LRZ in DEISA akzeptiert und vom LRZ betreut. Zusätzlich wurden für das Projekt DyBHo, mit Home-Site BSC und Executi- on-Site LRZ, die Portierungs- und Enablingarbeiten übernommen. Im Rahmen der DEISA Extreme Computing Initiative (DECI) wurden 12 Projekte am LRZ betreut. Für den DECI-Call 2010 wurden über das LRZ 11 Projekte eingereicht, von denen 8 akzeptiert und betreut wurden. Die Koordinierung der führenden europäischen Höchstleistungsrechenzentren zur gemeinsamen Abwick- lung der ehrgeizigen Ziele einer verteilten europäischen Höchstleistungs-Rechnerinfrastruktur erfordert regelmäßige Management-Treffen des DEISA-Exekutivkomitees. Diese fanden als Telefonkonferenzen statt.

82 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

2.6.3 PROSPECT e.V. PROSPECT ist ein im Umfeld von PRACE gegründeter Verein zur Förderung des Höchstleistungsrech- nens unter Einbeziehung von Wissenschaft, Wirtschaft und Herstellerfirmen. Der Verein wurde gemeinsam vom Barcelona Supercomputing Centre, dem Forschungszentrum Jülich und dem LRZ gegründet und umfasst inzwischen europaweit über fünfzig institutionelle Mitglieder. Arndt Bode vertritt das LRZ im Vorstand des Vereins. Der Fokus der Arbeiten in PROSPECT lag im Berichtsjahr auf den Themen „European OFS“ und „Euro- pean Technology Platform (ETP) for HPC“. Für die Verbreitung und Weiterentwicklung von Open Source Dateisystemen in Europa (u. A. Lustre) sowie die Berücksichtigung von speziellen Belangen europäischer Nutzer und Hersteller soll eine Euro- pean Cooperative Society (SCE) for OFS gegründet werden. Das LRZ ist durch Herrn Biardzki im Len- kungsausschuss der geplanten "European OFS Cooperative SCE" vertreten. Viel Engagement von PROSPECT e.V. Mitgliedern floss in strategische Überlegungen zur Gründung einer ETP für HPC, welche zukünftig die Belange von europäischen HPC-Nutzern bei der EU entsprechend vertreten soll.

2.6.4 KONWIHR

2.6.4.1 OMI4papps Im Rahmen des durch das Bayerische Staatsministerium für Wissenschaft, Forschung und Kunst geför- derten Kompetenznetzwerkes für Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR-II, Sprecher: Arndt Bode) erfolgten am LRZ innerhalb des Projektes „OMI4papps: Optimierung, Modellierung und Implementierung hoch skalierbarer Anwendungen“ folgende Aktivitäten: • Analyse der Performance und Anwendbarkeit neuer Programmiersprachen/-paradigmen für hochparallele Systeme • Beurteilung von neuen Hardware-Architekturen, insbesondere von Beschleuniger-Systemen mit CELL Prozessoren, Grafikkarten und Intels neuem Knights Ferry Chip • Evaluierung der Entwicklungsumgebungen RapidMind, HMPP ("Hybrid Multicore Parallel Pro- gramming Workbench“) und des PGI Accelerator Compilers, die eine einfache Programmierung von GPGPUs ermöglichen • Beta-Test von Intels neuer datenparalleler Programmiersprache "Intel Array Building Blocks" (ArBB) • Arbeiten zur synthetischen Performance-Modellierung wissenschaftlicher Applikationen • Erweiterung der Benchmarksuite des LRZ • Erweiterung des Kursangebots des LRZ im Bereich neuer Programmiersprachen und GPGPU- Programmierung. Im Juni fand der KONWIHR Review-Workshop statt, bei dem OMI4papps um ein weiteres Jahr verlän- gert werden konnte.

2.6.4.2 KONWIHR Software Initiative Im Rahmen der KONWIHR Software Initiative wurden vom LRZ drei Projekte unterstützt. Ziele der Initiative war es, neue Benutzer an das Hochleistungsrechnen heranzuführen. Das LRZ unterstützte die Benutzer hierbei bei der parallelen Implementierung von Submodulen aus dem Bioconductor Paket für verschiedene Architekturen wie SMP, MPP und GPGPU. Die Pakete umfassen Sequence Alignment (global und lokal) und teilweise überlappendes Alignment von DNA- und Protein-Sequenzen. Ein weiteres Projekt beschäftigte sich mit der Implementierung von Entscheidungsbäumen auf verschiedenen parallelen Architekturen für genom-weite Studien. Das dritte Projekt erforschte die Implementierung von Kreuz-Validierungs- und Normalisationsalgorithmen für hoch-dimensionale Micro-Array-Datensätze. Hierbei wurden rechenintensive Klassifikationsalgorithmen auf mehrere hundert Prozessoren skaliert.

Jahresbericht 2010 des Leibniz-Rechenzentrums 83

2.6.5 ISAR Innerhalb des BMBF-Projektes ISAR (Integrierte System- und Anwendungsanalyse für massivparallele Rechner) wurde durch das LRZ der Prototyp eines Monitoring-Tools (PerSyst Monitoring) installiert. Mit dem Tool lassen sich Engpässe auf Systemebene, wie z. B. Jobs mit schlechter Performance, detektieren. Für die Implementierung von PerSyst Monitoring wurden das Agentensystems, die Properties sowie die Suchstrategien von Periscope (innerhalb von ISAR weiterentwickeltes automatisches Leistungsanalyse- Tool auf Anwenderebene der TUM) an die systemweite Leistungsanalyse angepasst. Wesentlich bei der Implementierung war die Gewährleistung der weiteren Nutzung der von den Administratoren und Benut- zern am LRZ eingesetzten Anwendungen, die auf den bisherigen Monitoring-Tools basieren. Für die Ab- speicherung der gemessenen Daten sowie der berechneten Eigenschaften in einer MySQL-Datenbank wurde vom LRZ adäquate Hardware bereitgestellt. Die graphische Darstellung der Ergebnisse realisiert der GridMonitor der Firma ParTec, die ein Industriepartner innerhalb des ISAR-Projektes ist. Eine Vor- stellung von PerSyst Monitoring erfolgte innerhalb des Status-Treffens der Gauß-Allianz „Competence in High Performance Computing“ (CiHPC) in Schwetzingen (22.-24. Juli 2010).

2.6.6 EU Projekt Scalalife Im März 2010 wurde der Antrag für das Projekt Scalalife im Rahmen des FP7 Calls der EU genehmigt. Das Projekt soll die Grundlage für eine e-Infrastruktur im Bereich Life Science in der EU schaffen. Das LRZ hat hierbei die Leadership-Rolle für ein Workpackage übernommen und wird Dienste entwickeln, die anspruchsvolle Hochdurchsatzrechnungen von numerischen Simulationen auf europäischer Ebene ermöglichen. Speziell ist das LRZ für die Installation und die Validierung der Software zuständig und soll Benutzer an Maschinen der Petaflop-Klassen heranführen. Das Projekt hat eine Laufzeit von drei Jahren.

2.6.7 Beteiligung an Workshops Im Rahmen des Jülich Blue Gene/P Extreme Scaling Workshop 2010 (22.-24.3.) konnte ein Mitarbeiter das komplette Blue Gene/P System für BQCD-Tests benutzen und hat erreicht, dass das Quantenchromo- dynamikprogramm BQCD auf 294.912 Cores skalierte. Im Herbst 2010 wurde ein Projekt bei den "Grands Challenges CINES 2010" in Frankreich submittiert. Im Rahmen von Benchmark-Läufen auf dem neuen dortigen ICE Rechner wurde das Projekt akzeptiert und die Ergebnisse sind veröffentlicht („Combining MPI with OpenMP Parallelism in Large Scale QCD Simulations“). Auf einem Workshop in Leogang/Österreich zum Thema "Understanding the Parallel Behavior of Mo- dern Parallel CFD Applications" berichtete das LRZ über die Analyse des Skalierungsverhaltens und über eine Verbesserung des Mehrgitterverfahrens in OpenFOAM, einer modernen und weit verbreiteten Open Source CFD Anwendung. Zusammen mit den Jülicher Kollegen wurde im Frühjahr der „5th VI-HPS Tuning Workshop” organi- siert; Thema des Workshops waren Tools zur Skalierungs- und Parallelisierungsanalyse, wie Scalasca, VampirNG und Marmot.

2.7 Tätigkeiten im Server-Betrieb Der Hauptanteil der Tätigkeiten im Bereich der Server-Dienste beruhte auch im Jahr 2010 auf der Auf- rechterhaltung eines stabilen Betriebs. Trotz steigender Serverzahlen sind auch in diesem Jahr keine nen- nenswerten Dienstunterbrechungen zu vermelden.

2.7.1 Linux-Serversysteme Zur Aufrechterhaltung eines stabilen Betriebs von Linux-Systemen bewährt sich nach wie vor der für das Leibniz-Rechenzentrum entwickelte Software-Installations- und Update-Mechanismus. Die Eigenent- wicklung bietet den Vorteil, zeitnah auf individuelle Anforderungen reagieren zu können. Gerade im Be- reich der Linux-Server gleicht kaum eine Installation der anderen.

84 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Tagtäglich geschehen dynamische Veränderungen der LRZ-Dienste. Parallel dazu sind zum Betrieb aktueller Dienstsoftware Upgrades auf neuere Betriebssysteme notwendig. Wenn ältere Versionen nicht mehr vom Distributor unterstützt werden, betrifft der Betriebssystem-Upgrade zahlreiche Server. Die zugrunde liegende physische Hardware besteht aus verschiedensten Servermodellen. Deren Vielfalt ergibt sich nicht nur durch unterschiedliche Ansprüche beim Einkauf, sondern auch aufgrund Überlap- pung der jeweiligen Nutzungsdauer, teils über vier Generationen, d.h. Beschaffungsphasen hinweg. Erst durch die in 2009 erfolgte Beschaffung von Server-Blades als Grundlage für den Virtualisierungs- Cluster, der ab Mitte 2010 in Produktionsbetrieb übergeführt wird, entsteht ein gewisses Maß an Homo- genisierung. Somit existieren Administrationsvorteile analog zu den Pools gleicher Hardware im Bereich des Linux-Clusters, des HLRB II oder z.B. der Linux-Desktops bei den Mitarbeiter-Arbeitsplätzen. Die Zeitvorteile durch Homogenisierung werden allerdings bei gleichbleibendem Personalstand durch die rapide steigenden Zuwachszahlen an Linux-Servern nicht nur egalisiert, sondern ins Gegenteil verschoben. Das Jahr 2010 ist deshalb geprägt von der Planung und teilweisen Einführung notwendiger Prozesse zur Inbetriebnahme und Verwaltung von Linux-Servern und der Konkretisierung des sog. Dienstleis- tungskatalogs inklusive Aufstellung einer Verhaltensrichtlinie (Policy) für Linux-Nutzer. Ein wichtiges Beispiel ist die, bereits Ende 2009 angekündigte Einführung automatischer Linux-Kernel- Updates. Letztere ziehen einen Server-Reboot und somit eine zumindest kurzzeitige Dienstunterbrechung nach sich. Auf Wunsch kann eine Vorwarnzeit (in Tagen) eingerichtet werden. Seit 1. Juni 2010 liegt die Verantwortung beim Dienstadministrator, wenn Kernel-Updates ausgesetzt werden sollen. Eine individuelle Absprache zwischen Dienst- und Systemadministrator, die zuvor für jeden einzelnen Server getroffen werden musste, entfällt. Zur Dokumentation dient das Webinterface des LRZmonitor. In gewohnter Weise lassen sich sämtliche Routinen – auch für den Kernel-Update – halbau- tomatisch, d.h. bequem durch manuellen Aufruf starten. Parallel zum Ausbau der virtuellen Infrastruktur bleibt ein gewisser Grundbedarf an physischer Hardware erhalten. Hierzu zählen z.B. Dienste, die die virtuelle Umgebung managen, deren Aufstellungsort abseits der virtuellen Infrastruktur liegt, die einen hohen Anspruch auf Autonomie besitzen oder eine hohe Band- breite benötigen. Aus den genannten Gründen wurden im Dezember 2010 insgesamt 18 Server von der Fa. DELL einge- kauft. Neben 2 Modellen mit der Bezeichnung DELL PowerEdge R710 (2 HE), geplant als Oracle- Datenbank-Server, wurden 16 Modelle mit der Bezeichnung DELL PowerEdge R610 (1 HE) beschafft. Mit einer Ausnahme von 96 GByte RAM für den LRZ-Accounting-Dienst, sind alle übrigen Server mit 24 GByte RAM bestückt. Während für die R710-Modelle aus Oracle-Lizenz-Gründen nur eine CPU ver- baut ist, besitzen alle anderen Server jeweils zwei 6-Core-CPUs von Intel. Mit aktiviertem Hyperthrea- ding ergeben sich somit 24-fach SMP-Systeme. Das Einsatzgebiet der neuen R610-Server ist die Auslagerung als DNS- und DHCP-Server zur TUM und LMU in die Innenstadt, sowie die Verbringung nach Weihenstephan. Weitere zwei Server werden aus Homogenitätsgründen für DNS-/DHCP und als Testmaschine LRZ-intern genutzt. Sieben R610-Server (Accounting, Secomat, Snort-IDS usw.) dienen dem künftigen Netzmonitoring und besitzen deshalb eine zusätzlich eingebaute Karte mit 10-GbE-Dual-Ports für LC-Verkabelung. Zwei R610-Server unterstützen die VoIP-Telefonanlage, zwei sind als zentrale Basis für das künftige LRZ- Monitoring eingeplant.

2.7.1.1 Virtualisierung am LRZ Die stetige Virtualisierung physischer Systeme setzte sich auch im Jahr 2010 fort. Gegen Ende des Jahres bestand noch für etwa 76 physische Server mit Betriebssystem SuSE-Linux Virtualisierungspotential.

Jahresbericht 2010 des Leibniz-Rechenzentrums 85

Hauptgruppe Unter- Beschreibung Virtualisierungs- Erreichte gruppe anteil Zielsetzung SGI Altix Hlrb2 Höchstleistungsrechner 2/27 ≈ 7% 2/2 ≈ 100% Div HLR-Test- u. Spezialsysteme 0/6 ≈ 0% - Ice ICE-Testsystem 0/66 ≈ 0% - Lx64a Opteron-Clusterknoten 0/360 ≈ 0% - Lx64e EM64T-Clusterknoten 0/345 ≈ 0% - Linux-Cluster Lx64i Itanium-Clusterknoten 0/3 ≈ 0% - Lx64s Cluster-Management 28/37 ≈ 75% 28/28 ≈ 100% Lxe LMU Physik-Cluster 1/14 ≈ 7% 1/1 ≈ 100% Lxlcg LCG-Server-Blades 0/27 ≈ 0% - Lcg LCG-Manage- u. DCache-Knoten 12/67 ≈ 17% 12/12 ≈ 100% Grid Server Grid Grid-Dienste 60/65 ≈ 92% 60/65 ≈ 92% HSS Server Hss Hochschulstart.DE-Dienst 77/85 ≈ 90% 77/77 ≈ 100% Bsb BSB-Dienste 30/65 ≈ 46% 30/30 ≈ 100% BSB + BVB Server Bvb BVB-Dienste 22/22 ≈ 100% 22/22 ≈ 100% Misc Verschiedene Dienste 48/66 ≈ 72% 48/51 ≈ 94% Net Netzdienste 20/55 ≈ 36% 20/23 ≈ 86% Mail Mail-Server 17/35 ≈ 48% 17/35 ≈ 48% Web Web-Server 21/51 ≈ 41% 21/47 ≈ 44% Server Sql Datenbank-Server 14/18 ≈ 77% 14/14 ≈ 100% Basisdienste Edir e-Directory-Dienste 53/62 ≈ 85% 53/62 ≈ 85% Dat Daten- und Archiv-Dienste 10/83 ≈ 12% 10/10 ≈ 100% Cons Konsol- und Leitwartenserver 1/33 ≈ 3% 1/1 ≈ 100% Gmm Grafik- und Multimedia-Dienste 4/18 ≈ 22% 4/8 ≈ 50% Ext Server-Hosting 17/25 ≈ 68% 17/25 ≈ 68% Kurs-Cluster Kurs Kurs-Clusterknoten 12/21 ≈ 57% 12/12 ≈ 100% Mitarbeiter- User Büro- und Telearbeitsplätze 4/91 ≈ 4% 4/4 ≈ 100% Arbeitsplätze Gesamtanteile 453/1747 ≈ 26% 453/529 ≈ 86% Tabelle 28: Anteil virtueller gegenüber physischer Linux-Systeme Ende 2010

Nachdem im Vorjahr mit der Beschaffung einer größeren Infrastruktur der Grundstein für Virtualisierung am LRZ gelegt worden war, stand im Jahr 2010 das Thema Hosting virtueller Maschinen im Vorder- grund. Ziel des Vorhabens ist es, neben der Virtualisierung von LRZ-internen Systemen, die bereits zu massiven Einsparungen an physischen Servern führte, auch anderen Großnutzern die Möglichkeit zu geben, virtuelle Maschinen gegen Gebühr in der „LRZ-Cloud“ zu betreiben. Unter diesem Aspekt wurde das vorhandene VMware-Cluster von 32 auf nunmehr 64 Knoten verdoppelt, so dass mittlerweile 4,6 TB Hauptspeicher und 512 Rechenkerne für Virtualisierungsprojekte zur Verfügung stehen. Mit dem Projekt „Hochschulstart.de“ konnte ein weiterer großer Kunde für den Virtualisierungsdienst gewonnen werden und ein zusätzliches, separiertes Cluster mit 28 Systemen aufgebaut werden. Aktuell betreibt das LRZ auf diesen Clustern bereits über 800 VMs – Tendenz stark steigend. Neben den Erweiterungen der Hardware, die schon allein aufgrund der hohen LRZ-internen Virtualisie- rungsquote notwendig wurde, lag der Focus im Jahre 2010 auf dem Design von Prozessen zum Betrieb des geplanten Hosting-Szenarios sowie ersten prototypischen Implementierungen eines Webshops und eines automatisierten Verfahrens zur Bereitstellung von bestellten virtuellen Maschinen. Der Webshop wurde von Mitgliedern der ITSM- und Virtualisierungs-Gruppen des LRZ in Zusammenarbeit mit iET Solutions geplant und wird zurzeit von iET Solutions, dem Hersteller der im letzten Jahr erworbenen ITSM-Suite, implementiert. Dieses Projekt erweist sich aufgrund der noch nicht implementierten CMDB (Konfigurations-Management-Datenbank) sowie diversen Designeinschränkungen seitens der ITSM Suite als etwas kompliziert und langwierig, so dass mit funktionalen Ergebnissen frühestens im ersten Quartal 2011 gerechnet werden kann. Gut voran kam hingegen ein selbst entwickelter Algorithmus zur automatischen Provisionierung von virtuellen Maschinen. Der Algorithmus ermöglicht es, bestellte virtuelle Ma- schinen aus einer Datenbank abzufragen, eine entsprechende virtuelle Maschine nach den Vorgaben des Bestellers auf dem Cluster zu instanziieren und diese durch ein ebenfalls vollautomatisiertes Installati- onsverfahren mit einem gewünschten Betriebssystem zu versehen. Zu einem funktionierenden Gesamt- system, das als Dienst des LRZs nach den Vorgaben des ISO/IEC 20000 Standards betrieben werden soll, fehlt jedoch noch die endgültige Anbindung an die CMDB, welche zu diesem Zweck momentan um diverse Funktionalitäten wie etwa IP-Adressverwaltung und den genannten Webshop erweitert wird.

86 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Zwei weitere Aspekte, die im laufenden Jahr fast zwangsläufig im Kontext des Hostingprojekts behandelt werden mussten, sind die Themen Monitoring und Security. Da die Verfügbarkeit einer virtualisierten Umgebung aufgrund der vielen involvierten Subdienste, wie zum Beispiel physische Server, Netz und Storage, neben der eigentlichen Virtualisierungsschicht auch stark von diesen Komponenten abhängt, wird ein Dienste-übergreifendes Monitoring notwendig, welches aktuell im Rahmen von zwei Bachelor- arbeiten implementiert wird. Weiterhin wurden neue Firewall-Lösungen für virtualisierte Infrastrukturen evaluiert, um die gehosteten Maschinen zuverlässig voneinander isolieren zu können sowie ein erstes Konzept zur Realisierung eines sicheren und mandantenfähigen Management-Portals im Web erarbeitet.

Abbildung 40: Entwicklung und Nutzung der LRZ-Virtualisierungsumgebung

2.7.1.2 PCs unter Linux als Mitarbeiter-Arbeitsplätze Im Bereich der Mitarbeiter-Arbeitsplätze gab es 2010 wenige Änderungen. Ab April 2010 fand der Up- grade des verwendeten Betriebssystems „Novell/SuSE Linux Enterprise Desktop“ von Version 10 Ser- vicePack 2 auf ServicePack 3, kurz bezeichnet als „SLED-10.3“, statt. Ende 2010 wurde wegen zu hektischer Upgrade Zyklen der Umstieg auf die neueste Version „openSUSE 11.3“ vorbereitet. Ende Dezember begann die Verteilung der neuen OpenSource-Software auf die Mitar- beiter-Arbeitsplätze. Neben der Softwareumstellung werden sukzessive veraltete PCs der Modellreihe „DELL OptiPlex GX620“ durch neue „DELL OptiPlex 980“ ersetzt, von denen Mitte 2010 insgesamt 25 Stück für den Einsatz als Linux-Arbeitsplatz beschafft wurden.

Jahresbericht 2010 des Leibniz-Rechenzentrums 87

2.7.1.3 Zuwachs von Linux-Hosts im Leibniz-Rechenzentrum

1800

1700 SGI Altix 1600 Linux-Cluster 1500 Mitarbeiter-Arbeitsplätze Kurs-Cluster 1400 BSB + BVB Server 1300 Grid Server 1200 HSS Server 1100 Server Basisdienste Virtuelle Hosts 1000 900

800

700

600

500

400

300

200

100

0 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

Abbildung 41: Anzahl der Linux-Hosts im Leibniz-Rechenzentrum

2.7.1.4 Betriebsüberwachung Im Bereich der Betriebsüberwachung gab es 2010 wenig nennenswerte Änderungen gegenüber dem Vor- jahr. Erwähnenswert ist die Einführung eines weiteren sog. Überwachungssatelliten (siehe zur Begriffs- klärung den Jahresbericht 2009) im Rahmen des Hochschulstart.DE-Projekts. Auf diesem kommt die lizenzpflichtige Monitoring-Software „up.time“ zum Einsatz. Im Herbst 2010 fand für mehrere Mitarbeiter eine hausinterne Schulung zur Bedienung von „Tivoli Net- cool/OMNIbus“ statt. Die Umstellung von „HP OpenView“ auf „Tivoli Netcool/OMNIbus“ verzögert sich aufgrund unerwartet hohen Personalaufwands zur Kundenbetreuung für das Linux-Server-Hosting.

2.8 Aktivitäten im Bereich „Verteilte Ressourcen“ Die Arbeiten im Bereich Grid-Computing erfordern ein breit gefächertes Know-how und werden deshalb von den Abteilungen Kommunikationsnetze, Hochleistungssysteme und Benutzernahe Dienste und Sys- teme gemeinsam durchgeführt. Als abteilungsübergreifende Einrichtung war und ist der Arbeitskreis Grid Computing (AK-Grid) maßgeblich an der Koordinierung der verschiedenen Grid-Projekte (D-Grid, DEI- SA-2, PRACE, LCG Tier-2, EGI, IGE, LRZ-Grid, Grid Aktivitäten an LMU und TUM) innerhalb des LRZ und im Münchner Raum beteiligt, hilft Synergien auszunutzen und Doppelarbeit zu vermeiden. Dar- über hinaus widmete sich der AK-Grid in 2010 verstärkt dem Thema „Cloud-Computing“. Bis zu 10% der HLRB II-Rechenleistung sowie ein nicht unerheblicher Teil der Rechenleistung unseres Linux Clusters werden über Grid-Middleware von den Wissenschaftlern in Deutschland und Europa abgerufen. Das LRZ ist aktiv an den nationalen und internationalen Grid-Projekten „Initiative for Globus in Europe – IGE“, „European Grid Initiative - Integrated Sustainable Pan-European Infrastructure for Researchers in

88 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Europe – EGI-InSPIRE“, „Distributed European Infrastructure for Supercomputing Applications - DEISA2“, „Partnership for Advanced Computing in Europe, 1st Implementation Phase - PRACE-1IP“, den D-Grid-Projekten DGI2, SLA4D-Grid sowie DGSI, LHC-Grid (LCG) und „e-Infrastructure Reflec- tion Group Support Programme 3 (e-IRGSP3)" beteiligt. Dabei hat das LRZ bei IGE erstmalig die Füh- rungsrolle in einem europäischen Projekt übernommen. Im Folgenden beleuchten wir einige der in den Grid-Projekten durchgeführten Arbeiten ausführlicher.

2.8.1 Initiative for Globus in Europe (IGE) Die Gruppe VER initiierte 2010 das EU-Proposal „Initiative for Globus in Europe (IGE)“, um die Belan- ge der europäischen Benutzer stärker in dieser führenden Grid-Middleware zu repräsentieren. Dazu integriert IGE zehn europäische Partner sowie die University of Chicago, die die zentrale Globus Codebasis pflegt. IGE will hauptsächlich koordinierend eingreifen und die europäischen Wünsche bündeln und abstimmen, um sie dann mit einer gewichtigen Stimme gegenüber den anderen Globus-Entwicklern vorzutragen. Durch IGE soll Globus, das sich in Europa einer breiten Benutzerschaft erfreut, bisher aber keine europäi- sche Lobby hatte, in die europäischen Grid-Projekte, allen voran die European Grid Initiative (EGI), getragen werden. Durch Zentralisierung von Funktionen wie Test, Zertifizierung, Training, Support, etc., bei IGE kann Europa durch Synergieeffekte den Aufwand verringern und den Service für die Benutzer verbessern. Die wichtigsten Ziele des Projekts sind: • Koordination europäischer Globus Aktivitäten • Europäischen Input gebündelt an die Globus Alliance liefern • Für Europa wichtige Erweiterungen sollen in den Globus Quellcode einfliessen • Adaptoren für in Europa häufig benutzte Stapelverarbeitungssysteme wie LL, NQS2, ... bereitstellen • Als Globus-Dienstleister für europäischen Grids wie DEISA, PRACE und EGI arbeiten • Die Softwarequalität der Globus Middleware beurteilen • Verbesserung von Standardisierung, Training und Dokumentation von Globus • Ausrichten der Globus Europe Konferenz und des europäischen Globus Community Forums • Bereitstellung eines Spiegelservers für globus.org in Europa zur Redundanzerhöhung • Aufsetzen eines europäischen Globus metrics, um den strengen europäischen Datenschutz- richtlinien zu genügen • Unterstützung für Interoperabilität von Grid Middleware (BES, SAML, JSDL, LCAS, etc.) • Bereitstellung einer Web-Präsenz: http://www.ige-project.eu/ • Erstellen binärer Distributionen für die in Europa wichtigen Betriebssysteme AIX, SuSE, Debian, Fedora, etc. Die „Initiative for Globus in Europe – IGE“, begann offiziell am 1. Oktober 2010 und startete kurz darauf mit einem Kick-Off Treffen am LRZ. Sie stellt für das internationale Globus Projekt den Brückenkopf in Europa dar. IGE liefert die Globus Middleware für die europäischen Grid Infrastrukturen wie EGI, DEI- SA, PRACE, etc., und bietet neben Benutzerunterstützung und Training auch Anpassungen von Globus an europäische Bedürfnisse an. Dieses Projekt stärkt die Rolle Europas und natürlich auch des LRZ in Globus, dem weltweit führenden Middleware-Projekt. Auf der jährlich stattfindenden GridKa Summer School in Karlsruhe wurde das vom LRZ im Rahmen von IGE organisierte Globus-Training zum besten Training gewählt.

2.8.2 D-Grid: Förderung „e-Science und vernetztes Wissensmanagement“ des BMBF Im Rahmen von D-Grid nahm das LRZ 2010 an vielen Workshops und Treffen teil. In den kommenden Jahren wird das D-Grid Teil eines größeren, europäischen Verbunds, der European Grid Initiative (EGI) - dort vertreten durch NGI-DE (National Grid Initiative - Deutschland).

Jahresbericht 2010 des Leibniz-Rechenzentrums 89

2.8.2.1 D-Grid Integrationsprojekt (DGI) Als Rechenzentrum, und damit als Ressourcenanbieter, war das LRZ vorrangig am sogenannten D-Grid Integrationsprojekt (DGI, Laufzeit Jan. 2008 bis Dez. 2010) beteiligt. Aufgrund langjähriger guter Kon- takte zu HPC-Benutzern aus Astro- und Hochenergiephysik trat das LRZ aber auch als assoziierter Part- ner der Astrophysik- und der Hochenergiephysik-Community auf und beteiligte sich an deren Arbeitstref- fen. Außerdem ist 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 (Fachgebiet 1) vielfältiges Know-how für die Unterstützung von Benutzern und Ressourcenanbietern bezüglich Globus bereit. Auf den Produkti- onssystemen des LRZs wurde Globus von GT4.0.8 auf GT5.0 angehoben. Aufgrund der stürmischen Entwicklung des Globus Toolkits wurde im D-Grid beschlossen, die Version GT4.2 zu überspringen und direkt auf GT5 zu migrieren. Für einen Übergangszeitraum von 6 bis 12 Monaten sollen im D-Grid beide Globus Versionen parallel betrieben werden, da sie nicht 100% kompatibel sind. Nach Ende der Über- gangsphase soll dann vollständig auf GT5 migriert werden. Ein schwerwiegender Fehler in GT5, der durch Tests des LRZs offensichtlich wurde, verzögerte jedoch die Einführung von GT5. Im Rahmen des DGI-Fachgebiets 2-3 hat das LRZ Ressourcen für D-Grid angeschafft und betrieben und zentrale Dienste bereitgestellt. Die im Rahmen der D-Grid-Sonderinvestitionen im Herbst 2008 ange- schafften Serversysteme (zwei Serversysteme Sunfire X4600) zur Remote-Visualisierung sowie die dazu notwendige Software (AVS, Amira/Avizo, IDL) wurden für das D-Grid betrieben. Das LRZ hat die Res- sourcen, die im Rahmen früherer Sonderinvestitionen beschafft wurden, weiterbetrieben und für das D- Grid verfügbar gemacht. Im Jahr 2010 wurden auf diesen Ressourcen fast 3,4 Mio. Jobs submittiert, die ca. 5,8 Mio. CPUh verbraucht haben. Der Speicherplatz im dCache-Pool belief sich auf ca. 500 TByte. Als zentrale Dienste für D-Grid hat das LRZ Grid-Monitoring mittels der Werkzeuge MDS, WebMDS, GridCSM, 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, geleis- tet. Da der Förderzeitraum für DGI-2 Ende 2010 endete, wurde im Herbst zusammen mit den NGI-DE Part- nern ein Antrag für eine zwei-jährige Anschlussförderung beim BMBF eingereicht.

2.8.2.2 DGSI Das D-Grid-Gap-Projekt „D-Grid Scheduler Interoperability“ (DGSI) konzipiert und entwickelt eine In- teroperabilitätsschicht für Scheduling in Service Grids, die es Benutzern einer Community erlaubt, Ar- beitslast auf Ressourcen einer anderen Community zu verlagern. Im September 2010 richtete das LRZ ein All-Hands-Meeting von DGSI am LRZ aus. LRZ-Mitarbeiter beteiligten sich an unzähligen Telefonkonferenzen und brachten den LRZ Standpunkt ein. Das LRZ ist als Leiter von Task 4 für die „Anbindung lokaler Resource Management-Systeme“ verantwortlich. Im Rah- men dieses Tasks stetzte das LRZ ein Testbed mit GT4.0.8 und einer SGE Instanz auf. Es wurden Inter- faces zu den in Task 3 entwickelten Komponenten implementiert, sodass nun eine einheitliche Verbin- dung auch zu verschiedenen Batch Systemen möglich ist. Das LRZ ist an insgesamt drei Arbeitspunkten im Projekt beteiligt und hat an mehreren Projektberichten mitgearbeitet.

2.8.2.3 SLA4D-GRID Das D-Grid-Projekt “Service Level Agreements for D-Grid” (SLA4D-GRID) entwirft und realisiert eine Service Level Agreement-Schicht (SLA-Schicht) für das D-Grid. Diese Schicht zur Vereinbarung einer festgelegten Dienstgüte bietet einzelnen Benutzern, ganzen D-Grid Communities, sowie den Anbietern von D-Grid-Ressourcen die Gewährleistung der Ressourcennutzung unter wirtschaftlichen Bedingungen. In 2010 gab es drei Projekttreffen, an denen sich auch das LRZ beteiligte; ein Treffen wurde vom LRZ ausgerichtet und im Anschluss an die an der LMU stattfindende OGF-28 Konferenz in den Räumen der LMU in München abgehalten. Das LRZ promotete D-MON, eine LRZ Eigenentwicklung im Monitoring- Bereich, und lieferte ein Konzeptpapier, das die mögliche Verwendung von D-MON in SLA4D-GRID aufzeigt sowie Auswahlkriterien für ein Monitoringsystem bereitstellt. Vom LRZ wurde ein Testbed mit sechs Servern aufgesetzt. Für Globus, UNICORE und gLite steht jeweils ein Server zur Verfügung. Ge- meinsam für alle Middlewares gibt es einen Speicher-Server, einen Monitoring-Server und einen Batch-

90 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Server. Die Installation des Speicher-Servers mit GridFTP erleichterten Installationspakete von IGE (siehe Abschnitt 2.8.1).

2.8.3 EGI-InSPIRE Mit der Beteiligung an EGI-InSPIRE, das am 1. Mai startete, spielt das LRZ nun auch eine wesentliche Rolle in der zweiten großen europäischen e-Infrastruktur: EGI. Zusammen mit der Beteiligung an PRACE-1IP (ab 1.7. 2010) und DEISA2 fällt damit dem LRZ eine wichtige Funktion für die Integration der Infrastrukturen zu, an der auch in 2010 mit Hochdruck gearbeitet wurde. Im Projekt EGI-InSPIRE beteiligt sich das LRZ in 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 im Rahmen der Deployed Middleware Support Unit (DMSU).

2.8.4 MAPPER Das in 2010 neu gestartete EU-Projekt MAPPER (Multiscale Applications on European e-Infrastructures, http://www.mapper-project.eu/) konzentriert sich darauf, die für die Forschung immer wichtiger werden- den multi-scale Systeme, die mehrere wissenschaftliche Gebiete (etwa Fluiddynamik, Strukturmechanik und Chemie der Verbrennungsvorgänge) involvieren, effizient auf die europäischen Infrastrukturen wie EGI und PRACE abzubilden. Diese multidisziplinären, multi-scale Systeme erfordern zu ihrer Simulation höchste Rechenleistung. MAPPER wird Algorithmen, Software und Services für diese Unterfangen entwickeln und die besonderen Anforderungen (wie etwa advance reservation und co-scheduling) mit einer gewichtigen Stimme in die Infrastrukturen hineintragen. Das LRZ ist hier als Partner der LMU, einem der MAPPER-Partner, beteiligt und wird Hardware und Software beisteuern sowie das Projekt umfassend unterstützen; so ist z.B. das MAPPER All Hands Mee- ting für 2011 am LRZ geplant.

2.8.5 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 publi- ziert. Da das Projekt erst im Dezember startete, fanden 2010 neben einem Kickoff-Meeting nur erste ko- ordinierende Tätigkeiten statt.

2.8.6 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) Das derzeit weltgrößte Teilchenphysikexperiment „Large Hadron Collider“ am CERN steigerte in 2010 die Energie der Teilchenkollisionen. Bei den Experimenten der bedeutenden Wissenschaftsprojekte am CERN entstehen gewaltige Mengen an Daten im Petabyte-Bereich. Für die Auswertung wurde von An- fang an auf verteilte Ressourcen gesetzt. Heute sind dafür weltweit hunderte Cluster in einem Grid – dem LHC Computing Grid (LCG) – vernetzt. Das LRZ betreibt dabei zusammen mit dem MCSC-Partner RZG und den Hochenergiephysikern aus dem Münchner Raum ein Tier-2-Zentrum (siehe Abbildung 42). 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 stehen am LRZ für die Speicherung der Experimentdaten und Auswertungsergebnissen 915 Terabyte (TB) zur Verfü- gung. Durch die Absicherung als RAID beträgt die Nettokapazität 723 TB, die über die dCache-

Jahresbericht 2010 des Leibniz-Rechenzentrums 91

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.

Abbildung 42: Tier-Struktur des LHC Computing Grids.

2.8.7 LRZ-Projekt „Eclipse4Grid“ Das interne LRZ-Projekt „Eclipse4Grid“ hat sich zum Ziel gesetzt, das Software-Entwicklungs- Framework „Eclipse“ von IBM für Grid-Anwendungen geeignet zu erweitern. In Kooperation mit dem DEISA-Arbeitspaket 8 wurde die Erweiterung PTP untersucht. Darüber hinaus wurden die Erweiterungen unter die Lupe genommen, die im Rahmen des gEclipse-Projekts entstanden sind. Zusammen mit dem ISAR-Projekt wurde am 1. Oktober 2010 der PTP Workshop „Eclipse: C/C++ programming (with a slight Fortran touch)“ gehalten. Ein Abschlussworkshop mit dem Titel „Parallel Tools Platform (PTP): Eclipse based IDE for parallel application development, debugging and profiling“ ist für März 2011 geplant. Das Projekt lief Ende 2010 erfolgreich aus.

2.8.8 Cloud-Computing Während beim Grid-Computing der Hauptaspekt die föderale Nutzung von auf die Partner verteilten Res- sourcen ist, richtet sich das Cloud-Computing vornehmlich auf die Virtualisierung von Ressourcen. Diese Ressourcen sind nicht mehr unbedingt weiträumig verteilt, sondern oft bei einem kommerziellen Anbieter geclustert. So bieten Amazon, Google, aber auch die Deutsche Telekom Cloud Ressourcen gegen Entgelt an. Da dem Benutzer jeweils virtuelle Maschinen unter verschiedenen (Linux) Betriebssystemen angeboten werden, ist die genaue Beschaffenheit der zugrundeliegenden Hardware nur mehr zweitrangig. Durch die Virtualisierung wird auch der beim Nutzer ansonsten oft erhebliche Portierungsaufwand drastisch verringert – idealerweise bis auf null, denn der Benutzer kann ein ihm genehmes Betriebssystem auswäh- len.

92 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)

Im Rahmen des AK-Grid haben die Mitglieder verschiedene Cloud-Computing Anbieter getestet und in Vorträgen die Ergebnisse einander vorgestellt. So wurde die Elastic Computing Cloud (ECC) von Ama- zon auf Ihre Eignung für das LCG getestet: prinzipiell ist die ECC dafür geeignet, jedoch sind derzeit die auf „echter“ Hardware basierten Tier-2 Zentren (von denen eines auch am LRZ betrieben wird, siehe Abschnitt 2.8.3) noch deutlich kostengünstiger, als das Cloud-Computing bei Amazon. Es wurden auch Experimente mit den Angeboten von Google und der Telekom vorgeführt. Der AK verfolgte auch Bestre- bungen der Open Cloud Computing Interface working group des OGF, um die derzeit noch proprietären Interfaces der verschiedenen kommerziellen Anbieter zu vereinheitlichen und deren Clouds interoperabel zu machen. Die freien Pakete NIMBUS und OpenNebula zum Aufbau einer Cloud wurden praktisch untersucht, jedoch sind beide noch nicht reif für den Produktionseinsatz. Im nächsten Jahr soll am LRZ prototypisch eine Cloud aufgesetzt und ausgewählten Benutzern zum Test angeboten werden.

2.8.9 Projektanträge 7. EU-Forschungsrahmenprogramm „e-Infrastrukturen“ Für die Ausschreibung „FP7-INFRASTRUCTURES-2011-2“ des 7. Forschungs-Rahmenprogramms der EU beteiligte sich das LRZ an vielen Projekten. Die Projekte mit Beteiligung der Gruppe VER werden im Folgenden aufgezählt. Eine Entscheidung über die Genehmigung dieser Projekte fällt voraussichtlich im Frühjahr 2011. Die Gruppe „Verteilte Ressourcen“ war an den folgenden EU-Projektanträgen im FP7-Call beteiligt: • Partnership for Advanced Computing in Europe - First Implementation Phase Project (PRACE-2IP (Konsortialführung FZ Jülich) • My e-World (M-eW, Konsortialführung NCF, Den Haag) • Virtual Earthquake and Seismology Research Community in Europe (VERCE, Konsorti- alführung CNRS-INSU, Paris), Wiederholungsantrag • Intelligent Application-Oriented Scheduling Framework (IANOS, ATOS Origin Spanien), Wiederholungsantrag • Distributed Research Infrastructure for Hydro-Meteorology (DRIHM, Universität Genua), Wiederholungsantrag

2.8.10 Betrieb der Grid-Infrastruktur Der Regelbetrieb der Grid-Dienste wurde durch die Mitarbeiter der Gruppe „Verteilte Ressourcen“ betreut und ausgebaut. Derzeit betreut die Gruppe etwa 70 Server, auf denen ca. 40 Dienste in Produktions- und Testbetrieb laufen. Bei den seit Anfang 2010 in Produktion befindlichen Systemen lag die Verfüg- barkeitsquote bei 99.968%. Um die Ausfallsicherheit der Dienste weiter zu erhöhen, wurde fortgefahren, sie von physikalischer Hardware auf virtuelle Maschinen aus dem LRZ VMware-Pool zu migrieren. Au- ßerdem wurde die automatische Überwachung der Maschinen und Dienste deutlich erweitert, sowie re- gelmäßige Kernel-Updates und Security-Checks durchgeführt. Die lokale Grid-Benutzerverwaltung GUA (Grid User Administration) wurde vollständig mit LRZ SIM integriert. Benutzer aus D-Grid VOs (virtuelle Organisationen) und DEISA Projekten erhalten nun automatisch Zugang zum Linux Cluster bzw. zum Höchstleistungsrechner. Die Zahl der Grid-Accounts stabi- lisiert sich bei ca. 1.500 (1.409 Grid-Accounts in 2010, im Vorjahr waren es 1.569). Etwa 5% der HLRB II-Rechenleistung sowie ein Teil der Rechenleistung unseres Linux Clusters werden über Grid- Middleware von den Wissenschaftlern abgerufen. Die LRZ Grid Registration Authority, die auch die Rolle der Grid Registration Authority der LMU, der TUM und der Universität der Bundeswehr einnimmt, hat auch in 2010 wieder die Mitarbeiter und Studen- ten der drei großen Münchner Universitäten bei der Grid-Nutzung unterstützt. Insgesamt wurden 2010 72 User- und 52 Server-Zertifikate ausgestellt.

2.8.11 Sonstige Grid-Aktivitäten Am LRZ wurde im Rahmen der Einführungsveranstaltungen Grid Computing mit Übungen für die Teil- nehmer vorgestellt und traf auf große Resonanz. Die Grid-Zugänge über gsi-ssh stehen nun gleichberech- tigt neben ssh mit Passwort in unseren Dokumentationsseiten für alle Benutzer. Dazu trug auch der Short

Jahresbericht 2010 des Leibniz-Rechenzentrums 93

Lived Credential Service (SLCS) des DFN bei, der mit dem Identity provider (IdP) des LRZ gekoppelt ist und so allen LRZ Benutzern ohne weitere Formalitäten erlaubt, jederzeit ein Grid Zertifikat (der Schlüssel zum Grid computing) zu erhalten. Neben der durch IGE in besonderem Maß hervortretenden Expertise im Bereich Globus Toolkit war das LRZ auch mit der D-Grid-Entwicklung D-MON zum VO-basierten Monitoring auf europäischer Ebene stark vertreten. Dies zeigte sich u.a. in der Prämierung eines D-MON-Posters auf dem 1. EGI Technical Forum in Amsterdam mit dem Best Poster Award. Und last but not least wurde unser LRZ-Grid-Portal (http://www.grid.lrz.de/), mit dem sich das LRZ seinen Kunden im Grid-Bereich präsentiert, regelmäßig aktualisiert und entwickelte sich zu einem festen Anlaufpunkt für wichtige Informationen aus dem Grid-Umfeld für Benutzer aus der ganzen Welt.

2.9 Managed Hosting für Hochschulstart.de Die „Stiftung für Hochschulzulassung“ (Stiftung öffentlichen Rechts) ist die Nachfolgerin der Zentralstel- le für die Vergabe von Studienplätzen. Im Auftrag der Kultusministerkonferenz wird die Stiftung ab 2011/12 ein bundesweites, zentrales „Dialogorientiertes Verfahren“ für die Vergabe von Studienplätzen für alle deutschen Hochschulen etablieren. Über eine neue Web-Applikation, die von der T-Systems Mul- timedia Systems GmbH erstellt wurde, können sich Bewerber an mehrere Hochschulen bewerben und die Hochschulen können effizient eine Bewerberauswahl treffen und zusagen. Das LRZ wurde von der Stiftung beauftragt, den Infrastrukturbetrieb und das Managed Hosting für die neue Applikation durchzuführen. Die Vorbereitungsarbeiten haben bereits im September 2010 begonnen, die Hosting-Vereinbarung läuft zunächst bis zum 31.03.2012. Mit dem Management der Applikation selbst wurde die T-Systems MMS beauftragt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 95

3 Entwicklungen und Tätigkeiten im Bereich des Kommunikations- netzes

3.1 Betrieb des Kommunikationsnetzes Das Münchner Wissenschaftsnetz (MWN) verbindet vor allem Standorte der Ludwig-Maximilians- Universität München (LMU), der Technischen Universität München (TUM), der Bayerischen Akademie der Wissenschaften (BAdW), der Hochschule München (HM) und der Hochschule Weihenstephan- Triesdorf miteinander. Es wird aber auch von anderen wissenschaftlichen Einrichtungen (u. a. Max- Planck-Gesellschaft, Fraunhofer-Gesellschaft, Kunst-Hochschulen, Museen) mit genutzt. Diese Standorte sind insbesondere über die gesamte Münchner Region (i. W. Münchner Stadtgebiet, Gar- ching, Großhadern/Martinsried und Weihenstephan) verteilt, es gibt aber auch weitere Standorte in Bay- ern. Derzeit sind an das MWN mehr als 510 als Unterbezirke bezeichnete Gebäudegruppen in mehr als 50 Arealen angebunden (siehe Abbildung 43) und es werden mehr als 79.500 Systeme versorgt. Die Lage von Standorten, die außerhalb des Münchner Stadtgebietes liegen, ist in der Abbildung nicht maßstabsge- treu dargestellt, sondern lediglich schematisch (in Himmelsrichtung) angedeutet. Die Größe der zu ver- sorgenden 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.000 angeschlossenen Endgeräten. Derzeit sind bereits über 50 Studentenwohnheime mit insgesamt knapp 12.000 Wohnheimplätzen am MWN angeschlossen.

Abbildung 43: Lage der Standorte im MWN

96 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 44: Standorte und Verbindungen im MWN

Jahresbericht 2010 des Leibniz-Rechenzentrums 97

Abbildung 44: (Fortsetzung) Standorte und Verbindungen im MWN

98 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Die Areale des MWN werden zu Dokumentationszwecken auch mit Kürzeln aus 1 oder 2 Zeichen (Un- terbezirke) benannt (eine Liste der Unterbezirke findet sich im MWN-Netzkonzept; http://www.lrz.de/services/netz/mwn-netzkonzept/MWN-Netzkonzept-2010.pdf). 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. 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 von der Deutschen Telekom und M-net langfristig 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. Netze mit einer geringen Zahl von Endgeräten werden überwiegend mit SDSL-Verbindungen (bis zu 10 Mbit/s) von M-net oder WLAN- Verbindungen auf Basis von IEEE 802.11a oder g (bis 54 Mbit/s) angebunden. • Die Switches eines Gebäudes oder einer Gebäudegruppe werden mittels Glasfaser zum allergröß- ten Teil mit 1 Gbit/s, aber auch mit 10 Gbit/s an die Router herangeführt. • In den Gebäuden geschieht die Anbindung von Datenendgeräten über Ethernet. Die Anbindung wird entweder über „Twisted-Pair“-Kupferkabel (100/1000 Mbit/s) und Lichtwellenleiter (100 Mbit/s oder zum Teil 1000 Mbit/s) oder zu einem sehr geringen Teil noch über Koaxial-Kabel (10 Mbit/s) realisiert. Server-Rechner werden fast immer mit 1 Gbit/s angeschlossen. • Die zentralen Rechner im LRZ (der Bundeshöchstleistungsrechner HLRB II, die Linux-Cluster, die Server des Backup- und Archivsystems und die zahlreichen Server-Systeme) sind untereinander größtenteils mit 10 Gbit/s mittels Switches verbunden. Diese Netzstruktur der zentralen Rechner ist über einen Router (10 Gbit/s) mit dem MWN-Backbone verbunden. • Im MWN wird ausschließlich das Protokoll TCP/IP benutzt. Abbildung 44 zeigt die für das Backbone-Netz verwendeten Strecken, deren Übertragungsgeschwindig- keiten und Endpunkte. Hieraus lässt sich die Ausdehnung des Netzes ablesen.

3.1.1 Backbone-Netz Aus Abbildung 45 ist die Struktur des Backbone-Netzes ersichtlich. Den Kern des Backbones bilden Cis- co Catalyst 6509 Switch/Router, die untereinander mit 10 GBit/s verbunden sind. Die Anbindung der Standorte erfolgt über LWL (Lichtwellenleiter). Das LRZ selbst ist über einen virtuellen Router (bestehend aus zwei 6509) an das Backbone angebunden. Alle Telekom-Glasfasern enden im zentralen Netz- raum des TUM-Stammgeländes. Die M-net Glasfasern enden im zentralen Netzraum des LMU- Stammgeländes. Das Router-Backbone bildet mehrere Zyklen, die der Redundanz dienen. Bis auf die Router in Wei- henstephan und an der Hochschule München haben alle eine mindestens doppelte Anbindung an das Backbone. Die Router unterhalten sich über Punkt-zu-Punkt Verbindungen mittels OSPF (Open Shortest Path First). Der Verkehr fließt von der Quelle zum Ziel über die Leitungen mit der kleinsten „Hop“- Anzahl (Weg, der über die wenigsten Router führt).

Jahresbericht 2010 des Leibniz-Rechenzentrums 99

Abbildung 45: Das MWN-Backbone-Netz

Ausnahmen von 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 usw.) zu erfüllen. Auch die Internet-Anbindung ist redundant ausgelegt. Es gibt zwei Anbindungen an das X-WiN und eine an M-net. Dabei ist die Hierachie so gewählt, dass die höchste Priorität die Internet-Anbindung 1 (siehe Abbildung 45) hat. Fällt diese aus, wird zur Internet-Anbindung 2 gewechselt. Erst wenn diese auch aus- fällt, wird der Weg über M-net gewählt. Die Umschaltung zwischen den Internet-Anbindungen wird automatisch über ein Routing-Protokoll (BGP, Border Gateway Protocol) gesteuert.

3.1.2 Gebäude-Netze In den Gebäuden existiert grundsätzlich eine strukturierte Verkabelung bestehend aus Kupferkabeln (Ka- tegorie 5/6, TP) oder Multimode-Lichtwellenleiter-Kabeln (50/125µ). Zu einem sehr geringen Anteil ist jedoch in sehr wenigen, noch zu sanierenden Gebäuden, immer noch Ethernet-Koax-Kabel (yellow cable) verlegt, wobei sich durch Sanierungsmaßnahmen der Umfang auch in diesem Jahr weiter verringert hat. Als aktive Komponenten zur Verbindung mit den Endgeräten werden (Layer-2-)Switches eingesetzt. Ende 2008 wurde eine Switch-Auswahl durchgeführt, bei der Switches der Firma HP Procurve gewonnen haben, da diese für die Anforderungen im MWN am besten geeignet sind. Derzeit sind vor allem Swit- ches der Serien HP ProCurve 4200 und 5400 im Einsatz. Andere stackable HP-Switches vom Typ HP ProCurve 2610 sind in kleineren Netzanschlussbereichen, vom Typ HP ProCurve 2910 für Serveran- schlüsse bei Instituten und im Rechnerwürfel des LRZ in Betrieb. Auch im Jahr 2010 wurden weitere HP ProCurve-Switches der Serien 4200 und 5400 aufgebaut. Kennzeichen dieser Netzkomponenten sind 10GE und anspruchsvolle Features wie QoS und Meshing. Alle diese Geräte sind modular aufgebaut und bieten über einzubauende Schnittstellenkarten Anschluss von bis zu 288 Geräten. Die Switches der Serien HP ProCurve 4000 und 2524 sind die derzeit ältesten Komponenten; sie wurden in 2010 bis auf 6 Geräte durch neuere Switches ersetzt. Für 2011 und die folgenden Jahre ist eine Ersetzung der nächstältesten

100 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Switch-Generation (HP ProCurve 4100) geplant, die z.T. bereits seit neun Jahren im Einsatz sind und hinsichtlich ihrer Leistungsfähigkeit und Funktionalität nicht mehr den heutigen Anforderungen entspre- chen. Für diese Ersetzung wurde im Jahr 2010 ein Großgeräteantrag gestellt, der Ende des Jahres genehmigt wurde. Zum Jahresende 2010 wurden vom LRZ insgesamt 1126 Switches betrieben. Einen Vergleich zu den Vorjahren zeigt Tabelle 29:

Ende 2010 Ende 2009 Ende 2008 Ende 2007 Ende 2006 Anzahl Switches 1126 990 914 843 780 davon HP-Switches 1125 989 914 843 738 davon Cisco-Switches 1 1 - - - davon 3Com-Switches - - - - 42 Anzahl TP-Ports 67.040 60.363 53.591 47.212 42.050 Anzahl Glasfaser-Ports 6.842 6.493 6.245 5.302 5.110 Tabelle 29: Switches im Jahresvergleich

Die Verteilung nach Switchtypen ist im Abschnitt 7.3.2 zu finden.

3.1.3 Rechenzentrumsnetz Das LRZ-Rechnergebäude besteht in Bezug auf das Datennetz im Wesentlichen aus drei verschiedenen Bereichen: dem Daten- und Archiv-Raum (DAR), in dem sich das Backup- und Archiv-System befindet, dem Netz- und Server-Raum (NSR), der den zentralen Mittelpunkt des Netzes, das Linux-Cluster sowie die Server mit den diversen Netzdiensten (Mail, Web usw.) beherbergt, sowie dem Höchleistungsrechner- raum (HRR). Das Datennetz in diesen drei Räumen ist den unterschiedlichen Anforderungen der Rech- nerlandschaft angepasst und ist wie folgt aufgebaut: DAR-Raum: Im Wesentlichen besteht das Netz in diesem Raum aus sieben Switches, die auf Grund der hohen Bandbreite, die das Backup- und Archiv-System benötigt, mit jeweils 10 Gbit/s bzw. 2 ∙ 10 Gbit/s an den zentralen Routern im NSR-Raum angeschlossen sind. Die älteren Backup-Server sind an diesen Switches mit jeweils 1 oder 2 Gbit/s (Trunk) angeschlossen, die neuen, in den Jahren 2009 und 2010 beschafften Server des LABS-Systems, mit 10 Gbit/s. NSR-Raum: Die Netzstruktur in diesem Raum besteht aus zwei Ebenen. Die erste Ebene bilden zwei Router, über die die LRZ-Gebäude mit dem MWN-Backbone verbunden sind, und zwei Core-Switches HP E8212, die mit jeweils 2 ∙ 10 Gbit/s an den Routern angeschlossen sind. Jeder dieser beiden zentralen Switches ist redundant aufgebaut mit zwei Management- und zwei Switch-Fabric-Modulen. Hinter den Core-Switches befinden sich ca. 80 Edge-Switches, die in die einzelnen Server-Racks eingebaut sind und die in der Regel mit jeweils 1 Gbit/s mit den Core-Switches verbunden sind, in einigen Fällen auch mit 10 Gbit/s. Die Server selbst sind in der Regel mit 1 Gbit/s an den Edge-Switches angeschlossen, wobei aus Redundanzgründen die Server teilweise an zwei verschiedenen Switches angebunden sind, so dass die Verfügbarkeit dieser Server auch bei einem Ausfall eines Switches erhalten bleibt. Eine Sonderstellung im NSR-Raum bildet das Linux-Cluster, das über eine eigene Infrastruktur mit dem Nexus7000 von Cisco und 34 daran angeschlossenen Edge-Switches verfügt. Am Nexus7000 sind sowohl die Edge-Switches als auch 150 Server direkt mit jeweils 10 Gbit/s angebunden. Um die Ausfallsicherheit weiter zu erhöhen, wurde Anfang 2010 zwischen den zentralen Komponenten (Router, Core-Switches und Edge-Switches für die VMware-Server) das Spanning-Tree-Protokoll aktiviert, so dass bei einem Ausfall einer Leitung oder einer Komponente der Datenverkehr ohne Unterbrechung weiterläuft. In diesen Spanning-Tree- Verbund wurden Ende 2010 auch die beiden Switches mit aufgenommen, an die die Server des Hoch- schulstart-Projekts (vgl. Abschnitt 2.9) angeschlossen sind. HRR-Raum: Der im Jahr 2006 installierte Bundeshöchstleistungrechner besteht aus insgesamt 16 Kno- ten, wobei jeder Knoten über zwei 10-Gbit-Netzwerkkarten verfügt. Diese Knoten sind mit jeweils einem Interface an zwei unterschiedlichen Routern angeschlossen. Einer dieser Router ist mit dem MWN verbunden, der andere verfügt über einen eigenen 10-Gbit-Anschluss an das WiN und wird ausschließlich für

Jahresbericht 2010 des Leibniz-Rechenzentrums 101 die Verbindung zu anderen Höchstleistungsrechnern im Rahmen des DEISA-Projektes verwendet. Neben den beiden Routern befinden sich auch noch einige Switches im HRR-Raum, die für die interne Vernet- zung des Höchstleistungsrechners (CXFS-Dateisystem, Management) verwendet werden.

Abbildung 46: Struktur des Rechenzentrumsnetzes

3.1.4 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-Gesellchaft, Verwaltung)  Realisierung von Testnetzen parallel (ATM-Pilotprojekte, Fiber-Channel-Kopplung von Speichernet- zen usw.) Im MWN werden aktuell auf 10 Verbindungen WDM-Systeme eingesetzt (siehe Tabelle 30). Die WDMs, die bisher für die Verbindung der verschiedenen Standorte der medizinischen Fakultät der TUM (Klinikum Rechts der Isar, Klinikum am Biederstein, Poliklinik für Präventive und Rehabilitative Sportmedizin und Schwabinger Krankenhaus) verwendet wurden, wurden im Jahr 2010 außer Betrieb genommen. Das medizinische Intranet zwischen den vier Standorten, das bisher über eigene WDM- Kanäle bewerkstelligt wurde, wird nun durch MPLS-Verbindungen über das MWN-Backbone realisiert. 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.

102 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

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) FH-München – ADVA FSP1 Anbindung zur Zentrale in der Lothstraße 34 7 externe Standorte von folgenden Standorten:  Pasing, Am Stadtpark 20  Lothstr. 21  Schachenmeierstr. 35  Karlstr. 6  Infanteriestr. 13  Dachauer Str. 98b TK-Anlagen-Kopplung Intranet der FH-Verwaltung

Tabelle 30: WDM-Verbindungen

3.1.5 WLAN (Wireless LAN) Die seit dem Jahr 2000 eingerichteten Zugangsmöglichkeiten über WLAN wurden 2010 weiter ausgebaut. Ende Dezember 2010 waren 1.462 (Vorjahr 1.324) WLAN Accesspoints in 221 (221) Gebäuden installiert. Die Accesspoints sind vor allem in öffentlichen Bereichen wie Hörsälen, Seminarräumen, Bib- liotheken und Foyers installiert. Das Angebot erfreut sich steigender Beliebtheit, zeitweise waren mehr als 4.500 gleichzeitig aktive Verbindungen aufgebaut. Insgesamt wurden fast 150.000 (148.658) verschiedene Geräte (MAC-Adressen) registriert, dabei am Tag über 15.000 (15.605 am 8.12.2010). Die am stärksten frequentierten Accesspoints waren mit bis zu 105 gleichzeitigen Verbindungen belegt. Bei Ver- anstaltungen lag der Wert noch höher. Um diesen Ansturm aufzufangen wurden gezielt einzelne, stark frequentierte Accesspoints (21 MSM310) durch die nächste Geräte-Generation (MSM422) ersetzt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 103

Abbildung 47: Anzahl aktiver WLAN-Verbindungen (5-Minuten-Mittel)

Abbildung 48: Entwicklung der Belegung über das Jahr 2010 (Tagesmittel)

In den Abbildungen zeigt der blaue bzw. dunklere Bereich den Anteil von Verbindungen mit IEEE 802.11g (54 Mbit/s). Als Zugangskomponenten werden Accesspoints der Typen MSM310 (CN320), MSM320 (CN330) und MSM422 (MAP625) der Firma HP (ehemals Colubris) eingesetzt. Mit den MSM422 werden auch Ver- bindungen mit IEEE 802.11n im 5GHz-Band angeboten, mit denen Geschwindigkeiten bis zu 300Mbit/s erreicht werden können. Im Laufe des Jahre 2010 wurden folgende Bereiche neu mit WLAN ausgestattet: HSWT Weihenstephan Gebäude 4373 HSWT Weihenstephan Gebäude 4377 HSWT Weihenstephan, Geb. 4173 HSWT Weihenstephan Geb. 4176 HSWT Weihenstephan Staudengarten, Geb. 4374 HM Dachauer Str. 98b, Bau E HM Schachenmeierstr. 35, Bau S LMU Großhadern, Wasserchemie, Verfügungsbau LMU Leopoldstraße 11a LMU Martinsried, Bio 2 LMU Schönfeldstr. 13 LMU Winzerer Str. 45 Monumenta Germaniae Historica in der Bay. Staatsbibliothek Monumenta Germaniae Historica, Kaulbachstr. 19 TUM Gabelsberger Str. 39 TUM Garching IAS TUM Karlstr. 45 TUM Leopoldstr. 139 TUM Nordgelände N2

104 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

TUM Nordgelände N3 TUM Schragenhofstr. 31 TUM Weihenstephan Botanik, Gebäude 218 TUM Weihenstephan Phytopathologie, Dürnast Geb. 232 TUM ZHS Geb. 2304 Zoologische Staatssammlung Im Laufe des Jahres 2010 wurde in folgenden Bereichen das WLAN wegen Umzug der Institute bzw. Aufgabe des Gebäudes abgebaut: LMU Georgenstr. 7 LMU Geschwister-Scholl-Platz 1, Philosophie LMU Schellingstraße 10 TUM Weihenstephan Gemüsebau Geb. 4201 Folgende Areale waren Ende des Jahres 2010 mit WLAN versorgt: (nur zum geringen Teil flächendeckend): Akademie der Bildenden Künste Bayerische Akademie der Wissenschaften Bayerische Staatsbibliothek Deutsches Museum Exzellenzcluster Universe HSWT Weihenstephan Bioinformatik, Altes Bauamt HSWT Weihenstephan Forstwirtschaft HSWT Weihenstephan Landpflege, Kustermannhalle HSWT Weihenstephan Löwentorgebäude HSWT Weihenstephan Pappelallee HSWT Weihenstephan Geb. 4172 HSWT Weihenstephan Gebäude 4373 HSWT Weihenstephan Gebäude 4377 HSWT Weihenstephan, Geb. 4173 HSWT Weihenstephan Bibliothek HSWT Weihenstephan Geb. 4176 HSWT Weihenstephan Staudengarten, Geb. 4374 HSWT Weihenstephan Landtechnik, Geb. 4383 HSWT Triesdorf, 4 Gebäude HM Dachauer Str. 98 HM Dachauer Str. 98b, Bau E HM Lothstr. 34 HM Infanteriestr. 14 HM Lothstr. 13 Mensa und Bibliothek HM Karlstr. 6 HM Lothstr. 21 HM Pasing, Am Stadtpark 20 HM Schachenmeierstr. 35, Bau S Internationales Begegnungszentrum, Amalienstr. 38 Hochschule für Philosophie Hochschule für Fernsehen und Film, Frankenthalerstr. 23 LRZ Garching

Jahresbericht 2010 des Leibniz-Rechenzentrums 105

LMU Akademiestr. 1 LMU Amalienstr. 17 LMU Amalienstr. 54 LMU Amalienstr. 83 LMU Edmund Rumpler Str. 9 LMU Edmund-Rumpler-Str. 13 LMU Frauenlobstr. 7a LMU Garching, Beschleuniger-Laboratorium LMU Garching, Physik-Departement Coulombwall LMU Georgenstr. 11 LMU Geschwister-Scholl-Platz 1 LMU Geschwister-Scholl-Platz 1, Adalberttrakt LMU Geschwister-Scholl-Platz 1, Bücherturm LMU Geschwister-Scholl-Platz 1, Hauptgebäude LMU Geschwister-Scholl-Platz 1, Segafredocafe LMU Giselastraße 10 LMU Großhadern, Chemie/Pharmazie LMU Großhadern, Genzentrum LMU Großhadern, Wasserchemie, Verfügungsbau LMU Hohenstaufenstr. 1 LMU Königinstraße 12 LMU Königinstraße 16 LMU Kaulbachstr. 37 LMU Kaulbachstr. 45 LMU Kaulbachstr. 51a LMU Katharina-von-Bora-Straße 10 LMU Konradstraße 6 LMU Leopoldstraße 3 LMU Leopoldstraße 11a LMU Leopoldstraße 13, Haus 1, Geb. 0601 LMU Leopoldstraße 13, Haus 2, Geb. 0602 LMU Leopoldstraße 13, Haus 3, Geb. 0603 LMU Ludwigstr. 14 LMU Ludwigstr. 25 LMU Ludwigstr. 27 LMU Ludwigstr. 28 LMU Ludwigstr. 29 LMU Ludwigstr. 31 LMU Ludwigstr. 33 LMU Luisenstr. 37 LMU Martinsried, Bio 2 LMU Martinsried, Biozentrum LMU Martinsried Mensa LMU Martiusstr. 4 LMU Menzinger Straße 67 LMU Oberschleißheim, Klauentierklinik

106 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

LMU Oberschleißheim, Schleicherbau LMU Oberschleißheim, Versuchsgut St. Hubertus LMU Oberschleißheim, Vogelklinik LMU Oettingenstr. 67 LMU Oettingenstraße 67 Baracke LMU Prof. Huber Platz 2, Geb. 420 LMU Vestibülbau (Prof. Huber Platz), Geb. 421 LMU Vestibülbau Turm (Außenbereich), Geb. 421 LMU Richard-Wagner Str. 10 LMU Schönfeldstr. 13 LMU Schackstr. 4 LMU Schellingstraße 3 Rückgebäude LMU Schellingstraße 3 Vordergebäude LMU Schellingstraße 4 LMU Schellingstraße 5 LMU Schellingstraße 7 LMU Schellingstraße 9 LMU Schellingstraße 12 LMU Seestr. 13 LMU Sternwarte Laplacestr. 16 LMU Sternwarte Scheinerstr. 1 LMU Theresienstraße 37 LMU Theresienstraße 39 LMU Theresienstraße 41 LMU Veterinärstraße 1 LMU Veterinärstraße 5 LMU Veterinärstraße 13 LMU Winzerer Str. 45 LMU ZAAR Destouchesstr. 68 LMU Zentnerstr. 31 Monumenta Germaniae Historica in der Bay. Staatsbibliothek Monumenta Germaniae Historica, Kaulbachstr. 19 Musikhochschule Arcisstr. 12 Musikhochschule Barer Str. 34 Musikhochschule Gasteig Musikhochschule Luisenstr. 37a Olympisches Dorf Mensa Pinakotheken Freifläche Nord TUM Barer Str. 21 TUM Deutsches Museum TUM Eichenau TUM Gabelsberger Str. 39 TUM Gabelsberger Str. 45 TUM Gabelsberger Str. 49 TUM Garching Chemiegebäude TUM Garching Exzellenzcluster Universe

Jahresbericht 2010 des Leibniz-Rechenzentrums 107

TUM Garching IAS TUM Garching Maschinenbau TUM Garching Medizintechnik TUM Garching Mensa TUM Garching Physikdepartment TUM Garching Physikdepartment II TUM Garching Physikdepartment E18 Neutronenhütte TUM Garching Umformtechnik und Gießereiwesen TUM Garching Wassergütewirtschaft TUM Iffeldorf Limnologische Station TUM Karlstr. 45 TUM Katholische Hochschulgemeinde TUM Klinikum rechts der Isar Teilbibliothek TUM Klinikum rechts der Isar Hörsäle TUM Klinikum rechts der Isar Lern- und Trainingszentrum TUM Leopoldstr. 139 TUM Lothstraße 17 TUM Mensa TUM Nordgelände N1 TUM Nordgelände N2 TUM Nordgelände N3 TUM Nordgelände N4 TUM Nordgelände N5 TUM Nordgelände N8 TUM Nymphenburger Str. 39 TUM Obernach Versuchsanstalt für Wasserbau TUM Pasing Grundbau und Bodenmechanik TUM Richard-Wagner Str. 18 TUM Schellingstraße 33 TUM Schragenhofstr. 31 TUM Stammgelände Präsidialbereich TUM Stammgelände TUM Stammgelände Audimax TUM Stammgelände Cafeteria TUM Stammgelände Architekturfakultät TUM Stammgelände Architekturmuseum TUM Stammgelände Bauinformatik TUM Stammgelände Fak. Bauingenieurwesen TUM Stammgelände Bauklimatik und Haustechnik TUM Stammgelände Betriebswirtschaft TUM Stammgelände Bibliothek TUM Stammgelände Bildnerisches Gestalten TUM Stammgelände Datenverarbeitung TUM Stammgelände Datenverarbeitung Eikon-Turm TUM Stammgelände Entwurfsautomatisierung TUM Stammgelände Fachschaft Architektur

108 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

TUM Stammgelände Geodäsie TUM Stammgelände Hydraulik und Gewässerkunde TUM Stammgelände Kommunikationsnetze TUM Stammgelände LMU Geographie TUM Stammgelände STARTmunich e.V. TUM Stammgelände Theresianum TUM Stammgelände Wasserbau + Wasserwirtschaft TUM Stammgelände Wirtschaftswissenschaften TUM Versuchsgut Grünschwaige TUM Weihenstephan Altes Molkereigebäude TUM Weihenstephan Bibliotheksgebäude TUM Weihenstephan Biologie der Lebensmittel TUM Weihenstephan Biowissenschaften TUM Weihenstephan Bodenkunde, Gebäude 4217 TUM Weihenstephan Botanik, Gebäude 218 TUM Weihenstephan Botanik, Geb. 219 TUM Weihenstephan Braufakultät, Gebäude 4112 TUM Weihenstephan Chemie + Biochemie, Geb. 4212 TUM Weihenstephan Dürnast, Geb. 4235 TUM Weihenstephan Ernährungslehre Geb. 4107 TUM Weihenstephan Fischbiologie TUM Weihenstephan FML Geb. 4124 TUM Weihenstephan Forstbau Geb. 4277 TUM Weihenstephan Geb. 4101 TUM Weihenstephan Geb. 4109 TUM Weihenstephan Freigelände zu 4214 TUM Weihenstephan Geb. 4215 TUM Weihenstephan Genetik Geb. 4223 TUM Weihenstephan Grünlandlehre, Gebäude 4105 TUM Weihenstephan Hörsaalgebäude, Geb. 4102 TUM Weihenstephan Landtechnik, Geb. 4210 TUM Weihenstephan Lebensmittelchemie Geb. 4298 TUM Weihenstephan Lebensmitteltechnikum Geb. 4213 TUM Weihenstephan Lebensmittel Verfahrenstechnik Geb. 4126 TUM Weihenstephan Mensa, Geb. 4216 TUM Weihenstephan Physik, Geb. 4212 TUM Weihenstephan Phytopathologie, Dürnast Geb. 232 TUM Weihenstephan Tierernährung Geb. 4308 TUM Weihenstephan Tierwissenschaften TUM Weihenstephan Geb. 4111 TUM Weihenstephan Geb 4113 TUM Weihenstephan Hörsaalgebäude, Geb. 4214 TUM Winzerer Str. 45 TUM ZHS BFTS TUM ZHS Geb. 2301 TUM ZHS Geb. 2303

Jahresbericht 2010 des Leibniz-Rechenzentrums 109

TUM ZHS Geb. 2304 TUM ZHS Geb. 2305 TUM ZHS Geb. 2306 Walther-Meißner Institut Wissenschaftszentrum Straubing Zentralinstitut für Kunstgeschichte, Katharina-von-Bora-Straße 10 Zoologische Staatssammlung

3.1.6 Wesentliche Netzänderungen im Jahr 2010 Im Jahr 2010 gab es folgende in chronologischer Reihenfolge aufgeführte wesentliche Netzveränderun- gen: 08.01.2010 Anschluss des Fraunhofer Instituts für Sichere Informationstechnologie (SIT) am Business Campus in Garching mit 1 Gbit/s 04.02.2010 Anschluss der TU-Mathematik im Business-Campus in Garching mit 1 Gbit/s (gemeinsam genutzter Anschluss mit Fraunhofer SIT) 10.02.2010 Anschluss des TUM Exzellenzzentrums in Garching mit 1 Gbit/s 18.02.2010 Anschluss des Studentenwohnheims Gregorianum mittels aDSL mit 18 Mbit/s 26.02.2010 Bandbreitenerhöhung für die Hochschule für Musik und Theater im Gasteig auf 100 Mbit/s 03.03.2010 Anschluss des TUM Gebäudes Karlstr. 45 mit 1 Gbit/s 18.03.2010 Anschluss des TUM Gebäudes 4115 in Weihenstephan über das Gebäude 4102 (Bibliothek) 28.04.2010 Anbindung der Container an der Triton-Hütte des Beschleunigerlabors in Gar- ching 25.05.2010 Umzug des Zentrum für Arbeitsbeziehungen und Arbeitsrecht (ZAAR) von der Infanteriestr. 8 in die Destouchestr. 68 17.06.2010 Anschluss des TUM Gebäudes Guerickestr. 25 mit 1 Gbit/s 05.07.2010 Anschluss des Studentenwohnheims Türkenstr. 58 mit 1 Gbit/s 15.07.2010 Anschluss des LMU Gebäudes Fraunhoferstr. 12 in Planegg mit 1 Gbit/s 16.07.2010 Anbindung der Container der TUM Fischbiologie in Weihenstephan über eine Funkbrücke 15.08.2010 Anschluss des Studentenwohnheims Student Living Center (SLC) Haus II und Haus III über privat verlegte Glasfasern 17.08.2010 Upgrade der Anbindung des Gebäudes FCP-A am Genzentrum in Martinsried auf 10 Gbit/s 07.09.2010 Upgrade der Anbindung LMU Gebäude Amalienstr. 54 auf 10 Gbit/s 14.10.2010 Abbau einer Funkbrücke und Anbindung über privat verlegte Glasfaser; Gebäude 4123 in Weihenstephan 29.10.2010 Anschluss des LMU Gebäudes Schönfeldstr. 13 über eine privat verlegte Glasfaser mit 1 Gbit/s 29.10.2010 Anschluss des Kinderhauses am Campus Garching über eine privat verlegte Glas- faser mit 1 Gbit/s 18.11.2010 Redundante Anbindung des Zentrum für Nanotechnologie und Nanomaterialien in Garching über eine privat verlegte Glasfaser

110 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

25.11.2010 Anschluss des TUM Institute für Advanced Studies (IAS) in Garching mit 1 Gbit/s 20.12.2010 Anschluss des Physik Untergrundlabors in Garching über eine privat verlegte Glasfaser

3.1.7 Netzausbau (Verkabelung) Mit NIP (Netzinvestitionsprogramm in Bayern) wurde zwar eine flächendeckende Vernetzung erreicht, diese ist jedoch an der TUM in München und Garching noch zu einem geringen Teil in Koax ausgeführt. Bis Ende 2008 sollte diese Koax-Verkabelung durch eine strukturierte Verkabelung (Kupfer oder Glasfa- ser) ersetzt werden. Das Ziel wurde aber nicht erreicht, da einige Gebäude noch auf eine endgültige Gene- ralsanierung warten bzw. es unklar ist, wie sie später genutzt werden.

3.1.7.1 TU München Im Bereich der TU München (ohne Weihenstephan) konnten die im Folgenden aufgeführten Gebäude im Jahr 2010 mit einer strukturierten Verkabelung versehen werden. Innenstadt Schragenhofstrasse 31 (Motorenlabor) Derzeit gibt es noch Koax in Bau 0503, 0106 (N6) und 5402 (CH2), das aber im Rahmen anderer Maß- nahmen ersetzt werden soll.

3.1.7.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 4-drahtiger Anschluss [Cable- sharing] oder Installation von Kategorie 5-Kabeln bzw. Anschlusskomponenten). Dies betrifft 28 Ge- bäude (NIP V). Die Kosten in Höhe von 18,4 Mio. € wurden vom Landtag genehmigt. Im Rahmen des Konjunkturprogramms werden im ersten Bauabschnitt sechs Standorte bis August 2011 nachgerüstet werden: M-Bogenhausen Universitäts-Sternwarte (Neuverkabelung bereits 2009 abgeschlossen) M-Lehel Oettingenstr. 67 (Informatik, Kommunikationswissenschaft usw.) M-Schwabing Leopoldstr. 13 Haus 1 – 3 (Psychologie+Pädagogik) M-Maxvorstadt Theresienstr. 37 (Physik, Meteorologie) M-Maxvorstadt Theresienstr. 39 (Mathematik) M-Maxvorstadt Theresienstr. 41 (Geo- und Umweltwissenschaften) Die verbleibenden 22 Gebäude werden voraussichtlich ab 2012 im Rahmen des zweiten Bauabschnittes der NIP V-Maßnahme mit einer Verkabelung der Kategorie 6a modernisiert.

3.1.7.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).

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

3.1.8 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,

Jahresbericht 2010 des Leibniz-Rechenzentrums 111 für die Netznutzung werden aber keine Gebühren verlangt. Zum Jahresende 2010 sind 12.503 Wohn- heimplätze (im Jahr 2009: 12.302) in 59 (56) Heimen an das MWN angeschlossen, davon 24 (20) über eine Glasfaserleitung (LWL) mit 100 MBit/s, 15 Heime über Funkstrecken, 10 (11) Heime über DSL und 10 Heime über 100 MBit/s Laserlinks. Die nachfolgende Tabelle zeigt die Wohnheime, die Ende 2010 am MWN angeschlossen sind:

Name Adresse Träger Plätze Anschluss

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

Studentenviertel auf dem Helene-Mayer-Ring 9 Studentenwerk 1801 LWL zu ZHS Oberwiesenfeld

Kreittmayrstraße Kreittmayrstraße 14 Studentenwerk 45 Funk zu FH (Erzgießereistr. 14)

Adelheidstraße (mit Deutschkurse für Aus- Adelheidstraße 13 Studentenwerk 374 Laser zu FH Dachauerstraße länder)

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

Oberschleißheim Oberschleißheim Studentenwerk 171 LWL zu Rinderklinik Am Schäferanger 9-15

Verein evangelischer Funk zu Studentenstadt, Georg-Lanzenstiel-Haus Kieferngartenstraße 12 135 Studentenwohnheime LWL zu MPI (IMC)

Ökumenisches Studenten- Verein evangelischer Steinickeweg 4 70 Funk zu TUM-Uhrenturm heim Studentenwohnheime

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

Studentenwohnheim Ge- Studentenwohnheim Ge- Steinickeweg 7 227 SDSL M-net 2 MBit, Linux-Router schwister Scholl schwister Scholl e.V.

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

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

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

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

Hedwig Dransfeld Hedwig Dransfeld Allee Studentenwerk 100 100 MBit/s Laserlink Allee 7

SDSL M-net für Uniradio Stettenkaserne Schwere Reiter Str. 35 Studentenwerk 244 100 MBit/s Laserlink zur FH in der Dachauerstraße

Heidemannstraße Paul-Hindemith-Allee 4 Studentenwerk 310 100 MBit/s Laserlink

100 MBit/s Richtfunk zur Studenten- Felsennelkenanger Felsennelkenanger 7-21 Studentenwerk 545 stadt, von dort per LWL zu MPI

100 MBit/s Laserlink mit integriertem Heiglhofstraße Heiglhofstraße 64/66 Studentenwerk 415 2 MBit-Funk-Backup

100 MBit-Laserlink mit integriertem 2 Sauerbruchstraße Sauerbruchstraße Studentenwerk 259 MBit-Funk-Backup

Garching Garching I Studentenwerk 110 100 MBit-Laserlink zu TU-Feuerwehr Jochbergweg 1-7

Garching 100 MBit-Laserlink zu TU- Garching II Studentenwerk 112 Enzianstraße 1, 3 Heizkraftwerk

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

Maschinenwesen Garching Studentenwerk 4 SpeedVDSL

112 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Ehemalige Hausmeisterwoh- nung

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

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

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

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

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

Roncallicolleg Roncalli-Colleg Nymphenburger Str. 99 125 Funk zur FH Schachenmeierstraße (+ KHG) Prof. Fuchtmann

Bayerischer Lehrer- und BLLV-Wohnheim Cimbernstraße 68 Lehrerinnen- 160 SDSL M-net verband (BLLV)

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

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

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

Wohnheim Richard Wag- Richard-Wagner-Str. 16 Ingeborg van-Calker Stiftung 40 LWL zu Richard Wagner Str. 18 nerStr. 16

Evangelische Studentenwohn- Hochschulhaus Garching Enzianstr. 5 65 Funk zu TU-Feuerwehr heime

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

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

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

Orden der Armen Schul- Am Anger II Unterer Anger 17 83 M-net SDSL schwestern

Wohnheim Stiftsbogen Schröfelhofstraße 4 Studentenwerk 580 LWL zu Campus Großhadern

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

Magdalena-Lindt-Heim Kaulbachstr. 25 Ev. Waisenhausverein 93 LWL zu Staatsbibliothek

Marie-Antonie-Haus Kaulbachstr. 49 Studentenwerk 94 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

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

Newman-Haus Kaulbachstr. 29 Newman-Verein 68 Funk über Kaulbachstr. 29

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

Johann-Michael-Sailer-Haus Preysingstr. 83d Katholisches Ordinariat 26 LWL zu Ordinariat

Heinrich-Groh-Str. Heinrich-Groh-Str. 17 Studentenwerk 59 LML über Amalienstr. 17

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

Josef-Wirth-Weg 19 Josef-Wirth-Weg 19 Studentenwerk 190 100 MBit/s Laserlink

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

Jahresbericht 2010 des Leibniz-Rechenzentrums 113

Musikhochschule Musik und Theater

Oskar von Miller Forum Oskar von Miller Ring 25 Oskar von Miller Forum 80 LWL über Amalienstr. 17

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

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

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

59 Wohnheime Summe insgesamt 12.503

3.2 Dienste Neben der physischen und technischen Infrastruktur werden innerhalb des MWN auch viele unterstützen- de Dienste angeboten und betrieben. Neben dem Übergang ins globale Internet und verschiedenen Zu- gangsmöglichkeiten aus anderen Netzen ins MWN (z.B. über VPN, UMTS) werden auch mobile Nutzer im MWN mittels WLAN angebunden. Für Veranstaltungen und Konferenzen gibt es Konzepte, um einen Zugang ins Internet oder ins MWN zu realisieren. Der reisende Wissenschaftler wird durch eduroam, und einem damit verbundenen, sehr einfachem Zugang zum Netz unterstützt. Daneben werden Basisdienste wie Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Service Load Balan- cer (SLB), Proxies und Zeitschriftenzugänge sowie die nächste Generation des IP-Protokolls (IPv6) angeboten. Außerdem betreibt das LRZ eine Voice over IP (VoIP) Anlage für die Telefonie. Diese unterstüt- zenden Netzdienste werden im Folgenden vorgestellt.

3.2.1 Wählzugänge (Modem/ISDN) Die Anzahl der Wählverbindungen hat sich im Laufe des Jahres 2010 weiter verringert. Die Anzahl der Telekom-Kunden ging auf ca. 80 (2009: 160) zurück, die der M-net-Kunden stagnierte bei ca. 70. Abbildung 49 zeigt für das zweite Halbjahr 2010 die maximale Anzahl gleichzeitig aktiver Verbindungen pro Woche, aufgeschlüsselt nach den jeweiligen Rufnummern.

Abbildung 49: Maximale Anzahl von Verbindungen pro Rufnummer des zweiten Halbjahres 2010

Der Wochenüberblick zeigt bei den M-net-Verbindungen das Ansteigen werktags um 18 Uhr (vgl. Abbil- dung 50).

114 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 50: Verteilung der Modem/ISDN-Verbindungen im Wochenüberblick

Ü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 oder Eduroam selbst verwalten. Zum Jahresende 2010 waren 55 Radiuszonen konfiguriert. Eine Auflistung der Radiuszonen zeigt Tabelle 31: Zonenbezeichnung Institut aci.ch.tum Lehrstuhl für Anorganische Chemie TUM ads.mwn.de Kennungen im MWN-ADS binfo.wzw.tum.de Genome oriented Bioinformatics bl.lmu Beschleunigerlabor der TU und der LMU München bsbmuenchen Bayerische Staatsbibliothek campus.lmu.de Internet und virtuelle Hochschule (LMU) cicum.lmu Department Chemie LMU cip.informatik.lmu Institut für Informatik der LMU cipmath.lmu Mathematisches Institut LMU eduroam.mwn.de Eduroam-Nutzer edv.agrar.tum Datenverarbeitungsstelle der TU in Weihenstephan fhm.de Hochschule München fh- 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 ibe.lmu Institut für medizinische Informationsverarbeitung, Bio- ikom.tum Fachschaft Elektro- & Informationstechnik info.tum Informatik TUM lkn.tum Lehrstuhl für Kommunikationsnetze lmu.de Verwaltung LMU lmupsychologie Depart für Psychologie lpr.tum Lehrstuhl für Prozessrechner lrz.de LRZ-Mitarbeiter math.lmu 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

Jahresbericht 2010 des Leibniz-Rechenzentrums 115

meteo.lmu Meteorologisches Institut LMU mytum.de Mitarbeiter und Studenten der TUM org.chemie.tum Institut für Organische Chemie und Biochemie Lehrstuhl 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 regent.tum Lehrstuhl für Rechnergestütztes Entwerfen rz.fhm Rechenzentrum der FH München (Studenten) staff.fhm Rechenzentrum der FH München (Mitarbeiter) studext Studentenrechner LRZ (andere) studlmu Studentenrechner LRZ (LMU) tec.agrar.tum Institut für Landtechnik Weihenstephan tphys.lmu Institut Theoretische Physik 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 zi.lmu Zoologisches Institut der LMU zikgwpa Zentralinstitut für Kunstgeschichte zv.tum Zentrale Verwaltung TUM Tabelle 31: Radiuszonen im MWN

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

3.2.2.1 Technik Die VPN-Hardware besteht aus vier Appliances vom Typ „Adaptive Security Appliances ASA5540“ und einer Appliance vom Typ „VPN-Concentrator 3030“ der Firma Cisco. Der VPN-Concentrator 3030 dient für die Anbindung von externen Einrichtungen außerhalb des MWN über IPsec LAN-to-LAN Tunnel. Die vier ASA-Appliances sind zu einem VPN-Cluster zusammengefasst. Dieser VPN-Cluster wird von IPsec-Clients unter der Adresse ipsec.lrz.de, von SSL-VPN-Clients unter der Adresse asa-cluster.lrz.de angesprochen. Die Nutzer werden beim Anmelden mit der am geringsten ausgelasteten Appliance verbunden. Der VPN-Concentrator 3030 ist über zwei 100 MBit/s Anschlüsse (öffentlich und privat) angeschlossen. Die vier ASA5540 sind jeweils mit 1GBit/s angeschlossen. Die verfügbare Bandbreite für ver- schlüsselte Verbindungen (AES/3DES) beträgt 50 MBit/s beim VPN-Concentrator 3030 und 350 MBit/s pro ASA5540. Authentifizierung, Autorisierung der Nutzer sowie Accounting werden über das RADIUS- Protokoll abgehandelt.

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

116 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Nutzern erweiterte Möglichkeiten bietet. Diese Clients sind inzwischen in den Standarddistributionen wie z.B. Debian, SuSE und Ubuntu enthalten.

3.2.2.3 Telearbeitsplätze von LRZ-Mitarbeitern Mitarbeiter 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 aufbaut. Über diese Verbin- dung, 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. Laptop 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.

3.2.2.4 Entwicklung des Datenverkehrs über die VPN-Server Im Monat November, dem Monat mit dem höchsten Datenaufkommen, stieg der Durchsatz im Vergleich zum Vorjahr um 45%. In Spitzenzeiten waren bis zu 3200 Nutzer parallel angemeldet, täglich wurden bis zu 30.000 Verbindungen aufgebaut. Der im Jahr 2009 eingeführte SSL-VPN Client (Cisco AnyConnect) hat inwischen einen Anteil von 30% aller Verbindungen erreicht. Folgende Aufteilung nach Betriebsystemen ergab sich bei den IPsec-Verbindungen (Referenzmonat No- vember): Linux 8%, iOS 15%, Mac OS X 29%, Windows 49%. Bei den SSL-VPN Verbindungen ist eine Aufschlüsselung nach Betriebsystemen nicht möglich.

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

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

40 Ausgehend 30 Eingehend 20 Gesamt

0 2005 2006 2007 2008 2009 2010

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

Jahresbericht 2010 des Leibniz-Rechenzentrums 117

3500 3000 2500 2000 1500 1000 500 0 31.12 31.01 28.02 31.03 30.04 31.05 30.06 31.07 31.08 30.09 31.10 30.11 31.12

Abbildung 52: Anzahl der gleichzeitig an den VPN-Servern angemeldeten Nutzer

40,000 Eingehend 35,000 Ausgehend 30,000 Summe

25,000

20,000

15,000

10,000

5,000

0,000

Abbildung 53: Monatliches Datenvolumen der VPN-Server in Gigabyte im Jahr 2010

3.2.3 DFN-Roaming Das LRZ nimmt seit Anfang 2005 am DFN-Roaming-Dienst des DFN (Deutsches Forschungsnetz) Ver- eins teil. Damit ist es den Wissenschaftlern möglich, mittels einer vorhandenen Kennung ihrer Heimat- Hochschule einen einfachen Zugang ins Internet zu erhalten, wenn sie sich im Bereich des MWN aufhal- ten. Als Zugangspunkte dienen die vorhandenen WLAN-Accesspoints (an praktisch allen Standorten). In der erweiterten Form mit der SSID 'eduroam' statt '802.1X' ist nicht nur das Roaming innerhalb Deutschlands, sondern auch in vielen Länden Europas und in Australien möglich. Auch in den USA be- ginnen sich die ersten Universitäten zu beteiligen. Die SSIDs 'eduroam' und '802.1X' werden auf fast allen Accesspoints im MWN zur Verfügung gestellt. Nur an 2 Standorten mit je einem Accesspoint, die über DSL-Leitungen angeschlossen sind, war es aus technischen Gründen nicht möglich, das DFN-Roaming anzubieten. Neben der bisher im Bereich des MWN obligaten Methode TTLS/PAP wurde 2010 auch die Authentifi- zierung über PEAP/ MSCHAPv2 ermöglicht. Dies wurde erforderlich, da Windows 7 Systeme diesen Dienst nur mit kostenpflichtiger Zusatzsoftware TTLS/PAP nutzen können. Außerdem wurde der von vielen Systemen bisher benutzte Client (SecureW2) nicht mehr kostenfrei angeboten. Aus diesen Gründen

118 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes wurde ein eigenes Windows-basiertes Directory für Eduroam mit Anbindung an das Identity- Management-System des LRZ eingerichtet. Mittels PEAP können nun Systeme mit Windows 7 und viele Smartphones Eduroam ohne zusätzliche kostenpflichtige Software nutzen. Das nachfolgende Bild zeigt die Benutzungs-Statistik für das 802.1X/eduroam.

Abbildung 54: Anzahl der Eduroam-Nutzer im Jahr 2010

3.2.4 Unterstützung von Veranstaltungen Das LRZ richtet für Veranstaltungen im Münchner Wissenschaftsnetz (MWN) bei Bedarf ein spezielles Netz ein, damit die Tagungsteilnehmer das Netz ohne besondere Authentifizierung nutzen können. Hier- bei wird davon ausgegangen, dass die Nutzer dieses Netzes nicht unbedingt aus dem Kreise der Münch- ner Hochschulen stammen, sondern auch Firmen u. dgl. das Internet und das MWN ohne spezielle Vor- kehrungen (ohne VPN-Client-Installation, ohne Validierung) nutzen sollen. Eine Anmeldung und die bei frei zugänglichen Netzanschlüssen ansonsten obligatorische Verwendung eines VPN-Zugangs werden hier nicht gefordert. Diese „offene" Konfiguration bleibt auf den Zeitraum und den Ort der Veranstaltung begrenzt. Der Zu- gang ist drahtlos (WLAN nach IEEE 802.11b/g/n) möglich. Nur in Ausnahmefällen werden feste Netzan- schlussdosen (100 Mbit/s LAN) zur Verfügung gestellt. Für Geräte, die keine eingebaute Funkschnittstel- le haben, werden vom LRZ Wireless-Client-Bridges (WCB) bereitgestellt. Die Realisierbarkeit des Dienstes hängt aber von der vorhandenen Infrastruktur ab, nicht in allen Gebäuden und Räumen ist eine solche Möglichkeit gegeben. Allerdings ist dies meistens der Fall. Der Zugang wird seit 2006 bevorzugt per WLAN zur Verfügung gestellt. 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. Für reisende Wissenschaftler gibt es außerdem die Möglichkeit, sich mittels eduroam (vgl. Abschnitt 3.2.3) mit der Kennung ihrer Heimat-Universität im Netz anzumelden und verschlüsselt zu kommunzie- ren. In den letzten Jahren wird dieser Dienst vermehrt auch bei Veranstaltungen genutzt. Das heißt, diese sichere Art der Kommunikation setzt sich immer mehr durch. 2010 wurden 215 Veranstaltungen unterstützt (42 mehr als im Vorjahr).

Jahresbericht 2010 des Leibniz-Rechenzentrums 119

Datum Veranstaltung Datum Veranstaltung

10.06.2010-11.06.2010 10JahreVHB-2010 02.08.2010-03.08.2010 IPComm-2010

25.11.2010-26.11.2010 10_Jahre_VHB 03.12.2010-05.12.2010 ISARMUN-2010

19.06.2010-24.06.2010 22-IKOM-2010 28.10.2010-31.10.2010 ISMA-2010

22.07.2010-23.07.2010 ADG-2010 04.03.2010-05.03.2010 ISO20K-Maerz2010

11.10.2010-13.10.2010 ASCENS-2010 12.07.2010,25.07.2010-28.07.2010 ISSAC-2010

23.11.2010 Abschlusskolloquium_SFB453-2010 23.02.2010-24.02.2010 IVK2010

13.04.2010-16.04.2010 Adipositas-2010 02.07.2010 Ideenboerse-LfP-2010

20.09.2010 Agrarwissenschaftliches_Symposium-2010 14.06.2010 ImmerSence-Juni2010

05.10.2010-09.10.2010 Alpenforum-2010 20.07.2010 InKoMBio-2010

15.02.2010-17.02.2010 Annex54-2010 21.10.2010 Infoblox-Meeting

02.11.2010 Apple_on_Campus-Event2010 03.12.2010-05.12.2010 Integration_hoergeschaedigter_Kinder-Dez2010

25.11.2010-26.11.2010 Architektur-Konferenz-Dez2010 14.04.2010-15.04.2010 Intel_Round_Tabelle-April2010

18.11.2010 Autodesk-Nov2010 22.03.2010-23.03.2010 Interact-2010

23.09.2010 BRZL-AK-2010 11.05.2010 International_Day_HM-2010

15.04.2010 BULL-April2010 29.11.2010-03.12.2010 Internationale-Woche-TUM-2010

18.11.2010-19.11.2010 Biofilm-Nov2010 24.11.2010 Internationaler_Tag-NOV2010

15.04.2010-19.04.2010 Bright-2010 22.08.2010-29.08.2010 Isotopeschool-08-2010

02.12.2010 Britische-Hochschulmesse-2010 04.10.2010-08.10.2010 Iterative-Gleichungssystemloeser-und-Parallelisierung

21.05.2010 Bull-05-2010 01.12.2010 JOBcon-Finance-2010

10.06.2010 CC-Fachtagung-FK07-2010 07.05.2010 KIT-Mai2010

15.03.2010 CISCO-Besprechung 21.09.2010,23.09.2010-24.09.2010 Kanzlertagung-WZW-2010

12.10.2010-13.10.2010 COIN-Okt-2010 17.11.2010 KinderUni-2010

18.03.2010-19.03.2010 COST_Action_D41-2010 11.02.2010-22.02.2010 Klimagerechtes_Bauen-2010

21.10.2010-23.10.2010 CRC-Symposium-2010 07.09.2010 LERU-2010

16.08.2010 Chemistry-meets-Biology-2010 26.07.2010-27.07.2010,29.07.2010-30.07.2010 LSR-SummerSchool-2010

06.12.2010 Chinese-Delegation-Dez2010 17.11.2010,21.11.2010 Landesastenkonferenz-Nov2010

02.06.2010 Cisco_Ironport-Juni2010 14.10.2010-15.10.2010 Largecells_Kickoff_Meeting-Okt2010

04.02.2010 Cloud_Computing_LRZ-2010 18.11.2010 Leading-Entrepreneurs-Nov2010

13.10.2010-14.10.2010 CoTeSys-Workshop-Okt2010 23.06.2010 Lehrerfortbildung-Informatik-2010

09.07.2010 Concrete-Causation-2010 02.07.2010,03.07.2010 MHS-2010

26.04.2010-27.04.2010 CoteSys-Course-April2010 16.03.2010-17.03.2010 MMK-2010

12.03.2010 Courses_in_English-2010 16.03.2010 MMK-20109

09.02.2010-11.02.2010 DEISA-Meeting-Feb2010 05.10.2010 MMS-2010

29.06.2010 30.06.2010 DEISA2_Review-Juni2010 09.07.2010 Marketing-Symposium-2010

10.05.2010 11.05.2010 DES-2010 14.05.2010-16.05.2010 Marokkanischer_Verein-2010

13.04.2010-16.04.2010 DFG-FOR538-April2010 04.11.2010-05.11.2010 Megacities-2010

05.03.2010 DFG-Schwerpunkt-05.03.2010 17.03.2010 Menschliche_Zuverlaessigkeit-2010

07.07.2010-09.07.2010 DFG-Tagung-IMETUM-Juni-2010 26.11.2010 Mentor_meets_Mentee-Nov2010

07.10.2010-09.10.2010 DG-GT-Meeting-2010 09.03.2010-12.03.2010 Metabolomics_and_More-2010

27.09.2010-28.09.2010 DGSI-Sept2010 03.02.2010 Microsoft-Roadshow-2010

04.11.2010-07.11.2010 DPT-2010 04.02.2010-05.02.2010 Mittelstandssymposium-2010

04.08.2010-05.08.2010 DRIHM-Proposal-Meeting-2010 30.04.2010 Moodle-2010

17.05.2010-18.05.2010 DRIHMS-MAI-2010 06.12.2010 Moskau-Delegation

25.02.2010,03.03.2010-05.03.2010 DZT-2010 18.05.2010-19.05.2010 Muenchener_Unternehmenstag-2010

120 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

23.02.2010-24.02.2010 Design_und_Elektronik-2010 19.10.2010-20.10.2010 NIXU-Workshop-2010

02.09.2010-03.09.2010 Double-Chooz-Experiment-2010 30.03.2010 Nanocem-2010

07.05.2010-09.05.2010 DrupalDevDays-2010 05.10.2010 Netzneutralitaet-Okt-2010

23.08.2010-27.08.2010 EARLI_SIG_14-2010 14.10.2010-16.10.2010 Niere-2010

04.05.2010-05.05.2010 EFSA-2010 08.03.2010-09.03.2010 OASE-Projektmeeting-Maerz2010

17.12.2010 EGI-InSPIRE-PMB-2010 14.03.2010-20.03.2010 OGF28-2010

14.10.2010-16.10.2010 EGU_Fall-2010 04.10.2010-06.10.2010 Oekolandbau-Okt-2010

06.09.2010-09.09.2010 EHEDG-Seminar-Sept2010 04.12.2010-05.12.2010 Open-HW_SW-Event

07.10.2010-09.10.2010 ELOA-2010 02.12.2010 PDF_und_Geodaten_II-2010

13.09.2010 EPS-EWG-2010 15.01.2010 PERC-2010

24.06.2010 ERC-2010 30.08.2010-31.08.2010 PRACE-Kickoff-Mtg-2010

28.09.2010-02.10.2010 ESF-COST-A32-2010 01.03.2010-02.03.2010 PRACE_Workshop-Maerz2010

12.04.2010-13.04.2010 ETG-Workshop-2010 05.05.2010 PROSPECT-Mai2010

26.11.2010-27.11.2010 EU-Project-FP7-Nov2010 13.10.2010 PROSPECT-Okt2010

14.10.2010 EXASCALE-Meeting-Okt2010 20.12.2010 PROSPECT_STRATOS-2010

27.10.2010 EXPO-Wege-ins-Ausland-Okt2010 20.09.2010-24.09.2010 PWA-Workshop-2010

26.08.2010-27.08.2010 EcoMove-AUG2010 15.10.2010 PWiB-2010

14.09.2010-15.09.2010 EcoMove-SEPT2010 06.12.2010 ParTec-MSU-Dez2010

14.09.2010-17.09.2010 Economics_of_Food-2010 11.05.2010 Personalmesse-AUDIT-2010

08.10.2010-09.10.2010 Ernmed-2010 18.05.2010 Personalmesse-CONSULTING-2010

27.09.2010-01.10.2010 ExMar-2010 05.05.2010 Personalmesse-MEDIEN-2010

18.06.2010 Exascale-FS-2010 12.05.2010 Personalmesse-RECHT-2010

18.05.2010 FET-MAI-2010 11.03.2010-25.03.2010 Pervasive_Health-2010

27.09.2010 FH-RZ-Leiter-Sept2010 06.10.2010-07.10.2010 PhiBot10-2010

27.11.2010 FIRST_LEGO_League-November2010 13.12.2010 Pressekonferenz-SuperMUC-2010

12.04.2010-16.04.2010 FOG-April2010 06.10.2010 Produktionskongress-2010

17.07.2010-18.07.2010 FUH-psy2-ss10-2010 24.02.2010-26.02.2010 Reprotagung-2010

13.08.2010-15.08.2010 FernUni-2010-Bod 23.04.2010-24.04.2010 Roboticswettbewerb-April_2010

14.10.2010-16.10.2010 FernUni-2010-PsyE 22.02.2010-26.02.2010 SENSORIA-Feb2010

08.04.2010-10.04.2010 FernUni-EL-2010 08.10.2010 SFB453-Okt2010

12.06.2010 FernUni-Neve-Mai2010 01.03.2010-03.03.2010 SFB607-2010

31.05.2010-02.06.2010 Firmenkontaktgespraech-LMU-2010 03.03.2010 STRATOS-Meeting-Maerz2010

24.03.2010-25.03.2010 Forstlicher-Unternehmertag-2010 11.05.2010 Sophos-Tag-Mai2010

26.04.2010-27.04.2010 Forum_der_Lehre-2010 05.10.2010 Spiegelausschuss-2010

05.10.2010-08.10.2010 Freiflaechenworkshop-Okt-2010 04.10.2010,11.10.2010-14.10.2010 Stat-Woche-M2010

15.10.2010 Fundraisingtag_Muenchen-2010 07.12.2010 Stratos-Management-Board-Dez2010

16.06.2010-17.06.2010 G-Node-Symposium-2010 27.10.2010 Studienfinanzierung-2010

05.03.2010-12.03.2010 GDM-2010 20.03.2010 Studieninformationstag-2010

04.10.2010-06.10.2010 GEARS-2010 16.10.2010 Studieninfotag-Okt2010

06.07.2010 GI-Herausgebertreffen-2010 19.11.2010-22.11.2010 Studieren-Down-Under-2010

18.03.2010-19.03.2010 GMA-ELearning-2010 26.07.2010-06.08.2010 Summer-School-2010

15.03.2010-17.03.2010 GPZ2010 18.05.2010 SuperMUC-SGI-2010

20.05.2010 GROW-2010 10.03.2010-16.03.2010 THIS-Maerz2010

27.09.2010-29.09.2010 Ganga-Developer-Sept2010 08.07.2010-09.07.2010 TIME-Meeting-2010

09.12.2010-10.12.2010 Geist-Gehirn-Maschine-2010 28.10.2010-29.10.2010 Technologieseminar-Okt-2010

Jahresbericht 2010 des Leibniz-Rechenzentrums 121

04.11.2010-05.11.2010 Geodaesie-Nov-2010 24.03.2010 Telekom_Stiftung-2010

10.03.2010-11.03.2010 Geoinformationssysteme-2010 19.03.2010 TextGrid-2010

05.08.2010-07.08.2010 GlobalHands-2010 17.05.2010-20.05.2010 Thermoacoustics-Mai-2010

25.06.2010 Governance-Network-2010 10.06.2010 Unternehmertag-2010

29.11.2010-01.12.2010 Gradewood-2010 04.06.2010-07.06.2010 VDE-Fallstudien-2010

08.04.2010-10.04.2010 HETDEX-2010 01.05.2010-02.05.2010 VDI-Aktiven-Treffen-2010

14.07.2010 HP-Networking-Day-2010 14.10.2010-15.10.2010 VERCE-Okt-2010

21.04.2010 HP-Procurve-Manager-April2010 11.03.2010,15.03.2010,17.03.2010-19.03.2010 Vertragsverhandlungen-SuperMUC-2010

02.11.2010-03.11.2010 HoKo-2010 08.10.2010,12.10.2010-13.10.2010 Vorkurs-Physik-Herbst2010

22.10.2010 IAS-Symposium-Okt2010 07.10.2010-08.10.2010 WMHT-2010

29.11.2010-03.12.2010 IATUL-Tagung-NOV2010 22.02.2010-24.02.2010 WS_Vegetationsoekologie-Feb2010

01.06.2010 ICS-Symposium-Juni2010 22.10.2010-26.10.2010 Wissenschaftstage-Okt-2010

28.06.2010-01.07.2010 ICTON-2010 06.12.2010-10.12.2010 Workshop_Fluorescence_Imaging-2010

23.06.2010 IFO-Jahresversammlung-2010 19.02.2010 ZHS-Alumni-Feb2010

23.07.2010-31.07.2010 IFTR-2010 10.11.2010-11.11.2010 ZKI_IT-Strategietagung-2010

18.10.2010-19.10.2010 IGE-KickOff-Meeting-Okt2010 15.04.2010-17.04.2010 Ziel-Seminar-Apr2010

26.11.2010 IGSSE_Meeting-Nov2010 18.02.2010-20.02.2010 Ziel-Seminar-Feb2010

20.01.2010 IKOM_Bau-2010 29.09.2010-30.09.2010 excelence-day-Sep-2010

05.05.2010 IKOM_Life_Science-2010 14.01.2010 Interne Sitzung (VER:_GSISSH-Vorführung)

11.10.2010-13.10.2010 IMAPS_Konferenz-2010_ 14.04.2010-16.04.2010 mfk2010

Tabelle 33: Liste der unterstützten Veranstaltungen im Jahr 2010

Auch im Jahr 2010 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 300 Mbit/s erreichen und geben dadurch den Funkkanal schneller wieder für andere Teilnehmer frei. Außerdem wurden öfters Access Points anlässlich einer Veranstaltung neu aufgebaut, die ansonsten erst zu einem späteren Zeitpunkt eingerichtet worden wären. Eine Verteilung der Konferenzen auf die einzelnen Monate zeigt die Statistik in Abbildung 55. Erwar- tungsgemäß werden die Hörsäle vor allem in vorlesungsfreien Zeiten für Konferenzen genutzt.

Abbildung 55: Konferenzen im Verlauf des Jahres 2010

122 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

3.2.5 Internet-Zugang Der Zugang zum weltweiten Internet wird über das Deutsche Wissenschaftsnetz (WiN) realisiert. Im Jahr 2010 war das MWN technisch mit einer 10 Gbit/s-Schnittstelle am WiN angeschlossen. Derzeit ist ein zweistufiges Ausfallkonzept mit Backups für den Internetzugang umgesetzt (s.u). Die monatliche Nutzung (übertragene Datenmenge) des WiN-Anschlusses seit Juni 1996 zeigt Abbildung 56

Abbildung 56: Entwicklung der Nutzung des WiN-Anschlusses des MWN (in GByte/s)

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

1,9 1,9 1,7 1,5 1,6 1,4 1,4 1,4

1,0 1,0

2001 2002 2003 2004 2005 2006 2007 2008 2009 2010

Abbildung 57: Steigerungsraten beim übertragenen Datenvolumen

Seit September 2003 ist der WiN-Anschluss vertragstechnisch ein so genannter Clusteranschluss, bei dem die vom MWN versorgten teilnehmenden Institutionen als eigenständige Partner mit eigenem Tarif bezogen auf den eingehenden Datenverkehr aufgefasst werden. Zu diesem Zweck wurden die laufenden Mes-

Jahresbericht 2010 des Leibniz-Rechenzentrums 123 sungen kumuliert, um eine Verteilung des Datenverkehrs zu bekommen. Die prozentuale Verteilung des Datenvolumens am WiN-Zugang (Messzeitraum November 2010) zeigt Tabelle 34.

Institution Total Bytes % LRZ und BAdW 78,1 TUM 8,7 LMU 8 Hochschule München 1,6 Sonstige 2,5 Hochschule Weihenstephan 0,9 Gate 0,2 Tabelle 34: Prozentuale Verteilung des Datenverkehrs am WiN-Zugang

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

Abbildung 58: Anbindung des MWN an das Internet

Der Standardzugang zum Internet ist über das vom DFN betriebene Wissenschaftsnetz (WiN) realisiert. Der WiN-Anschluss des LRZ erfolgt über das IPP (Max-Planck-Institut für Plasmaphysik) in Garching mit einer Anschlußbandbreite von 10 Gbit/s. Dort wurde vom DFN der zugehörige WiN-Kernnetz-Router installiert. Derzeit ist ein zweistufiges Ausfallkonzept für den Internetzugang umgesetzt. 1. Falls die Hauptleitung zwischen LRZ und IPP oder eines der entsprechenden Interfaces an den beiden Routern ausfallen sollte, wird automatisch auf den Backup-Link zwischen Maschinenwe- sen und IPP umgeschaltet. Durch diese Backup-Verbindung entstehen keine zusätzlichen Kosten. 2. Sollten beide Leitungen oder aber der Kernnetzrouter des DFN in Garching ausfallen, wird ohne merkliche Unterbrechungen für den Benutzer auf eine über M-net realisierte Backup-Verbindung umgeschaltet. Die Backup-Verbindung zum Internet wird über eine LWL-Strecke mit 1 Gbit/s

124 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

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 2010 wurde die Backup-Strecke in sechs Fällen aktiv. In der Regel handelte es sich dabei um sehr kleine Störungen und der Backup war nur für wenige Minuten aktiv. Am 27.08.2010 kam es zu Routing- Problemen im X-WiN. Auslöser war ein Test von RIPE und ein Software-Fehler in einigen DFN- Routern. Bei diesem Vorall wurde der Verkehr für knapp zwei Stunden über die Backup-Strecke abgewickelt.

3.2.6 Service Load Balancer (SLB)

3.2.6.1 Big-IP-3400 Die beiden Big-IP-3400 Server Load Balancer von F5 Networks sind schon seit 2006 produktiv mit gro- ßem Erfolg im LRZ im Einsatz. Über sie laufen Dienste wie Webserver, Radiusproxies, Zeitschriften- proxies und SSH-Logins für das Linux-Cluster. Weitere technische Informationen dazu sind in den Jahresberichten der Vorjahre zu finden.

3.2.6.2 Big-IP-8900 Für das Projekt Hochschulstart.de wurden im Oktober 2010 zwei Big-IP-8900 Server Load Balancer beschafft. Diese werden zunächst nur für Hochschulstart.de (vgl. Abschnitt 2.9) eingesetzt. Ab Februar 2011 sollen sie dann die beiden Big-IP-3400 ersetzen. Alle Dienste werden dann umgezogen. Technische Daten der Big-IP-8900: • 2x AMD Quad Core 2,2 GHz • 2x 320 GB Festplatte als Raid 1 • 16 GB RAM • Hauptanbindung: 2x 10 Gb-Ethernet-Glasfaser • 8 x 1 Gb-Ethernet-Glasfaser (2x nur intern genutzt) • 16 x 1 Gb-Ethernet-Kupferkabel (2x für Serveranbindung genutzt) • Max. 58.000 SSL-Transaktionen pro Sekunde in Hardware.

3.2.7 Proxies und Zeitschriftenzugang Das Angebot der elektronischen Zeitschriften und Datenbanken wurde von den Universitätsbibliotheken weiter ausgebaut. In vielen Fakultäten ist es eine wichtige Informationsquelle für Mitarbeiter und Studen- ten. Viele Studenten recherchieren auch von zu Hause, wo sie meist über einen DSL-Anschluss mit Flat- rate verfügen.

3.2.7.1 Webplattform für den Zeitschriftenzugriff Die vom LRZ betriebene Webplattform DocWeb (http://docweb.lrz-muenchen.de) wurde am 31.12.2010 eingestellt, da die zugrundeliegende Software (CGIProxy) nicht mehr weiter gepflegt wird und zunehmend Probleme mit dynmischen Webseiten (vor allem mit Javascript) machte. Das führte dazu, dass viele Zeitschriftenzugänge und Zeitschriften nicht mehr benutzbar waren, da ständig Javascript- Fehlermeldungen erschienen oder die Webseiten keinen sinnvollen Inhalt mehr anzeigten. Die Universitätsbibliothek der TU-München hat mit eAccess (https://eaccess.ub.tum.de :2443/login) seit Sommer 2010 einen Nachfolger am Start. Nutzer der LMU können nur noch den Zugang über VPN verwenden.

Jahresbericht 2010 des Leibniz-Rechenzentrums 125

3.2.7.2 Shibboleth Für die Bibliothekszwecke wird das Authentifizierungsverfahren Shibboleth eingesetzt. Als verlagsüber- greifendes Authentisierungsverfahren Shibboleth ist es zwar schon seit einiger Zeit bei beiden Bibliothe- ken im produktiven Einsatz, allerdings beteiligen sich daran zurzeit nur große Verlagshäuser. Bei Shibbo- leth wird der Nutzer von der Verlagsseite direkt zu einer Authentifizierungseite des LRZ umgeleitet und muss sich nur einmal für einige Stunden und beliebige teilnehmende Verlage einloggen. VPN oder ein spezielles Webportal sind dann nicht mehr notwendig.

3.2.8 Domain Name System

Neben IPv4- werden auch IPv6-Einträge unterstützt. Der Webdns-Dienst wird inzwischen von 255 Nut- zern zur Pflege der DNS-Einträge verwendet. Die Anzahl der über Webdns verwalteten DNS-Zonen stieg (von 1688) auf 1857. Es wurden 123 neue Domains unter verschiedenen Toplevel-Domains (z.B. de, org, eu) für Institute und Organisationen registriert oder von anderen Providern transferiert.

Abbildung 59 und Abbildung 60 zeigen die Frequenz der Anfragen für den autoritativen und Resolving- Dienst über 7 Tage (6.12.2010 – 12.12.2010).

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

Abbildung 60: Statistik für alle DNS-Resolver

Eine Übersicht aufgeteilt nach Domains im MWN zeigt Tabelle 29. Die reale Anzahl der Zonen und Ein- träge ist um einiges höher, kann aber nicht ermittelt werden, da manche der von den Instituten selbst betriebenen DNS-Server keine Auflistungs-Abfragen beantworten.

126 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Anzahl Anzahl Anzahl Anzahl Anzahl Anzahl A- AAAA- Domain Zonen Sub-Domains Records Records Aliase MX-Records uni-muenchen.de 359 2879 26025 1383 4113 3572 lmu.de 104 2076 3744 272 1636 2933 tu-muenchen.de 286 7257 18831 340 1967 7687 tum.de 323 2466 10429 593 2590 1959 fh-muenchen.de 50 288 3566 0 233 525 hm.edu 68 228 7509 0 228 307 fh- weihenstephan.de 3 18 114 0 48 2 hswt.de 1 6 61 0 39 2 badw- muenchen.de 25 74 28 0 29 92 badw.de 24 70 1 0 63 82 lrz-muenchen.de 72 185 6669 901 1120 55 lrz.de 59 128 20394 286 588 14 mhn.de 62 321 78113 40 1263 274 mwn.de 42 117 2914 113 269 26 Sonstige 503 683 2495 63 788 501 Gesamt 1981 16796 180893 3991 14974 18031 Tabelle 35: Domains im MWN

3.2.8.1 Teilnahme am deutschen DNSSEC-Testbed

Die Einführung der Domain Name System Security Extensions (DNSSEC), einer Erweiterung des DNS, mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden, wurde angegan- gen. Das LRZ hat hierzu die ersten Domains (z.B. mwn.de) digital signiert und nimmt am DNSSEC- Testbed der DENIC (zentrale Regesteriungsstelle für alle .de-Domains) teil. Dabei war das LRZ im zweiten Halbjahr 2010 der (nach Abfragen gemessen) mit Abstand größte Teilnehmer am DNSSEC-Testbed. Die Erfahrungen und Ergebnisse wurden in einem Vortrag beim DENIC-DNSSEC-Workshop, einem zusammen mit Nixu Software organisierten Workshop für universitäre Anwender aus ganz Deutschland im LRZ, sowie in vielen Einzelgesprächen, verarbeitet. Das LRZ hat sich dadurch einen Namen in diesem Bereich erarbeitet und wird diesen Kurs im nächsten Jahr fortsetzen.

3.2.9 DHCP-Server Seit ca. acht Jahren betreibt das LRZ einen DHCP-Dienst, der von allen Münchener Hochschulen für die automatische IP-Konfiguration von institutsinternen Rechnern genutzt werden kann. Außerdem wird dieser Dienst für einige zentrale Anwendungen verwendet, wie z.B. für die WLAN-Zugänge im MWN oder die Netzanschlüsse in Hörsälen und Seminarräumen. Insgesamt wird der DHCP-Dienst von ca. 250 Insti- tuten genutzt und verwaltet dabei ungefähr 670 Subnetze mit knapp 90.000 IP-Adressen. Falls gewünscht, tragen die DHCP-Server die Namen der Clients auch automatisch in den zuständigen DNS-Server ein (Dynamic DNS).

Jahresbericht 2010 des Leibniz-Rechenzentrums 127

Physisch betrachtet besteht der DHCP-Dienst aus drei Servern, von denen sich z.Zt. zwei im LRZ- Gebäude und einer im LMU-Stammgelände befinden. Die drei Server bilden zwei Paare, wobei einer der beiden Server im LRZ der primäre Server ist und der zweite Server im LRZ bzw. der im LMU- Stammgelände als sekundärer Server fungiert. Zur Ausfallsicherheit arbeiten die Server redundant, d.h. bei einem Ausfall eines Servers übernimmt der jeweils zweite automatisch die Funktion des anderen. Außerdem findet zwischen den Servern eine Lastteilung statt. Bzgl. DHCPv6 (DHCP für IPv6) fanden im Jahr 2010 weitere Tests statt. Im Laufe des Jahres 2010 wurden die Produktionsserver mit der neuesten Version der DHCP-Software (ISC DHCP 4.2.0) versehen, so dass im Zuge der geplanten flächendeckenden Einführung von IPv6 (vgl. Kapitel 3.2.12) auch entsprechende DHCPv6-Dienste zur Verfügung stehen.

3.2.10 Voice over IP (VoIP) im Jahr 2010 Insgesamt wurden durch die VoIP-Telefonanlage des LRZ vom Typ Asterisk ca. 201.000 (2009: 197.000) Gespräche mit einer durchschnittlichen Länge von 2:57 Minuten oder insgesamt ca. 590.000 (2009: 580.000) Gesprächsminuten vermittelt. Dies entspricht wieder einem Gesprächsvolumenzuwachs von ca. 2% im Vergleich zum Vorjahr, wobei die durchschnittliche Dauer der Gespräche gleich blieb. Es konnten ca. 900 Gesprächsminuten direkt über SIP zu externen Teilnehmern abgewickelt werden, was in etwa 40% im Vergleich zum Vorjahr entspricht. Grund hierfür ist der starke Rückgang der Ge- sprächsminuten zu einer externen Institution. Zu den über SIP erreichbaren Zielen gehören die Universi- täten Eichstätt, Jena, Regensburg, Wien, Mainz, Mannheim, Würzburg, Innsbruck, Stockholm und der DFN. Weitere Informationen zur VoIP-Telefonanlage, wie z.B. Aufbau und Vermittlungsstatistik, können den Jahresberichten ab 2006 entnommen werden.

3.2.11 Zugang über UMTS: Vodafone Sponsoring der Exzellenz Universitäten TU München und Ludwig-Maximilians-Universität München Im Rahmen des Sponsorings mit einem Gesamtvolumen von 5 Mio. Euro in der Laufzeit von fünf Jahren wurden die beiden Münchner Hochschulen Ende 2007 (LMU) bzw. Anfang 2008 (TU) mit UMTS- fähigen Geräten für die mobile Sprach- und Datenkommunikation ausgestattet. Damit ist es für mobile Nutzer möglich geworden, sich über einen zentralen VPN-Zugangspunkt mit dem MWN und dem Inter- net zu verbinden. Eine detaillierte Beschreibung der Technik findet sich im Jahresbericht 2008. Im Jahr 2010 waren die ersten zwei Jahre des Vertrages der TU abgelaufen und so werden die Endgeräte durch die nächste Generation ersetzt. Die PCMCIA / ExpressCard UMTS Modems werden durch USB-Sticks ersetzt. Als Austausch für die anderen Geräte wurde von der TU das Nokia E72 ausgewählt. Eine Darstellung des übertragenen Datenvolumens ist leider nicht möglich, da die Daten von Vodafone nicht bereitgestellt werden konnten.

3.2.12 IPv6 im MWN Zum Jahresende waren für 75 (weitere 15 im Zeitraum eines Jahres) MWN-Institutionen IPv6-Subnetze reserviert. Diese Zuwächse ziehen sich durch alle Teilnehmerkreise. Wie auch im letzten Jahr sind ein Großteil dieser Subnetze bereits konfiguriert und in Benutzung. Nach der bereits im Jahr 2009 erfolgten Ausgliederung des Teredo-Protokollumsetzers auf den zweiten X-WiN-Zugang erhöhte sich der (nun rein durch Teilnehmer am MWN verursachte) IPv6-Verkehr auf dem Zugang ins Internet erneut um den Faktor 2. Viele grosse Web-Seiten und Dienste-Anbieter haben ihre Inhalte im letzten Jahr auch über IPv6 zugänglich gemacht. Der letzte Sprung im Januar 2011 wurde beispielsweise durch die Aktivierung von IPv6 durch das YouTube Portal verursacht. Mit dem stetig wachsenden IPv6-Angebot nimmt auch der Verkehr im MWN entsprechend zu.

128 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 61: IPv6-Verkehr im MWN

Die Anzahl der gleichzeitig aktiven Systeme am X-WiN-Übergang erhöhte sich im Laufe des Jahres leicht auf 1300 (Vorjahr 1100), bei einem marginal verringerten Anteil des automatischen Tunneldiensts ISATAP. Die Anzahl der Endsysteme mit nativem IPv6 stieg laut dem Tool Nyx von 1800 auf 4800. Dies ist auf das fortschreitende Ausrollen von IPv6 im MWN und die zunehmende Installation neuer, von Haus aus IPv6-kompatibler Betriebssysteme der Kunden verursacht.

Abbildung 62: Gleichzeitig aktive IPv6-Hosts im MWN

Viele weitere Dienste im Angebot des LRZ wurden im Jahr 2010 IPv6-fähig gemacht. Dazu zählen bei- spiesweise Exchange 2010, der Postausgangsserver mailout.lrz.de, das ID-Portal sowie (experimentell) das Backup über TSM. Ein Meilenstein in diesem Bereich war der Beschluss der Leiterrunde des LRZ vom 24. November 2010, der eine flächendeckende Versorgung mit IPv6 im gesamten MWN bis Ende 2012 und die Bereitstellung der meisten Dienste des LRZ über IPv6 vorsieht. Damit hat der IPv6-Dienst im MWN entgültig den Sta- tus eines Produktionsdienstes erreicht. In diesem Zusammenhang wurden die Netzverantwortlichen auf dem NV-Treffen im Herbst 2010 noch einmal in diesem Bereich auf den neuesten Stand gebracht. Die exzellente Reputation des LRZ im Bereich von IPv6 manifestierte sich im Jahr 2010 in vielen Koope- rationen und Tests mit Herstellern sowie in diversen Vorträgen.

Jahresbericht 2010 des Leibniz-Rechenzentrums 129

Die Planungen für das Jahr 2011 sehen daher das Ausrollen von IPv6 in einer hohen Anzahl von Kunden- netzen und die Migration vieler interner Dienste vor. Die Vorbereitung (insbesondere im Bereich der Statistiken und Messungen) auf den weltweiten IPv6-Tag am 8. Juni 2011 und die (vollständige) Erweite- rung der bestehenden Netzüberwachungsmöglichkeiten auf IPv6 sind umfangreiche Aufgaben für das nächste Jahr.

3.3 Management Für das effiziente Management der Netzkomponenten und -dienste setzt das LRZ seit vielen Jahren erfolgreich auf eine Kombination aus Standardsoftwarepaketen und gezielt ergänzende Eigenentwicklun- gen. Nachfolgend werden die aktuellen Weiterentwicklungen der LRZ-Netzdokumentation sowie der Einsatz kommerzieller Netz- und Dienstmanagementwerkzeuge – insbesondere auch die mandantenfähige Überwachung der Dienstqualität im MWN – vorgestellt. Anschließend werden aktuelle Weiterentwick- lungen und Statistiken in den Bereichen Incident, Configuration und Change Management, die bislang durch Remedy ARS unterstützt werden, vorgestellt. Schließlich wird auf die Ausrichtung der LRZ IT- Service-Management-Prozesse nach ISO/IEC 20000 und die damit verbundene Werkzeugunterstützung über die iET Solutions ITSM Suite eingegangen.

3.3.1 Weiterentwicklung und Betrieb der Netzdokumentation In der LRZ-Netzdokumentation werden für den Betrieb des MWN relevante Informationen (Netzkompo- nenten, Subnetze, Ansprechpartner, Räume usw.) gespeichert. 2010 wurde die Netzdokumentation auf einen neuen, virtuellen Server mit aktuellem Betriebssystem migriert. Im Zuge dieser Migration wurden auch der zugrundeliegende Anwendungsserver Zope und die für die Netzdokumentation benötigten Soft- ware-Module und Treiber aktualisiert. Neben dieser Migration wurden auch noch einige Erweiterungen und Verbesserungen vorgenommen; die wichtigsten werden im Folgenden kurz aufgeführt.

3.3.1.1 Erweiterungen und Verbesserungen der Netzdokumentation Folgende Erweiterungen und Verbesserungen wurden 2010 realisiert: • “Firewalls / Filter“ wurde als komplett neuer Menüpunkt in die Netzdokumentation aufgenommen. Unter diesem Menüpunkt werden derzeit vor allem Informationen zu virtuellen Firewalls gespeichert. Prinzipiell könnten hier aber auch alle anderen Arten von Firewalls oder Filtern auf Subnetzen (Hardware-Firewalls, Router-Filter usw. gespeichert werden, da die Felder für die abgelegten Informationen (Name, Typ, Modus, Status der Komponente, Transportnetz, Kundennetz usw.) allgemein genug gehalten sind (siehe Abbildung 63 mit einem Ausschnitt des Ergebnisses einer Suche über die Firewall-Kontexte). Die Informationen zu Firewalls und Filtern wurden auch an einigen anderen Stellen in der Netzdokumentation (bei Personen, bei Instituten, bei Subnetzen und bei Komponenten) integriert und damit mit den bereits vorhandenen Daten in Beziehung gesetzt. • Bei Personen wurde ein Attribut für die LRZ-Kennungen der Netzverantwortlichen neu einge- führt. Das Attribut wurde anschließend durch einen Abgleich mit LRZ-SIM per Skript bei allen Personen gesetzt, bei denen eine eindeutige Zuordnung der Person in der Netzdokumentation zu einer Kennung in LRZ-SIM möglich war. Anschließend wurde die Kennung per E-Mail an alle Netzverantwortlichen entweder überprüft (falls ein Abgleich per Skript möglich war) oder neu abgefragt. Das Attribut LRZ-Kennung dient derzeit vorwiegend dazu, dass Netzverantwortlichen, die sich in die neue WWW-Schnittstelle NeSSI mit ihrer persönlichen Kennung eingeloggt haben, ihre Daten in der Netzdokumentation zugeordnet werden können. • Die Switch-Betreuer und die Arealbetreuer der Netzwartung können jetzt auch (wie bisher schon die Arealbetreuer) bei Bezirken und Unterbezirken gespeichert werden. • Das IP-Sperren-Attribut bei Subnetzbereichen wird jetzt automatisch bei der Eingabe gemäß den Vorgaben des Arbeitskreises Security gesetzt. • Das Attribut Ort bei Bezirken und Unterbezirken wurde in die Attribute Name, Straße und Ort aufgeteilt. • Die DHCP-Administratoren werden bei Änderungen an Subnetzen oder Subnetzbereichen, die für die DHCP-Konfiguration relevant sind, per E-Mail benachrichtigt.

130 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 63: Ergebnis (Ausschnitt) einer Suche über die Firewall-Kontexte

3.3.1.2 Inhaltliche Aktualisierung der Netzdokumentation Um die Aktualität der Informationen zu den Netzverantwortlichen zu sichern, wurde 2010 wieder eine Benachrichtigung und Überprüfung der Kontaktinformationen durchgeführt. Jeder der 844 Netzverant- wortlichen erhielt per E-Mail die Liste der Subnetze und Subnetzbereiche, für die er zuständig ist, und die in der Netzdokumentation gespeicherten persönlichen Daten. Diese Daten sollten entweder bestätigt oder eventuelle Fehler korrigiert werden. An die Netzverantwortlichen, die auch nach einem Monat noch nicht geantwortet hatten, wurde per Skript automatisiert eine E-Mail zur Erinnerung geschickt. Bei rund 273 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.

3.3.2 Netz- und Dienstmanagement Das Netz- und Dienstmanagement bildet die Basis für die Qualität der Netzdienstleistungen des LRZ im MWN. Wesentliche Komponenten des Netz- und Dienstmanagements sind das Konfigurations-, das Feh- ler- und das Performance-Management. Die Aufgaben des Konfigurations- und Fehler-Managements werden im MWN durch den Netzmanagement-Server und die auf dem Server eingesetzten Netzmanage- ment-Software erfüllt. Die Aufgaben des Performance-Managements werden im Service-Level- Management-Werkzeug InfoVista umgesetzt (siehe auch nächster Abschnitt).

3.3.2.1 Netzmanagement Software und Netzmanagement Server Im Jahr 2008 wurde der IBM Tivoli Network Manager IP (ITNM) als neue Netzmanagement-Software ausgewählt. ITNM löst den HP OpenView Network Node Manager 6.4 ab. Der Auswahlprozess und die Gründe für die Wahl von ITNM sind im Jahresbericht 2008 zusammengefasst. 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 Einführung konnte 2009 allerdings nicht abgeschlossen werden. Die Gründe dafür und die für 2010 verbliebenen Arbeitspakete sind im Jahresbericht 2009 aufgeführt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 131

Die Produktivführung des IBM Tivoli Network Manager hat sich auch 2010 noch bis Juli verzögert. Hauptgrund war das Root-Cause-Analyse-Problem, das schon im Jahresbericht 2009 erwähnt wurde (RCA; Korrelation der Erreichbarkeits-Abfrage mit der Layer-2-Topologie). Es bewirkte, dass Ausfall- meldungen von Geräten, die hinter dem ursächlich ausgefallenen Gerät liegen, meistens nicht wie er- wünscht unterdrückt wurden. Dieses Problem wurde erst im Juli 2010 vom IBM-Support (und erst nach einer erneuten Eskalation durch das LRZ bei IBM) endgültig behoben. Die technische Ursache des Prob- lems war ein Fehler bei der Erzeugung der Layer-2-Topologie durch das Tool, so dass viele fehlerhafte Verbindungen im Topologie-Graphen für das MWN vorhanden waren. Neben der Bearbeitung des RCA-Problems wurden auch noch folgende (aus 2009 noch offenen) Punkte 2010 erledigt: • Automatisierung der Layer-2-Topologie-Erkennung • Automatisierung des Backups der Anwendung • Automatisches und schnelles Entfernen von abgebauten Geräten aus der Layer-2-Topologie • Vervollständigung der Dokumentation der Installation • Absolvierung bzw. Organisation von zwei Kursen zum IBM Tivoli Network Manager (ein Admi- nistrator-Kurs für die ITNM-Administratoren in Hamburg und ein Anwender-Kurs für die Event- konsole (OMNIbus) am LRZ) • Vervollständigung der Konfiguration zur Verarbeitung der SNMP-Traps der Geräte und Benach- richtigung der Geräteadministratoren bei bestimmten (wichtigen) SNMP-Traps über E-Mail und SMS • Weitere spezifische Anpassungen für die HP/Coloubris WLAN-Accesspoints aufgrund deren feh- lerhafter SNMP-Implementierung. Es ist leider immer noch nicht gelungen, vom Hersteller der WLAN-Accesspoints eine bzgl. der SNMP-Implementierung fehlerfreie Firmware-Version zu erhalten. • Erstellung und Umsetzung eines Benutzerkonzepts (Sichten für Geräte-Administratoren, Sichten für Operateure usw.) • Korrektur einiger verbleibender kleinerer Probleme bzgl. der Layer-2 Topologie-Erkennung Für das Jahr 2011 verbleibt damit als einziger wichtiger offener Punkt die VLAN-Unterstützung von ITNM nochmals zu testen und eventuell einzuführen (2009 wurde entschieden, die VLAN-Unterstützung aufgrund erheblicher Probleme vorerst zu deaktivieren, siehe Jahresbericht 2009). Aufgrund des oben beschriebenen RCA-Problems (und einiger kleinerer darüber hinaus) konnte der IBM Tivoli Network Manager erst im Sommer 2010 in den Produktivbetrieb überführt werden. Der HP Open- View Network Node Manager wurde deshalb noch bis Herbst 2010 parallel dazu betrieben und dann erst endgültig deaktiviert. In den folgenden drei Abbildungen sind Screenshots des IBM Tivoli Network Ma- nager zu sehen. In Abbildung 64 ist die Layer-2-Topologie des gesamten MWN zu sehen (inklusive des Auswahl-Fensters mit allen konfigurierten Layer-2-Sichten). In Abbildung 65 ist die Layer-2 Topologie des (erweiterten) MWN-Backbone dargestellt. Zusätzlich zu den Backbone-Routern sind noch einige Switches von wichtigen Standorten und die Anbindungen an das X- WiN (das deutsche Forschungsnetz) und an das Netz von M-net (Internet-Backup) zu sehen. Die MWN- Backbone-Struktur ist auch gut in der ersten Abbildung des gesamten MWN wiederzuerkennen. In Ab- bildung 66 ist die Event-Konsole des IBM Tivoli Network Manager mit einigen Meldungen zum Status des MWN dargestellt. Violett sind hier beispielsweise die von der Root-Cause-Analyse als Symptom erkannten Meldungen zu sehen. Ende 2010 wurden vom IBM Tivoli Network Manager ca. 2900 Netzkomponenten und Server (mit netz- relevanten Diensten) überwacht. Das ist eine Steigerung von ca. 300 Geräten gegenüber 2009. Der Netzmanagement-Server, 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

132 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 64: Layer 2 Topologie des gesamten MWN im IBM Tivoli Network Manager

Abbildung 65: MWN-Backbone im IBM Tivoli Network Manager

Jahresbericht 2010 des Leibniz-Rechenzentrums 133

Abbildung 66: Event-Konsole des IBM Tivoli Network Manager mit Status-Meldungen

3.3.2.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-muenchen.de/ werden Performance-Daten zu den wichtigsten Elementen des MWN (Backbone, X-WiN-Anbindung, IPv6-Verkehr, NAT-o-Mat, Demilitarisierte Zone (DMZ) des LRZ, Mo- dem- 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. In 2010 gab es hier keine wesentlichen Änderungen.

3.3.3 Überwachung der Dienstqualität des MWN mit InfoVista Das Service Level Management Werkzeug InfoVista dient dazu, die Qualität von IT-Diensten zu überwa- chen und in Visualisierungen und Reports darzustellen. Es wird seit dem Jahr 2000 zur Überwachung der Dienstqualität im Münchner Wissenschaftsnetz (MWN) eingesetzt. Das InfoVista-System wird ständig an die Entwicklungen im MWN angepasst bzw. Veränderungen im Netz werden in InfoVista übernommen. Im Jahr 2010 wurde der InfoVista-Server auf einen virtuellen Server migriert und gleichzeitig ein Update auf die Version 4.0 SP2 durchgeführt. Nach dieser Migration traten wiederholt Abstürze des InfoVista Collector-Service auf. Der Collector-Service, zuständig für die Sammlung der Daten per SNMP von Netzkomponenten, ist teilweise mehrmals pro Woche abgestürzt. Bis Ende 2010 konnte auch mit Hilfe des InfoVista-Supports noch nicht endgültig geklärt werden, ob diese Abstürze durch die Migration auf den virtuellen Server verursacht sind oder andere Gründe haben. Dieses Problem verbleibt für 2011 zur

134 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes endgültigen Klärung. Im Folgenden werden neue und veränderte Reports, die 2010 implementiert wurden, vorgestellt.

3.3.3.1 TSM-Reports Für die TSM-Server wurden 2010 einige Reports neu aufgesetzt, um die Auslastung der Netzanbindung und das Verkehrsvolumen zu überwachen. In Abbildung 67 ist als Beispiel ein Report über den Durchsatz zweier Router-Interfaces zu den TSM Servern zu sehen.

Abbildung 67: Report zum Durchsatz zweier Router-Interfaces zu den TSM Servern

3.3.3.2 Signal-Rausch-Verhältnis der WLAN Funkstrecken In diesem Report wird das Signal-Rausch-Verhältnis aller Funkstrecken im MWN dargestellt und über- wacht. Bei Unterschreiten eines Schwellwerts (derzeit 20 dB) wird eine E-Mail an die Administratoren der Geräte verschickt.

Abbildung 68: Report zum Signal-Rausch-Verhältnis der WLAN-Funkstrecken

Jahresbericht 2010 des Leibniz-Rechenzentrums 135

Das Unterschreiten des Schwellwerts deutet auf eine schlechtere Verbindungsqualität bzw. auf eine höhe- re Fehlerrate der Funkstrecke hin. In Abbildung 68 ist der Report mit dem Signal-Rausch-Verhältnis zu drei Funkstrecken zu sehen.

3.3.3.3 Switch-Reports für Netzverantwortliche Die Institute haben mit den Switch-Reports für Netzverantwortliche über die WWW-Schnittstelle Vista- Portal (http://vistaportal.lrz.muenchen.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 Diensterbrin- gung des LRZ transparenter, außerdem kann die Fehlersuche im Institut dadurch erleichtert werden. Die Reports können im HTML-, GIF-, PNG-, PDF-, Text- oder Excel-Format abgerufen werden. Zu den bereits in den Jahren 2003-2009 instanziierten Reports für Netzverantwortliche kamen 2010 noch Reports für folgende Einrichtungen hinzu: • Lehrstuhl für Kommunikationsnetze, Technische Universität München • ITW Weihenstephan • Physik-Department, Technische Universität München • Hochschule Weihenstephan-Triesdorf

3.3.4 Action Request System (ARS) Das Action Request System (ARS) von BMC wird am LRZ seit 16 Jahren für Incident Management, Change Management, Beschaffungswesen, Asset-Management und IP-Adressverwaltung eingesetzt. Die Arbeiten im Jahr 2010 haben sich vorwiegend auf Wartung und Pflege konzentriert. Zahlreiche Schu- lungen wurden für die Hotline-Mitarbeiter, studentischen Operateure und LRZ-Mitarbeiter zur Benutzung des ARS-Tools und der Formulare durchgeführt. 2010 wurden insgesamt 1189 (2009: 924) KOM-Change-Record-Tickets abgeschlossen. Dieses Formular unterstützt den Change-Management-Prozess in der Abteilung Kommunikationsnetze. Am Trouble-Ticket Formular (TT) wurden folgende Änderungen vorgenommen: • Neue Teams in ARS aufgenommen: Posterdruck mit der Mail an [email protected] und VMware Team mit der Mail an [email protected] • Der Dienst "Virtuelle Firewalls" in das Netz/Systemdienste Menü aufgenommen. • Ab sofort werden die ARS E-Mail Error Systemmeldungen auch an die Hotliner verschickt. Bis jetzt ging sie nur an ARS-Admins. • Die Anzahl der Anhänge wurde im Trouble-Ticket auf sieben erhöht, außerdem kann man jeweils Dateien bis max. 10 MB speichern. • Neuer Button "Offene Tickets HLRB + Linux" in TT-Formular eingebaut. • Der Erfasser des Tickets in KCR und TT wird bei der Anzeige auf Read-Only gesetzt. • Die Sucheinträge in der Hilferufliste werden jetzt mitgeloggt, um heiße Themen zu identifizieren. • Auf Hotline-Webformularen das Textfeld Applikation in Kurzbeschreibung umbenannt. Außer- dem wurde es Pflichtfeld. (https://www.lrz.de/services/beratung/hotline- web-allgemein) Auch in den Masken zum Einzelteil- und IP-Adress-Ticket wurden zahlreiche Detailverbesserungen vorgenommen.

3.3.4.1 Übersicht über die Nutzung des Trouble-Ticket Systems Ein Trouble-Ticket dient der Erfassung von Anfragen oder Störungen und der Ablaufdokumentation der Bearbeitung. Es ist immer einem Verantwortlichen (oder einer Gruppe) zugeordnet. Im Jahr 2010 wurden insgesamt 3554 (Vorjahr: 2966) Trouble-Tickets eingetragen, davon waren:

28 (39) Tickets mit der Dringlichkeit „kritisch“ 3487 (2914) Tickets mit der Dringlichkeit „mittel“ 39 (13) Tickets mit der Dringlichkeit „gering“

136 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 69 gibt einen Überblick über die Gesamtanzahl der monatlich erstellten Tickets und verdeutlicht den im Jahre 2010 stark angewachsenen Anteil an Standard-Störungsmeldungen, die über die Hot- line-Webschnittstelle (ARWeb, 1392 Tickets) eingegangen sind. Die Meldungen von Benutzeranfragen per Webschnittstelle werden neben den Nutzern von Standarddiensten ebenfalls von HLRB- und Linux- Cluster-Nutzern intensiv verwendet. Im Jahr 2010 sind 231 HLRB-Tickets (bis 01.12.2010, danach Mig- ration nach iET-Solutions) und 261 Linux-Cluster-Tickets (bis 17.08.2010, danach ebenfalls Migration nach iET-Solutions) per Webschnittstelle im ARS eingetragen worden. 2010 wurden insgesamt 1884 von 3554 Tickets per Web-Formular erfasst und somit bearbeitet.

Abbildung 69: Trouble-Tickets pro Monat

Die Diagramme in Abbildung 70 zeigen die Entwicklung der Bearbeitungszeiten von Trouble-Tickets über die letzten drei Jahre hinweg.

Jahresbericht 2010 des Leibniz-Rechenzentrums 137

Abbildung 70: Bearbeitungszeiten von Trouble-Tickets

Abbildung 71: Trouble-Tickets, klassifiziert nach Dienstklassen

Die Ursache für die extrem lange Bearbeitungszeit von Tickets mit der Priorität niedrig im Monat Okto- ber waren Tickets, die länger im Status „erfasst“ waren (anstelle von ausgesetzt) und die erst später geschlossen wurden. Aufgrund der geringen Anzahl von Tickets mit niedriger Priorität (39) haben diese Tickets mit langer Bearbeitungszeit auch eine große Auswirkung auf die Jahresübersicht. Abbildung 71 zeigt die Verteilung der Tickets auf Dienstklassen. Der Großteil der Tickets betrifft Netz- und Systemdienste. Zu folgenden zehn Diensten wurden die meisten Tickets geöffnet:

Dienst Anzahl Tickets VPN 356 Linux-Cluster 290 Mail -> Anwenderproblem 233 HLRB 223 WLAN -> eduroam 161 Verbindungsproblem 134 WLAN per mobilem Gerät 126 Groupware (Exchange) 96 Softwarebezug 87 Netzkomponenten -> Patchungen 86

138 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

3.3.4.2 Übersicht über die Nutzung des Quick-Ticket-Systems (QT) Im Laufe des Jahres 2010 wurde die Benutzung des Quick-Ticket-System durch die Hotline eingestellt. Die notwendigen Daten zur Verbesserung der Beratungsqualität konnten auch durch die Auswertung der generierten Trouble-Tickets in hinreichendem Maße gewährleistet werden. Im Jahr 2010 wurden insgesamt 210 Quick-Tickets (2009: 1480) eingetragen, davon entfielen auf: Dienst Anzahl Tickets telefonische Bera- 151 (1072) tung LRZ-Post 0 (247) Präsenzberatung 59 (161)

Zu folgenden Diensten bzw. Dienstleistungen wurden die meisten Quick-Tickets erzeugt: Dienst Anzahl Tickets Verbindungsproblem 58 VPN 40 Mitarbeiterkennungen 25 WLAN 21 Ausdruck 11 Gastkennungen 9 Studentenkennungen 7 Reservierungen 7 Mail Anwenderproblem 7

3.3.4.3 Benutzeranfragen der Technischen Universität München

An der Technischen Universität München (TUM) wurde im Jahr 2008 ein Service Desk eingeführt, der Benutzeranfragen der TUM entgegen nimmt. Diese Benutzeranfragen werden in einem TUM-eigenen Trouble-Ticket-System (OTRS) erfasst. Der TUM-Service-Desk koordiniert diese Benutzeranfragen ggf. mit nachgelagerten Dienstanbietern, wozu auch das LRZ als IT-Dienstleister der TUM gehört.

Anzahl TUM IT-Support Tickets in ARS 2010 100 50 0

Abbildung 72: Anzahl der von der TUM weitergeleiteten Anfragen

Jahresbericht 2010 des Leibniz-Rechenzentrums 139

Anfragen von TUM-Benutzern für das LRZ werden per E-Mail an das LRZ weitergegeben. Eine automatisierte Einspeisung in das ARS-System war aufgrund organisatorischer Änderungen nicht mehr möglich, d.h. die eingehenden Emails des TUM-Supports mussten jeweils manuell in ARS-Tickets überführt werden. Das führte allerdings dazu, dass die Bearbeitung dieser Benutzeranfragen sowohl auf TUM-Seite als auch auf LRZ-Seite komplexer wurde.

Abbildung 72 ist die Anzahl der vom TUM-Service-Desk an das LRZ weitergeleiteten Anfragen (531 Tickets, 2009: 497 Tickets) ersichtlich. Deutlich erkennbar ist auch der Anstieg der Anfragen um ca. 50% ab der zweiten Jahreshälfte.

3.4 Sicherheit Durch die gezielte Kombination aus der Bereitstellung von Werkzeugen zur Prophylaxe und der kontinu- ierlichen Überwachung des Netzbetriebs konnten die Auswirkungen IT-sicherheitsrelevanter Vorfälle auch in diesem Jahr erfreulich gering gehalten werden. Im Folgenden werden zunächst das am LRZ entwickelte Intrusion Detection und Prevention System Nat- o-Mat und seine aktuelle, als Secomat bezeichnete Version beschrieben. Daran anschließend wird auf den Einsatz des Security Information und Event Management Systems OSSIM sowie die zentralen Logserver und Sperrlisten eingegangen. Ferner werden die Mechanismen zum Monitoring am WiN-Zugang und das ebenfalls am LRZ entwickelte Sicherheitswerkzeug Nyx, das 2010 ins NeSSI-Portal integriert wurde, vorgestellt. Abrundend wird ein Überblick über die weiterhin auf sehr großes Kundeninteresse stoßende Dienstleistung „virtuelle Firewalls“ gegeben.

3.4.1 NAT-o-MAT/Secomat Das automatische proaktive Intrusion Prevention System (IPS) NAT-o-MAT und dessen Weiterentwick- lung Secomat bestehen derzeit aus zwei Clustern mit jeweils drei Nodes (technische Details siehe Jahres- bericht 2007 und 2009). Die folgenden Abbildungen zeigen eingehende bzw. ausgehende Datenübertra- gungsraten und gesperrte Benutzer der sechs Knoten des Secomat- und NAT-o-MAT-Clusters im Zeit- raum von einer Woche.

Abbildung 73: secomat1

Abbildung 74: secomat3

Abbildung 75: secomat4

140 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 76: natomat1

Abbildung 77: natomat2

Abbildung 78: natomat3

Tabelle 36 zeigt die Spitzenwerte bei Datenübertragungsrate und gleichzeitigen Benutzern. Secomat-Cluster NAT-o-MAT-Cluster Eingehende Datenübertragungsrate ca. 450 Mbit/s ca. 950 Mbit/s Ausgehende Datenübertragungsrate ca. 150 Mbit/s ca. 310 Mbit/s Gleichzeitige Benutzer ca. 3000 ca. 4800 Tabelle 36: Spitzenwerte der eingehenden und ausgehenden Datenübertragungsrate, sowie der Benutzeranzahl Nach den positiven Erfahrungen mit dem neuen Secomat-Cluster wurden vier leistungsstarke Rechner mit 10GE Netzkarten beschafft. Diese werden als Secomat-Cluster zukünftig den kompletten Verkehr der beiden bisherigen Cluster, d.h. NAT-o-MAT und Secomat, abwickeln.

3.4.2 Security Information & Event Management Auch in diesem Jahr unterstützte die 2009 eingeführte Security Information & Event Management (SIEM) Lösung auf Basis von Alienvaults Open Source SIM (OSSIM) die Arbeit des LRZ Abuse-Teams. Während bisher nur Systemverantwortliche über am X-WiN-Übergang detektierte Viren-, insbesondere Conficker-infizierte Systeme automatisch informiert werden konnten, wurde diese Reaktionsmöglichkeit in diesem Jahr um die direkte Information per VPN eingewählter Nutzer erweitert. Die Weiterleitung derartiger Informationen stellte bis dahin einen manuell von einem Abuse-Team-Mitarbeiter durchzufüh- renden Schritt dar, welcher nun ebenfalls komplett automatisiert durchgeführt wird und zur weiteren Ent- lastung der Mitarbeiter des Abuse-Teams führt. In Vorbereitung ist auch die Umsetzung einer automatisierten Sperrung der RADIUS-Kennung bei wiederholter Auffälligkeit. Durch Feintuning vorhandener Mechanismen konnte die Anzahl von False Positives auf ein sehr geringes Maß (2) reduziert werden. Desweitern führte die Erstellung und automatische Abfrage einer Datenbank- basierten Ausnahmeliste erfreulicherweise dazu, dass IP-Adressen zentraler Gateway- und Firewall- Systeme nur mehr vereinzelt automatisch gesperrt wurden. Die Anfang 2010 vom DFN-CERT etwa 30 bis 40 als auffällig gemeldeten IP-Adressen im MWN konnten bis Jahresende auf einige wenige (2 bis max. 5) pro Tag reduziert werden. Da OSSIM eine Reaktion nahezu in Echtzeit erlaubt, werden kompromitterte Systeme, die nur temporär mit dem MWN verbunden waren, zeitnah detektiert und die Netzverantwortlichen informiert. So war es möglich, auch Gäste und Konferenzteilnehmer über eine Viren-Infektion (meist privater) Systeme zu informieren.

Jahresbericht 2010 des Leibniz-Rechenzentrums 141

3.4.3 Zentrale Sperrliste Die zentrale Sperrliste des LRZ (technische Details siehe Jahresbericht 2009) wurde um eine Ausnahme- liste erweitert. Die Ausnahmeliste wird benötigt, um bestimmte IP-Adressen vor einer manuellen oder automatischen Sperrung zu schützen. So wird vermieden, dass z.B. der zentrale Webserver eines Institu- tes oder einer Organisation im Münchner Wissenschaftsnetz (MWN) beim Monitoring auffällt und dann umgehend gesperrt wird. Denn ein Rechner kann beim Monitoring durch eine vorübergehende Verkehrs- anomalie auffallen, die legitime Ursachen hat. Eine Sperrung wäre in solchen Fällen kontraproduktiv. Der Algorithmus, mit dem entschieden wird, ob ein Rechner gesperrt wird, bewertet zuerst das auffällige Ereignis und überprüft dann die Ausnahmeliste. Die Ausnahmeliste ruht auf zwei Säulen: einer daten- bankgestützten Tabelle, in die einzelne IP-Adressen oder auch -Bereiche eingetragen werden, und der ebenfalls datenbankgestützten Netzdokumentation, in der über die Vergabe von IP-Subnetzen im MWN Buch geführt wird. In der Netzdokumentation kann für ein Subnetz vermerkt werden, ob dessen IP- Adressen gesperrt werden dürfen oder nicht. Typischer Fall eines IP-Subnetzes, das durch eine entsprechende Markierung vor einer Sperrung geschützt wird, ist ein Server-Netz. Auch wenn ein Rechner detektiert wird und durch einen Eintrag in der Ausnahmeliste vor einer Sperrung sicher ist, wird der zuständige Netzverantwortliche verständigt. Denn es nicht ausgeschlossen, dass ein Rechner in der Ausnahmeliste korrumpiert wird. Die Ausnahmeliste sorgt lediglich für einen Zwischen- schritt im Eskalationsmechanismus.

3.4.4 Monitoring am X-WiN-Übergang Am X-WiN-Übergang wird sowohl die ein- als auch die ausgehende Kommunikation überwacht und analysiert. Im Unterschied zu vielen Unternehmen und deren Überwachungsstrategien liegt unser Schwerpunkt auf der Analyse ausgehenden Verkehrs, wobei sich grundsätzlich zwei Verfahren unter- scheiden lassen: • Vergleich mit (bekannten) Angriffsmustern • Statistische Verfahren Nennenswerte Auffälligkeiten in ausgehendem Verkehr sind unter anderem • FTP-Server auf einem Nicht-Standard-Port, welcher von Angreifern genutzt wird. • SSH-Scans (d.h. Verbindungsversuche zu externen Rechnern auf TCP-Port 22 mit einer Rate von mindestens 60 Verbindungsversuchen/Minute), um in Verbindung mit Wörterbuch-Angriffen schwa- che Passwörter zu brechen. • Die Kommunikation Viren-infizierter und trojanisierter Systeme (Conficker, Mebroot, Gozi, ZeuS, StormWorm), die versuchen, weitere Systeme insbesondere im Internet zu infizieren und damit auf die weitere Ausbreitung des Virus abzielen. • Die Kommunikation mit bekannten Command & Control Servern eines Botnetzes. • Allgemeine Portscans und Denial-of-Service-Angriffe. • Ungewöhnlich hohe ausgehende Datenvolumina. Demgegenüber werden am X-WiN-Übergang auch die meist in der Breite durchgeführten SSH-Scans auf MWN-interne Ziele erkannt. Auch dieses Jahr war das Monitoring am X-WiN-Übergang überwiegend geprägt von der Kommunikati- on MWN-interner, Conficker-infizierter Systeme. Insgesamt 502 betroffene Rechner wurden detektiert. Auch der Gozi-Trojaner (174 Systeme), mittels dessen versucht wird, per SSL gesicherte Daten, beispielsweise Bankaccounts, zu stehlen und an weltweit verteilte Server zu übermitteln, wurde detektiert. Die jeweils zuständigen Netzverantwortlichen und seit diesem Jahr auch per VPN verbundene Nutzer wurden automatisch (OSSIM) über Auffälligkeiten ihrer Systeme informiert und konnten damit zeitnah reagieren und Gegenmaßnahmen einleiten.

142 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

3.4.5 Sicherheitswerkzeuge "Nyx" und "Nessi"

3.4.5.1 Nyx Nyx ist ein Sicherheits- und Netzmanagementwerkzeug, mit dem einzelne Rechner im MWN lokalisiert werden können. Nach Eingabe einer bestimmten MAC- oder IP-Adresse eines Rechners bekommt man den Switch und den Port gemeldet, an dem der Rechner angeschlossen ist. Außerdem wird die Bezeich- nung der Netzwerkdose ausgegeben, zu welcher der Switchport gepatcht ist. Dafür müssen über 1100 Switches und 11 Router alle 5 Minuten abgefragt werden, um keine Daten zu verlieren. Deshalb ist Nyx massiv parallel aufgebaut. Um irrelevante Daten auszufiltern, ist die Kenntnis der Topologie notwendig. Die Erkennung erfolgt mit einem maschinellen Lernalgorithmus, dessen Ge- nauigkeit im Schnitt bei über 95% liegt. Im September und Oktober 2010 wurden im Rahmen eines studentischen Praktikums kleinere Cisco- Router und vor allem HP-Access-Points in Nyx integriert, so dass nun auch drahtlose Geräte geortet werden können. Als Standort wird dann der entsprechende Access-Point ausgegeben. Eine echte Standortbe- stimmung ist so allerdings nicht möglich (und auch nicht vorgesehen). Nyx fragt insgesamt also ca. 2700 Geräte ab.

3.4.5.2 Nessi Nyx wurde aus Datenschutzgründen früher nur LRZ-intern verwendet. Immer mehr Netzverantwortliche aus dem MWN fragten jedoch nach, ob sie diesen Dienst nicht auch selbst z.B. zur Fehlersuche nutzen könnten. Deshalb wurde 2009 mit der Entwicklung einer mandantenfähigen Plattform für Netzverant- wortliche begonnen, die ins LRZ-ID-Portal integriert ist. NeSSI (Network Admin Self Service Interface) stellt Netzverantwortlichen Werkzeuge zur eigenständigen Nutzung für ihre Bereiche zur Verfügung. Seit Oktober 2010 ist Nessi produktiv im Einsatz.

Abbildung 79: Nessi-Portal für Netzverantwortliche

Jahresbericht 2010 des Leibniz-Rechenzentrums 143

Nessi umfasst zurzeit folgende Dienste: • Nyx: Netzverantworliche können Rechner in ihren Subnetzen – und nur dort – orten. • DHCP: Netzverantworliche können sich vom LRZ-DHCP-Server vergebene IPs anzeigen lassen. • Anzeige der Kontakte und Subnetze aus der Netzdoku. Das Nessi-Portal ist in Abbildung 79 dargestellt. Das Portal ist wie Nyx in Java geschrieben und nutzt Tomcat als Application-Server. Zur Sessionverwaltung wird JavaServer Faces 2.0 eingesetzt. Der Web- desktop ist in Javascript realisiert, unter Verwendung des Javascript-Framework Extjs.

3.4.6 Virtuelle Firewalls Das LRZ betreibt fünf Cisco Firewall Service Module (FWSM), die sich auf verschiedene Backbone- Router im Münchner Wissenschaftsnetz (MWN) verteilen, und eine ASA5580-40 (technische Details siehe Jahresbericht 2009). Derzeit werden damit rund 85 Kunden mit virtuellen Firewalls (VFW) bedient. Bisher waren FWSMs und ASA5580-40 für zwanzig VFWs lizensiert. Da diese an einigen Standorten nicht mehr ausreichten, wurden alle Komponenten mit Lizenzen für jeweils fünfzig VFWs ausgestattet. Um die Ausfallsicherheit zu erhöhen, wurde eine zweite ASA5580-40 beschafft. Zukünftig werden die beiden ASA5580-40 nach einer Testphase im Active-Passive-Mode betrieben. Bei diesem Verfahren springt bei einem Ausfall der aktiven ASA5580-40 sofort die bis dahin passive ASA5580-40 ein und übernimmt deren Aufgaben. Durch ein Update des Web-Interfaces zur Verwaltung von VFWs auf den FWSMs kann jetzt auch auf den FWSMs die IPv6-Konfiguration bequem über die grafische Benutzerschnittstelle vorgenommen werden. Dies war zuvor nur auf den ASA5580-40 möglich.

Abbildung 80: Web-Schnittstelle Adaptive Security Device Manager (ASDM)

3.5 Projektarbeiten im Netzbereich 2010 Projektarbeiten hatten auch 2010 wieder einen hohen Stellenwert im Netzbereich. Im Folgenden werden die Tätigkeiten für das D-Grid GIDS-Projekt, das Customer Network Management (CNM) und die Gé- ant3-Tasks zum End-to-End Monitoring, I-SHARe sowie die Visualisierungswerkzeuge und die Arbeiten zum Performance Monitoring vorgestellt. Schließlich wird über den erfolgreichen Abschluss des 100GET E3-Projekts berichtet.

144 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

3.5.1 D-GRID Projekt GIDS Unter Grid-Computing versteht man die kollektive und kollaborative Nutzung weltweit verteilter hetero- gener Ressourcen wie z.B. Rechner, Software, Daten, Speicher, aber auch wissenschaftlicher Instrumente oder Großgeräte (z.B. Beschleunigerring am CERN, astronomische Teleskope) u.ä.. Das Grid-Computing wird seit September 2005 im D-Grid-Projekt vom Bundesministerium für Bildung und Forschung gefördert. Die Förderung des BMBF verteilt sich auf wissenschaftliche Verbundprojekte, die Grids nutzen, die so genannten Community-Projekte (CPs), und ein Verbundprojekt von Partnern, die Grid-Infrastrukturen entwickeln und betreiben und den Community-Projekten zur Verfügung stellen. Das letztgenannte Projekt wird als D-Grid-Integrationsprojekt (DGI-I) bezeichnet. Das DGI-I hat eine Kern- Grid Infrastruktur geschaffen, auf der die existierenden Community-Projekte basieren. Ziel war der Auf- bau einer nachhaltigen Grid-Basisinfrastruktur, die den Anforderungen der Communities gerecht wird. Nachdem das Projekt 2007 endete, wurde Mitte des Jahres 2007 ein Nachfolgeprojekt DGI-II beantragt und bewilligt. Das DGI-II Projekt startete zum 1.1.2008; es wird fachlich und inhaltlich in der Abteilung HLS bearbeitet. Im Netzbereich wurde 2010 an einem weiteren Projekt aus dem 2. Call gearbeitet: Zur Sicherung der Nachhaltigkeit einer deutschlandweiten Grid-Infrastruktur ist insbesondere der Bereich des Sicherheits- managements zu berücksichtigen. Das GIDS-Projekt hat die Entwicklung, Projektierung und Inbetrieb- nahme 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 Sicherheitssys- teme, die von Ressourcenanbietern betrieben werden, zu kombinieren, um eine globale Sicht auf Sicher- heitsvorfälle im Grid zu erhalten. Das Projekt, das zum 01.07.2009 begonnen wurde, wird als so genanntes GAP-Projekt gefördert. Die Projektlaufzeit beträgt 36 Monate und wird neben dem LRZ vom Regionalen Rechenzentrum für Nieder- sachsen (RRZN) und der DFN-CERT Services GmbH durchgeführt, mit den assoziierten Partnern Sto- nesoft GmbH und Fujitsu Technology Solutions GmbH, wobei die Konsortialführung beim LRZ liegt. Details zur Problemstellung, zu den Zielen und den im Jahr 2009 abgeschlossenen Arbeitspaketen des Projektes sind im Jahresbericht 2009 zu finden. Im Projekt wurden im Jahr 2010 folgende Arbeitspakete bearbeitet: • Entwicklung eines Datenschutzkonzepts für ein föderiertes GIDS • Entwicklung eines Informationsmodells inkl. Datenaustauschformats • Entwicklung einer Architektur: o Grobskizze einer Architektur für ein Grid-basiertes IDS o Detaillierung der Architektur auf Seiten der Ressourcen-Anbieter, inkl. (technischer) Durchsetzung des Datenschutzkonzepts o Detaillierung der Architektur auf Seiten eines GIDS-Betreibers zur Erbringung eines Grid-weiten IDS-Dienstes o Evaluation des Architekturvorschlags im Hinblick auf Anforderungs- und Kriterienkata- log • Umsetzung der entwickelten Architektur im D-Grid: o Implementierung und Realisierung ausgewählter Agenten o Implementierung und Realisierung einer Benutzeroberfläche 3.5.1.1 Entwicklung eines Datenschutzkonzepts für ein föderiertes GIDS Ein wichtiger Beitrag zur Akzeptanzsteigerung des GIDS bei den D-Grid-Ressourcenanbietern ist eine einfache und effiziente Durchsetzung von Datenschutzanforderungen und eine Anpassung der weiterge- gebenen Daten an die lokalen Sicherheitsrichtlinien. Diesem Ziel wurde im Datenschutzkonzept von GIDS, Meilensteinbericht Datenschutzmodell für ein Grid-basiertes IDS (MS 13) (http://www.grid- ids.de/documents/GIDS_MS13.pdf; Juli 2010), Rechnung getragen. Ziel dieses Arbeitspaketes war die Entwicklung eines Datenschutzkonzeptes, das alle rechtlichen, organisatorischen und technischen Anforderungen erfüllt, die vorher für das GIDS aufgestellt wurden. Dabei wurde unter anderem das Prinzip des „Least Privilege“ berücksichtigt, das die Rechte und Möglichkeiten der beteiligten Seiten auf das Notwendige einschränkt. Dadurch werden prophylaktisch die Risiken und Konsequenzen im Falle eines Sicherheitslecks so gering wie möglich gehalten.

Jahresbericht 2010 des Leibniz-Rechenzentrums 145

Zu diesem Zweck wurde mit einer Literaturrecherche bezüglich der vorhandenen Ansätze für Verfahren zur Anonymisierung und Pseudonymisierung personenbezogener Daten begonnen. Ziel war es, Kompo- nenten zu bestimmen, die in das Datenschutzkonzept direkt oder mit minimalem Aufwand für Anpassun- gen übernommen werden können. Als wichtiges Kriterium wurde geprüft, dass das Datenschutzkonzept konform zu den anderen Arbeitspaketen ist und deren Ergebnisse berücksichtigt.

3.5.1.2 Entwicklung eines Informationsmodells inkl. Datenaustauschformats Im Rahmen des Projektes ist die Spezifikation eines Informationsmodells inklusive eines Datenaustausch- formats entwickelt worden. Für eine effiziente und zuverlässige Erkennung von Angriffen (insbesondere verteilter Angriffe über mehr als eine Site der D-Grid Infrastruktur) ist der sichere Austausch verschie- denartiger Daten zwischen den auf den Sites installierten GIDS-Komponenten erforderlich. Die Kommu- nikation findet hier nicht nur Site-lokal, sondern ebenfalls Grid-global statt. Um ein geeignetes Datenformat zur Übertragung solch sicherheitsrelevanter Informationen zu finden, wurden zunächst die Anforderungen an ein solches erarbeitet und im Anschluß Recherchen zu bereits bestehenden Produkten und Formaten durchgeführt. Als ein für das Vorhaben GIDS sehr geeignetes For- mat hat sich das XML-basierte Intrusion Detection Message Exchange Format (IDMEF) herausgestellt. Durch eine breite Nutzerschicht und eine aktive Community handelt es sich bei IDMEF im Gegensatz zu vielen anderen proprietären Formaten um einen lebendigen Standard im Bereich verteilter IDS. Es folgte eine Untersuchung bereits bestehender Produkte und ihre Fähigkeiten bezüglich einer IDMEF- Unterstützung. Die bereits aufgestellten, speziellen Anforderungen an ein Grid-basiertes Intrusion Detection System wurden in einem nächsten Schritt bei der Erstellung der Spezifikation Informationsmodell inklusive Datenaustauschformat für ein Grid-basiertes IDS (MS 12) (http://www.grid- ids.de/documents/GIDS_MS12.pdf; Juni 2010) berücksichtigt. Darüber hinausgehend haben wir mehrere Punkte identifiziert, in denen eine Anpassung bzw. Erweite- rung von IDMEF erforderlich ist, um die volle Funktionalität von GIDS zu gewährleisten. So ist in ID- MEF beispielsweise keine Möglichkeit vorgesehen, kenntlich zu machen, dass gewisse Teile der Nach- richt (aus Datenschutzgründen) anonymisiert wurden. Die Einhaltung von Datenschutzbestimmungen ist jedoch essentiell für die Akzeptanz des GIDS und somit für den Erfolg des Projekts. Entsprechend wurden Erweiterungen über die von IDMEF dafür vorgesehenen Schnittstellen konzipiert und präzise definiert, welche GIDS-spezifischen Werte in die jeweiligen Datenfelder einzutragen sind.

3.5.1.3 Entwicklung einer Architektur Die Aufgabe in diesem Arbeitspaket bestand darin, die Architektur des zu entwickelnden GIDS festzu- schreiben. So wurde im ersten Schritt eine Grobskizze entwickelt, die in den weiteren Schritten näher spezifiziert wurde. Das daraus entstandene Architekturkonzept ist im Meilensteinbericht Architekturkonzept für ein Grid-basiertes IDS (MS 16-1) (http://www.grid-ids.de/documents/ GIDS_MS16-1.pdf; Oktober 2010) zu finden. Als Abschluss steht das noch laufende Arbeitspaket der Evaluation des Architekturvorschlags aus.

3.5.1.3.1 Grobskizze einer Architektur für ein Grid-basiertes IDS Die Grobskizze umfasst die zentralen technischen und organisatorischen Komponenten der GIDS- Architektur. Daneben existieren viele Abhängigkeiten und Wechselwirkungen zu dem Datenschutzkon- zept und dem Datenaustauschformat. Beispielsweise ergeben sich aus den Benutzerrollen Anforderungen an den Schutz der Daten und deren Verwendung. Für die Grobskizze der Architektur wurden zunächst die zentralen Rollen, unter denen Organisationen im Grid-Verbund auftreten können, und deren technische Komponenten für GIDS definiert, wie auch im Meilensteinbericht Grobskizze einer Architektur für ein Grid-basiertes IDS (MS 10) (http://www.grid- ids.de/documents/GIDS_MS10.pdf; Mai 2010) nachzulesen. Für die Rolle Ressourcenanbieter sind Sen- soren und die wichtigen Vorverarbeitungswerkzeuge Filter, Aggregator/Verdichter und Anonymisierer/ Pseudonymisierer definiert worden. Daneben ist in der Architektur ein GIDS-Agent als Anbindung an eine Bus-Struktur vorgesehen, die eine Kommunikation zwischen den einzelnen Teilnehmern von GIDS ermöglicht, sowie eine optionale lokale (G)IDS-Instanz, die unabhängig von den anderen beteiligten Partnern Alarmmeldungen verarbeiten kann. Darüber hinaus werden jeweils Agentensysteme benötigt, die Meldungen von bestehenden bzw. zu schützenden und zu überwachenden Systemen erhalten und die

146 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes diese Meldungen nach Durchlaufen der Vorverarbeitungsschritte an alle anderen für die jeweilige Nach- richt relevanten GIDS-Partner verteilen können. Eine weitere zentrale Rolle ist der Betreiber, der in erster Linie für das Berichtswesen und die Anbindun- gen der Virtuellen Organisationen (VO) an GIDS über ein Benutzerportal bzw. für proaktive Benachrich- tigungen zuständig ist. Weiterhin stellt er eine Grid-globale GIDS-Instanz und eine Datenbank für korre- lierte Alarmmeldungen zur Verfügung. Im Rahmen der Suche nach Implementierungsmöglichkeiten wurden verschiedene Kommunikationsan- sätze untersucht (Bus vs. Peer-to-Peer). Die Entscheidung ist hierbei auf eine Bus-Architektur gefallen, die die gegebenen Anforderungen besser erfüllen kann als ein Peer-to-Peer-Ansatz. Neben der Verbrei- tung sicherheitsrelevanter Informationen über den GIDS-Bus wurde ebenfalls eine Lösung über Reposito- ries diskutiert, um als GIDS-Teilnehmer auf den aktuellen Datenbestand des Grid-basierten IDS zugreifen zu können. Auch die sichere und effiziente Übertragung von Angriffsdaten wurde beleuchtet.

3.5.1.3.2 Detaillierung der Architektur auf Seiten der Ressourcen-Anbieter, inkl. (technischer) Durchsetzung des Datenschutzkonzepts Die im vorherigen Arbeitspaket in der Grobarchitektur definierten Komponenten und deren Funktionen wurden in diesem Arbeitspaket so detailliert spezifiziert, dass eine Implementierung auf dieser Basis erfolgen kann. Dabei wurden die folgenden, in Abbildung 81 gezeigten Komponenten näher betrachtet.

Abbildung 81: Architektur auf Seiten der Ressourcenanbieter

Die Komponente Anonymisierer/ Pseudonymisierer dient in erster Instanz dazu, dass die juristischen und vor allem datenschutzrechtlichen Randbedingungen, denen GIDS in Deutschland unterliegt, auch technisch durchgesetzt werden können. Als Basis der Spezifizierung diente das in den vorherigen Arbeitspa- keten entwickelte Meilensteindokument des Datenschutzkonzepts. Die Komponente Aggregator/Verdichter dient dazu, eine Vorverarbeitung der registrierten Alarme zu ermöglichen. Die über den GIDS-Bus zu transportierenden Daten sind nicht die von den Sensoren gelie- ferten Rohdaten. Stattdessen werden diese Rohdaten zunächst veredelt und in das spezifizierte Datenaus- tauschformat überführt. Hierbei wird ebenso die Vorverarbeitung vorgenommen. Es werden Zusammen-

Jahresbericht 2010 des Leibniz-Rechenzentrums 147 hänge zwischen Einzelalarmen hergestellt und aggregierte Meldungen erzeugt. Auf diese Weise wird ebenso die Datenmenge deutlich reduziert, um die Belastung des GIDS-Bus zu minimieren. Die eigentliche Logik des IDS liegt in den angeschlossenen (G)IDS-Instanzen. Die Installation und der Betrieb einer lokalen (G)IDS-Instanz ist optional und dem jeweiligen Ressourcenanbieter selbstverständ- lich eigenverantwortlich überlassen. Es bietet sich jedoch an, auf bereits existierende Mechanismen zu- rückzugreifen und diese an die Grid-Umgebung anzupassen. Die entsprechenden Vorüberlegungen für Betriebsmodelle und Integrationsstrategien wurden eruiert. Die Komponente GIDS-Agent ist die Kommunikationskomponente. Sie dient der Kommunikation zwischen verschiedenen Komponenten der GIDS-Gesamtarchitektur und bildet die Schnittstelle zwischen den lokalen GIDS-Instanzen und dem GIDS-Bus (und entsprechend auch mit der ebenfalls an den GIDS- Bus angeschlossenen globalen GIDS-Instanz).

3.5.1.3.3 Detaillierung der Architektur auf Seiten eines GIDS-Betreibers zur Erbringung eines Grid-weiten IDS-Dienstes Analog zu den Architekturkomponenten der Ressourcenanbieter wurden in diesem Arbeitspaket Kompo- nenten und deren Funktionen so detailliert spezifiziert, dass eine Implementierung auf dieser Basis erfolgen kann. Die Grid-globale GIDS-Instanz bildet das Gegenstück zur Site-lokalen GIDS-Instanz. Sie ist beim GIDS- Betreiber installiert und verarbeitet nicht durch lokale Sensoren gesammelte Daten, sondern durch andere GIDS-Teilnehmer übermittelte, veredelte Daten verschiedenster Ressourcenanbieter. Diese Instanz arbeitet entsprechend auf einer deutlich kleineren, aber dafür Grid-globalen Datenbasis und kann entsprechend Site-übergreifende Angriffe erkennen. Die zentrale Anlaufstelle des GIDS für Benutzer und Administratoren wird ein Webportal sein. Hierfür wurden die Anforderungen gesammelt, diskutiert und festgehalten. Für eine proaktive Benachrichtigung der Kunden des Grid-basierten IDS ist eine mandantenfähige Kom- ponente notwendig, mit deren Hilfe Benachrichtigungen über einen erkannten Sicherheitsvorfall abhängig von seinem Schweregrad über verschiedene Kommunikationswege, wie beispielsweise E-Mail oder SMS, versendet werden. Um eine proaktive Benachrichtigungskomponente zu realisieren, wurden Konzepte zum Einsatz bzw. zur Modifikation bereits existierender Monitoring-Systeme diskutiert.

3.5.1.3.4 Evaluation des Architekturvorschlags im Hinblick auf Anforderungs- und Kriteri- enkatalog Der Abgleich des Architekturkonzepts gegen den in der ersten Phase des Projekts aufgestellten Anforde- rungs- und Kriterienkatalog wurde im Rahmen dieses Arbeitspakets ebenfalls begonnen. Als potenziell problematisch wird bei der vollständigen Umsetzung der Datenschutzanforderungen die Beurteilung der Erkennungsleistung der Agenten / Sensoren eingestuft. Die praktischen Auswirkungen sollen im Pilotbe- trieb evaluiert werden.

3.5.1.4 Umsetzung der entwickelten Architektur im D-Grid Aufgrund der Komplexität der Architektur ist es für deren technische Realisierung notwendig, auf bestehenden Systemen aufzubauen. Dabei müssen die bereits getroffenen Enscheidungen bzgl. der Grobarchi- tektur und des Datenschutzkonzeptes berücksichtigt werden. Als Baustein bietet sich das Prelude-Rahmenwerk an, das ein verteiltes IDS mit offenen Schnittstellen realisiert. Als weiterer Vorteil wird das Format IDMEF bereits nativ unterstützt und bietet ein Datenbank- schema, in dem Daten gespeichert werden können. Weiterhin werden verschiedene Sensoren inklusive Snort unterstützt, die im Rahmen von GIDS eingesetzt werden können.

3.5.1.4.1 Implementierung und Realisierung ausgewählter Agenten In Zusammenarbeit mit den Projektpartnern wurde zunächst ein Testbed für den GIDS-Bus eingerichtet, um die verschiedenen Organisationen miteinander zu verbinden. Hierfür wurde mit Hilfe von OpenVPN ein virtuelles Netzwerk implementiert, das durch redundante VPN-Server an den drei Standorten der Pro- jektpartner betrieben wurde. Erste Tests bezüglich des Datendurchsatzes dieser Lösung sind vielverspre- chend verlaufen. Ebenso wurden erste prototypische Agenten an das Netzwerk angebunden, die von ihnen

148 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes gesammelte Informationen in Form von GIDS-Meldungen im IDMEF-Format über den GIDS-Bus an andere Teilnehmer verteilen. Auch hier sind erste Tests erfolgreich verlaufen. An den Standorten der Projektpartner wurden erste Agenten auf Basis von Prelude eingerichtet, deren Aufgabe das Sammeln von Sensornachrichten und das anschließende Konvertieren in das GIDS- Datenformat ist.

3.5.1.4.2 Implementierung und Realisierung einer Benutzeroberfläche Schlussendlich wurde angefangen, eine Benutzeroberfläche zu entwickeln, die sowohl Gridbenutzern als auch Administratoren als zentrale Anlaufstelle für das GIDS dienen soll. In einem ersten Schritt wurden die Anforderungen an eine solche Benutzerschnittstelle gesammelt, diskutiert und bewertet. Basierend auf den Ergebnissen wurden Mockups entwickelt und Oberflächendesigns diskutiert. Hierbei haben sich zwei wesentliche Sichten herauskristallisiert. Zum einen wird es eine Überblicksseite geben, auf welcher die aktuelle Lage graphisch und tabellarisch dargestellt wird. Zum anderen wird es eine wesentlich detailliertere Ansicht geben, die es Administratoren erlaubt, gezielt und zeitlich beschränkt nach bestimmten An- griffsarten und Angriffszielen zu suchen. Im Folgenden galt es, eine technische Lösung für das Webportal zu erarbeiten. Hierfür wurden Recher- chen zu verschiedenen technischen Umsetzungen durchgeführt. Nach Gesprächen mit dem DFN-CERT ist die Entscheidung für das Python-Framework Django gefallen. Django ist ein quelloffenes Webframe- work, welches ein direktes objektrelationales Mapping für verschiedene Datenbanksysteme ermöglicht. Ein weiterer Vorteil an Django ist die Kapselung der einzelnen Module. Da das DFN-CERT-Portal ebenfalls mit Hilfe des Django-Frameworks entwickelt wurde, ist eine spätere Integration von GIDS ohne größere technische Hürden machbar.

3.5.2 Customer Network Management 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 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 aussagekräftige Informationen über die Einhaltung der vertraglich ausgehandelten Dienstvereinbarungen. Die CNM-Anwendung für das X-WiN ist unterteilt in die drei Anwendungen Topologie, Datenvolumen und XY-Accounting: 1. Die CNM-Anwendung Topologie dient der Visualisierung der X-WiN-Topologie/des Zustands der IP-Infrastruktur (siehe Abbildung 82). Anhand dieser Anwendung wird den DFN-Kunden (Anwender) 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, und für jeden Knoten (Router) die weitergeleiteten Pakete. Auf der Netzebene gibt es 59 Standorte, die jeweils einen Router enthalten. Diese Router sind direkt mit den Kundeninfrastrukturen verbunden und enthalten auch verschiedene Verbindungen zu kommerziellen Netzbetreibern sowie dem europäischen Wissenschaftsnetz Géant. Die auf hierarchischen Karten aufgebaute Anwendung wurde im April 2004 für alle X-WiN-Anwender freigegeben und ist seitdem im Betrieb.

Jahresbericht 2010 des Leibniz-Rechenzentrums 149

Abbildung 82: Die CNM-Anwendung Topologie

2. Die CNM-Anwendung Datenvolumen dient der Bereitstellung von 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. Die zwei Anwendungen können separat und unabhängig voneinander benutzt werden oder alternativ ihre Daten korrelieren. Beispielsweise wird für das LRZ als DFN-Anwender beim Starten der Topologie- Anwendung und Auswählen des Knotens (Routers) GARx1 ein Fenster mit den entsprechenden Verbin- dungen geöffnet, zu denen weitere Dienstinformationen angezeigt werden können (siehe Abbildung 83).

Abbildung 83: Dienstinformationen in Knotenkarten

Beim Anklicken des Felds ServiceInfo wird für den Anwender (hier das LRZ) das Dienst-Ressourcen Fenster geöffnet, das alle von diesem Anwender benutzte Netzressourcen beinhaltet (siehe Abbildung 84). Wenn man aber nur einen der gelisteten Dienste auswählt, werden auch nur die zu diesem Dienst zugeordneten Ressourcen angezeigt. Die Liste umfasst alle vergangenen und aktuellen Netzressourcen

150 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes mit deren Nutzungszeitraum. In einzelnen Spalten werden die Komponente, der Interfacename, der Dienstname, der Dienstname und der Zeitraum der Ressourcennutzung aufgeführt.

Abbildung 84: Dienst-Ressourcen pro Kunde

Wenn aus dieser Liste eine Ressource und dann über das Kontextmenü die Option ,,Öffne Service- Fenster‘‘ ausgewählt wird, so wird das neue Service-Fenster der CNM-Anwendung Datenvolumen geöff- net. Von diesem aus können die entsprechenden Datenvolumenstatistiken angefordert werden (siehe Ab- bildung 85).

Abbildung 85: Das Dienstfenster (CNM-Datenvolumen) für das LRZ

3. Die CNM-Anwendung XY-Datenvolumen dient der Bereitstellung von detaillierten IP- Accounting-Daten. Diese Anwendung ist neu und befindet sich zur Zeit noch im prototypischen Betrieb. Mit ihr können die DFN-Anwender nachvollziehen, mit welchen anderen DFN-Anwendern sie innerhalb des X-WiN wie viel IP-Verkehr ausgetauscht haben. Der Prototyp sieht eine Admin- und einen Kundensicht vor. Die erste ist in Abbildung 86 dargestellt. Angezeigt wird die Top-10-Liste der Datenvolumina, die zwischen den links ausgewählten Bereitstellungsorten zu allen anderen Anwendern ein- bzw. ausgegangen sind. Alle oben genannten Anwendungen werden den Benutzern als Java-Applets angeboten. Darüberhinaus wird seit 2004 im MWN eine Webinterface-basierte Sicht der CNM-Anwendung Topologie angeboten, das sogenannte WebCNM. Diese zeigt ausschließlich hierarchische Netzkarten mit dem aktuellen Status der Routerinterfaces. Bei der CNM-Anwendung handelt es sich um eine verteilte Client/Server-Architektur. Wie bereits er- wähnt wurde, ist der Client als Java-Applet bzw. WebCNM-Anwendung erhältlich. Der Server ist in C++ implementiert. Der Server bedient sich einer XML-Datenbank, GIS2 (Globale X-WiN- Informationssystem), die alle X-WiN Daten verwaltet. Als Kommunikationsmiddleware sowohl zwischen dem Client und dem Server als auch zwischen dem Server und GIS2 dient CORBA. Derzeit läuft der Server unter Solaris (Sparc-Rechnerarchitektur).

Jahresbericht 2010 des Leibniz-Rechenzentrums 151

Abbildung 86: Die XY-Accounting Anwendung (Prototyp)

Da am LRZ zukünftig alle Server nach Möglichkeit als virtuelle Server in der VMware-Infrastruktur laufen sollen und diese unter Sparc-Solaris Architektur mit VMware nicht virtualisiert werden können, ist eine Portierung des CNM-Systems auf Linux-x86 nicht nur empfohlen, sondern unabdingbar. Hierfür wurde ein Portierungsplan erstellt, der schrittweise den Server (C++ Implementierung, CORBA Anbin- dung, Datenbankanbindung u.a.) von Sparc-Solaris auf Linux-x86 umstellt. Am Ende des Jahres wurde in Kooperation mit dem DFN mit dem ersten Schritt, der Auswahl eines geeigneten ORBs unter Linux, begonnen. Die Portierung soll Ende 2011 abgeschlossen sein. Weitere Einzelheiten zum CNM-Projekt und zum CNM für das X-WiN sind zu finden unter: http://www.cnm.dfn.de .

3.5.3 Géant E2E Link Monitoring Géant ist eine Weiterentwicklung des europäischen Wissenschaftsnetzes, das ca. dreißig nationale Wis- senschaftsnetze verbindet. Neben klassischen IP-Verbindungen können im Rahmen des Géant-Verbundes auch End-to-End (E2E) Links eingerichtet werden. Das LRZ arbeitet seit Jahren aktiv in Projektteilen mit, die Konzepte, Verfahren und Tools zum Management dieser Ende-zu-Ende Links bereitstellen. Ein wesentlicher Bestandteil dieses Projekts ist das E2E Link Monitoring System (E2Emon), das unter Feder- führung des LRZ konzipiert und entwickelt wurde. Eine ausführliche Beschreibung des zugrunde liegenden Projekts und des Monitoring Systems kann dem Jahresbericht 2008 entnommen werden. In Géant wird das E2E Monitoring System von der E2E Coordination Unit (E2ECU) betrieben, die gezielt für den Betrieb von E2E Links ins Leben gerufen wurde. Sie überwacht derzeit (Stand Anfang 2011) 35 produktive Links. Weitere 14 Links sind aktuell in der Aufbauphase. Zu den größten Kunden dieses Dienstes zählen internationale Forschungsprojekte wie das LHC am Cern sowie die europäische GRID- Initiative DEISA. Bereits seit Mitte 2008 erfüllt E2Emon die von der E2ECU spezifizierten funktionalen Anforderungen. Deshalb lag 2010 der Fokus hauptsächlich auf einer weiteren Verbesserung der Benutzerfreundlichkeit. Beispielsweise können die grafischen Ansichten der E2E Links vom Benutzer konfiguriert werden, sodass nicht nur eine horizontale, sondern auch eine vertikale Repräsentation möglich ist (siehe Abbildung 87). Desweiteren können die Listen der Links anhand verschiedener Kriterien sortiert werden. Auch die konfigurierbare automatische E-Mail Benachrichtigung wurde erweitert und deckt nun zusätzliche Fehler- fälle ab.

152 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 87: Vertikale Darstellung eines End-to-End Links

Da E2Emon sich in den letzten Jahren als äußerst erfolgreich erwiesen hat und einen hohen Bekanntheits- grad genießt, wird der Fokus des Tools nun auch in Zusammenarbeit mit internationalen Partnern im Kontext dynamischer Verbindungen erweitert, wofür 2010 in enger Zusammenarbeit mit amerikanischen Forschungsnetzen wie Internet2 oder ESnet eine erste Anforderungsanalyse gestartet wurde. Die Liste der Anforderungen, die in dem derzeitig noch andauernden Prozess erstellt werden, dient als Grundlage für die Analyse der Defizite existierender Versionen von E2Emon hinsichtlich der Überwachung solcher dynamischer Verbindungen. In einem nächsten Schritt wird dann untersucht und evaluiert, wie diese De- fizite behoben werden können.

3.5.4 Géant I-SHARe Beim Betrieb von Netzdiensten, die die Zusammenarbeit mehrerer unabhängiger Provider erfordern, ergeben sich neuartige Herausforderungen, die von etablierten IT Service Management Frameworks nicht adressiert werden. Im Umfeld des von der EU geförderten Géant-Projektes werden diese insbesondere im Zusammenhang mit sog. Ende-zu-Ende-Verbindungen deutlich, bei denen es sich um dedizierte optische Multi-Gigabit-Verbindungen - i.A. jeweils über mehrere heterogene optische Netze - handelt. Die Ar- beitsabläufe für die Einrichtung und den Betrieb dieser Verbindungen erfordern ein koordiniertes Vorge- hen der beteiligten nationalen Wissenschaftsnetze. Das Ziel der GN-Aktivität I-SHARe ist die Tool-Unterstützung der Multi-Domain-Betriebsprozesse, die alle Phasen des Lebenszyklus von E2E Links abdecken. Der Fokus liegt dabei auf dem erforderlichen Informationsaustausch, der von der Planung einer neuen E2E Link Instanz über deren Betrieb bis hin zu ihrer Abbestellung notwendig ist. Die Aktivität wurde Mitte 2007 mit einer umfangreichen, fundierten Anforderungsanalyse gestartet. Details dazu können im Jahresbericht 2008 nachgelesen werden. Ergebnis dieser Analyse war die Spezifikation und Entwicklung eines Prototyps, 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

Jahresbericht 2010 des Leibniz-Rechenzentrums 153 wurde. Der Pilotbetrieb von I-SHARe, der bis Ende März 2011 andauernd soll, wird vom LRZ übernom- men (siehe Abbildung 88). I-SHARe wird derzeit von fünf NRENs für die Planung neuer End-to-End Links genutzt.

Abbildung 88: I-SHARe Pilotinstallation am LRZ

Nach Beendigung der Pilotphase sollen mögliche Änderungswünsche berücksichtigt und implementiert werden. Für eine erfolgreiche Überführung in den Produktivbetrieb werden derzeit Management-Prozesse definiert, die die Zusammenarbeit aller beteiligten Partner definieren sollen.

3.5.5 Géant-Visualisierungswerkzeuge und Performance Monitoring Das CNM (siehe Kapitel 3.5.2) wird seit 2004 im europäischen Forschungsumfeld als Visualisierungs- werkzeug eingesetzt, im Géant2-Projekt von 2004 bis 2009 und in dessen Nachfolger Géant3 seit 04/2009. Mit der CNM-Anwendung Topologie werden die Topologie und aktuelle bzw. historische Kennzahlen vom Géant-Kernnetz und einigen der 34 angeschlossenen nationalen Forschungsnetze in hierarchischen Netzkarten visualisiert. Zusätzlich wird das Web-CNM in einer speziell angepassten Version für die Netzüberwachung des LHCOPN (Large Hadron Collider Optical Private Network) eingesetzt. Der über Géant realisierte europäische Verbund von 34 nationalen Forschungsnetzen (NRENs) stellt Netzdienste im paneuropäischen Maßstab zur Verfügung. Ein Beispiel für einen solchen Dienst sind Op- tical Private Networks (OPNs), die z.B. im Umfeld des LHC-Grid verwendet werden, um das CERN (Tier-0) mit den Tier-1- und Tier-2-Zentren zu verbinden. Die Dienste werden in einer multinationalen Kooperation unabhängiger nationaler Forschungsnetzen (NRENs) und DANTE erbracht. Die entwickelte LHCOPN-Wetterkarte, die den Web-Zugriff auf Status und Kennzahlen der LHCOPN- Infrastruktur (Tier-0- zu Tier-1-Verbindungen) einer HTML/CSS-, Java-Script-basierten Implementie- rung ermöglicht, wird über den Web-Browser angesprochen. Abbildung 89 zeigt ihre Übersichtskarte. Im letzten Jahr wurde die Anbindung an die produktive E2EMon-Instanz realisiert und die Wetterkarte wird im LHCOPN-Portal von den Operateuren der LHCOPN aufgerufen. Diese können je ein Paar von zwei LHCOPN-Standorten (T0/T1 oder T1/T1) auswählen, um Informationen und Kennzahlen über den Link dazwischen zu erhalten. Für jeden Link werden dabei Ende-zu-Ende (E2E) Kennzahlgraphen von verschiedenen Netzschichten der letzten 24 Stunden angezeigt, nämlich: Hop-Anzahl, One-Way-Delay, Jit- ter, Paketverlust, verfügbarer TCP-Durchsatz, Verbindungsauslastung, IO-Errors. Diese Kennzahlgraphen wurden mit einer Funktionalität erweitert, die es ermöglicht, nicht nur die letzten 24 Stunden, sondern auch bestimmte zurückliegende Zeitintervalle abzufragen und die damit verbundenen Kennzahlen darzustellen. Ein Beispiel einer solchen Abfrage ist in Abbildung 89 dargestellt. Ebenso wird für den ausge- wählten Link eine detaillierte Ansicht der Schicht-2-Abschnitte in den verschiedenen beteiligten administrativen Domänen angezeigt

154 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 89: Hauptansicht der LHC-OPN Wetterkarte

Weiterhin wird für den ausgewählten Link eine detaillierte Ansicht der Schicht-2-Abschnitte in den verschiedenen beteiligten administrativen Domänen angezeigt (siehe Abbildung 90).

Abbildung 90: Historische Kennzahlen für ein LHCOPN-link

Diese Kartenübersicht wurde erweitert und verfeinert zu einer tabellarischen Übersicht, auch ,,Dashboard‘‘ genannt. Hier werden dieselben Kennzahldaten zusammengefasst wie in der Wetterkarte, nur in einer komprimierter Form: alle Links auf einen Blick. Die Kennzahlen können allein oder kombi- niert (z.B. One-Way-Delay und Paketverlust) ausgewählt werden. Ein Tooltip zeigt den entsprechenden Wert beim Durchlaufen der Matrix.

Jahresbericht 2010 des Leibniz-Rechenzentrums 155

Abbildung 91: Prototypische LHCOPN Dashboard

Zu dieser Sicht kommt noch eine ausführliche dazu, die pro ,,Kästchen‘‘ auch die entsprechenden Kenn- zahlen anzeigt. Eine zusätzliche Sicht ist die jedes Knoten zu oder von allen anderen. In der Abbildung werden die kombinierten Kennzahlen für alle eingehenden Verbindungen zu einem Tier-1 Center (FR- CCIN2P3) gezeigt.

Abbildung 92: Eingehende Verbindungen zu FR-CCIN2P3 (Ausschnitt)

Auf Basis der im MWN prototypisch entwickelten WebCNM und der LHCOPN Wetterkarte wurde dieses Jahr ein ausführliches WebCNM-Konzept formuliert. Die Funktionalitäten der bestehenden Ja- vaCNM, die sehr vielfältig und seit vielen Jahren im Einsatz sind, werden in diesem WebCNM - Konzept vollständig auf eine Web-basierte Implementierung übertragen. Abbildung 93 zeigt eine mögliche Sicht des WebCNM.

156 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes

Abbildung 93: WebCNM - Vision

Für weitere Informationen zum Géant-Projekt und perfSONAR-System, siehe: http://www.geant.net/Services/NetworkPerformanceServices/Pages/perfSONARMDM.aspx

3.5.6 100GET-E3 Im Rahmen des europäischen Dachprojektes 100 Gbit/s Carrier-Grade Ethernet Transport Technologies (100GET), das vom BMBF gefördert wurde, wurden Ultra-Hochgeschwindigkeitsnetze basierend auf Ethernet-Technologien für Übertragungsraten von 100 Gigabit pro Sekunde entwickelt. Durch den breite- ren Einsatz von Ethernet-Technik auch in den Backbone-Netzen (sogenanntes Carrier-Grade Ethernet) erwartet man sich erhebliche Kosteneinsparungen. Das von Nokia Siemens Networks (NSN) geführte Teilprojekt "End-to-End Ethernet (E3)" entwickelte in Zusammenarbeit mit dem Leibniz-Rechenzentrum solche Technologien und Protokolle. Das Projekt mit einer Laufzeit von 36 Monaten endete nach einer dreimonatigen Verlängerung am 31. Dezember 2010. Im Rahmen dieses Teilprojektes wurde ein Konzept und eine Architektur für ein integriertes Inter- Domain Network Management System für Ultra-Hochgeschwindigkeitsnetze basierend auf Ethernet- und DWDM-Techniken spezifiziert. Um extrem breitbandige Verbindungen zwischen zwei Kunden zu schal- ten, sind häufig mehrere Provider beteiligt, die i.d.R. jeweils unterschiedliche eigene Systeme und Geräte verschiedener Hersteller verwenden (Heterogenität). Um einen solchen Dienst erbringen zu können, muss ein Managementsystem in der Lage sein, mit diesen Domänen-übergreifenden (Inter-Domain) Aspekten umgehen zu können. Das Themengebiet des IT-Managements lässt sich in die fünf Aufgabengebiete Fault (Fehlermanage- ment), Configuration, Accounting, Performance und Security Management aufteilen (FCAPS). Im Rah- men dieses Teilprojektes waren insbesondere das Fehler-, Konfigurations- sowie das Performance Ma- nagement von Interesse. Außerdem wurden die Fragen des Organisationsmodells für domänenübergrei- fende Zusammenarbeit untersucht. 2010 wurden ein Konzept für Service Level Agreements (SLA) und entsprechende Quality of Service (QoS) Parameter, ein Konzept für ein Ende-zu-Ende Monitoring System und Incident und Problem Ma- nagement Prozesse für providerübergreifende Dienste entwickelt. In der dreimonatigen Verlängerung wurde zusätzlich ein Konzept für einen Proxy-Dienst erstellt, der zwischen Kontrollschicht und Manage- mentschicht vermittelt. Dieser Proxy-Dienst ermöglicht die Kombination verschiedener Protokolle zur providerübergreifenden Signalisierung von Diensten und damit zu einer schnelleren Verbreitung von providerübergreifenden Diensten. Abbildung 94 zeigt die prinzipielle Funktion des Proxy-Dienstes, der zwischen der Kontrollschicht (E-NNI) und der Managementschicht (MTOSI) vermittelt. Das LRZ beteiligte sich darüber hinaus an der Erstellung eines Positionspapiers zu 100 Gigabit/s Ethernet Netztechniken.

Jahresbericht 2010 des Leibniz-Rechenzentrums 157

Der Projektpartner Alcatel-Lucent konnte bereits 2010 ein erstes Produkt vorstellen, das im Rahmen von 100GET entwickelt wurde.

Abbildung 94: Konzept des Proxy-Diensts

Jahresbericht 2010 des Leibniz-Rechenzentrums 159

4 Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen Die Komplexität vieler Tätigkeiten, insbesondere im IT-Service-Management und in Sicherheitsfragen, erfordert die enge Zusammenarbeit der Spezialisten des LRZ über die Grenzen der internen Organisation hinweg. Zu diesem Zweck wurden in der Vergangenheit spezielle Arbeitskreise eingerichtet, über deren Arbeit nachfolgend berichtet wird.

4.1 Arbeitskreis Security Im Fokus der Arbeit des abteilungsübergreifenden Arbeitskreises „Security“ steht, das bisher erreichte Sicherheitsniveau im MWN zu überwachen und weiter zu steigern. Auch in diesem Jahr wurde versucht, dieses Ziel nicht einfach durch den Einsatz weiterer IT-Security-Werkzeuge zu erreichen, sondern vorhandene, bereits bewährte Mechanismen weiter zu optimieren. Neben der Betrachtung rein technischer Aspekte standen vor allem organisatorische Aspekte im Vordergrund, um die komplexen Problemstellun- gen in diesem Themengebiet zu lösen. Die technische Umsetzung der erarbeiteten Lösungen erfolgt weiterhin durch die jeweils zuständige Abteilung, mit dem Unterschied, dass diese Lösungen von nun an in einen hausweiten Gesamtkontext eingebettet und somit aufeinander abgestimmt sind. Nennenswerte Themen, mit denen sich der Arbeitskreis „Security“ im Jahr 2010 unter anderem auseinan- der gesetzt hat, sind • Entwurf einer hausweiten Richtlinie zum Umgang mit Log-Daten, insbesondere die Speicherung, Verarbeitung und Löschung personenbezogener Daten unter rechtlichen Rahmenbedingungen. • Entwurf einer MWN-weit gültigen Richtlinie zum Thema „Sichere Passwörter“ und Verschär- fung der bis dato gültigen Anforderungen. • Entwurf einer Richtlinie für den abgesicherten Management-Zugang zu internen Ressourcen von Hersteller- und Wartungsfirmen und Entwicklung eines Konzepts zur technischen Umsetzung. • Erstellung einer Richtlinie zur Absicherung von Management-Zugängen zu Netzkomponenten (Switches, Router) sowie Konzeption und Zeitplanung zu deren technischer Umsetzung. Das wohl herausragendste Ergebnis der Arbeit des Arbeitskreises „Security“ war 2010 die Erstellung eines hausweiten Security-Incident-Response-Prozesses sowie dessen offizielle Einführung. Zielsetzung des Prozesses ist die strukturierte Bearbeitung von detektierten Sicherheitsvorfällen durch ein LRZ- CSIRT (Computer Security Incident Response Team). Der Prozess beschreibt unter anderem den Ablauf der Vorfallsbearbeitung und legt Verantwortlichkeiten in Form von definierten Rollen fest. Somit ist ge- währleistet, dass bei der Bearbeitung die Tätigkeiten von CSIRT-Mitarbeiter festgelegt sind und damit keine essentiellen Schritte vergessen oder doppelt durchlaufen werden. Auch im Jahr 2011 wird die Arbeit des Arbeitskreises „Security“ überwiegend von der Erstellung von Richtlinien und der Konzeption technischer Umsetzungsmöglichkeiten dieser Richtlinien geprägt sein. Insbesondere stellt auch die Absicherung des neuen Höchstleistungsrechners SuperMUC eine interessante Aufgabe dar, mit der sich der Arbeitskreis beschäftigen wird.

4.2 Arbeitskreis IT-Service-Management Die Zuverlässigkeit und Verfügbarkeit von IT-Services ist in erheblichem Maß auch von der effektiven Kommunikation, Kooperation und Koordination zwischen den Mitarbeitern des IT-Service-Providers abhängig. Ein optimales Management von IT-Diensten muss folglich über die Überwachung und Steue- rung 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 sowohl verschiedener so genannter ITSM-Rahmenwerke wie der IT Infrastructure Library (ITIL), als auch des vergleichsweise neuen internationalen Standards ISO/IEC 20000. Wie bereits im letzten Jahres- bericht dargelegt, arbeitet das LRZ daran, seine ITSM-Prozesse an den Vorgaben von ISO/IEC 20000 auszurichten.

160 Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen

4.2.1 Aktivitäten im Bereich IT-Service-Management am LRZ Der Arbeitskreis IT-Service-Management (AK ITSM) hat zur Aufgabe, ein organisatorisches und technisches Konzept für das ITSM am LRZ zu entwickeln. Er koordiniert die ITSM-Aktivitäten am LRZ, welche jedoch nicht auf Arbeiten innerhalb des Arbeitskreises selbst beschränkt sind. Die bereits im Juli 2009 gegründeten Prozess-Teams „Control“ und „Resolution“ haben ihre Planungen zu einem prozessorientierten Betrieb weiter vorangetrieben. Im „Control Team“ wurde die Implementierung eines LRZ-weiten, d.h. abteilungsübergreifenden Chan- ge- und Configuration-Managements weiter konkretisiert. Prozesse und Konzepte wurden erarbeitet und in ersten kleinen Pilotprojekten umgesetzt. Im Rahmen des „Resolution Teams“ hat man sich auf die Pla- nung und Einführung eines LRZ-weiten Incident-Managements fokussiert, um dieses zeitnah ausrollen und damit das alte Trouble-Ticket System ablösen zu können. Beide Teams bestehen wie der AK ITSM ebenfalls aus Vertretern aller Abteilungen und sind daher auch dafür verantwortlich, den Status der Ent- wicklungen in den Prozessen dorthin zu berichten. Die wichtigsten ITSM-Aktivitäten im Jahr 2010 sind analog zur Gliederung der ITSM-Planungen im letzten Jahresbericht im Folgenden anhand der drei Hauptaspekte „People, Process, Technology“ (Men- schen, Prozesse, Technologie) strukturiert.

4.2.1.1 „People“ Auch 2010 wurden Schulungen zu Grundlagen der ISO/IEC 20000 durchgeführt. Insgesamt haben sich so mittlerweile über 100 LRZ-Mitarbeiter mit dem erfolgreichen Absolvieren einer durch die TÜV SÜD Akademie durchgeführten Prüfung für das „Foundation Certificate in IT Service Management according to ISO/IEC 20000“ qualifiziert. Die Schulungen auf dem Professional Level wurden dieses Jahr durch den weltweit ersten Kurs zur Erlangung der neuen Zertifizierung „Associate Consultant / Auditor“ er- gänzt, an dem neben zehn LRZ-Mitarbeitern auch Hochschuldozenten aus verschiedenen Teilen Deutsch- lands teilnahmen. Erstmals wurden im Jahre 2010 auch interne Schulungen für das neue ITSM-Tool durchgeführt. Im Rah- men dieser Schulungen wurden über 30 Mitarbeiter an das neue Tool herangeführt und in hands-on Tuto- rien geschult, wie der vom „Resolution Team“ erarbeitete Incident-Management-Prozess mit dem Tool umzusetzen ist.

4.2.1.2 „Process“ Die 2008 eingeführten „KOM Change Records (KCRs)“ zur Koordination von Neuanschlüssen, Installa- tionen und Wartungsarbeiten wurden konsequent weiterentwickelt. Die Erfahrungen, die durch die KCRs gewonnen wurden, sind ebenfalls bei der Planung und Einführung eines abteilungsübergreifenden Chan- ge-Managements mit eingeflossen. Das 2009 definierte Verfahren zur geeigneten und kontrollierten Reaktion auf Störungen mit größerer Auswirkung, den sogenannten „Major Incidents“, wurde durch den Arbeitskreis „Continuity“ diskutiert und weiterentwickelt. Als Input diente hierbei in erster Linie die Analyse laufender Vorfälle bzw. derer Behandlung. Im Rahmen des „Resolution Teams“ wurde ein LRZ-weiter Incident-Management-Prozess definiert. Die- ser Prozess beschreibt ein einheitliches Verfahren, wie mit Störungen und Ereignissen, die eine Minde- rung der Servicequalität zur Folge haben könnten, umgegangen werden soll. Im Rahmen dieses Prozesses wurde ein Incident Manager benannt, welcher für den effektiven und effizienten Betrieb des Prozesses verantwortlich ist. Im August 2010 wurde dann der Incident-Management-Prozess im Rahmen eines Pi- lotbetriebes eingeführt. Zunächst wurden nur Störungen behandelt, die sich auf den Dienst „Linux- Cluster“ bezogen. Nach erfolgreicher Einführung wurde der Betrieb sukzessive auf weitere Dienste ausgeweitet. Im ersten Quartal 2011 soll die Einführung abgeschlossen werden, so dass ab diesem Zeitpunkt das gesamte LRZ nach einem einheitlichen Prozess arbeitet. Im Bereich der Control Prozesse wurde ein CMDB-Konzept erarbeitet nach dem künftig im ITSM-Tool die Infrastruktur und die Dienste des LRZ abgebildet werden. Auch wurde ein Change-Management Pro- zess definiert, welcher festlegt, wie innerhalb des LRZ mit Änderungen an Komponenten, Applikationen oder Diensten umgegangen werden soll. Das 2009 definierte Verfahren für „Major Changes“ wurde dabei in diesen Prozess integriert. Analog zum Incident-Management-Prozess wurde auch hier ein Prozessma-

Jahresbericht 2010 des Leibniz-Rechenzentrums 161 nager benannt, welcher für die Autorisierung von Changes mit größerer Auswirkung verantwortlich ist. Für ausgewählte Fälle wurde der Prozess bereits herangezogen und getestet.

4.2.1.3 „Technology“: Unterstützung der Prozesse durch die ITSM-Suite Nachdem 2009 viel Energie in die Auswahl einer ITSM-Suite gesteckt wurde, stand im Jahr 2010 an, diese Tool-Suite an die Gegebenheiten und Prozesse des LRZ anzupassen und in den Produktivbetrieb zu überführen. Speziell im Rahmen des Incident-Managements wurde hier viel Aufwand investiert, um das LRZ-spezifische Incident-Management optimal zu unterstützen. Mit dem Pilotbetrieb des Incident- Management-Prozesses im August 2010 wurde auch das neue ITSM-Tool für die Mitarbeiter des LRZ ausgerollt und zur Benutzung freigegeben. Neben Aktivitäten im Incident-Management wurde 2010 auch an der Tool-Unterstützung für das Change- und Configuration-Management gearbeitet. In kleinen Pilotprojekten wurde evaluiert, wie sich das ITSM- Tool für die Unterstützung, der durch das „Control Team“ definierten Konzepte eignet. Das Feedback wurde vom Tool-Entwickler-Team gesammelt und entsprechende Änderungen am Tool durchgeführt. Eine Anpassung und Weiterentwicklung des Tools wird auch 2011 ein zentraler Aspekt in der Einführung eines LRZ-weiten IT-Service-Managements sein. Das Entwickler-Team ist sowohl im Control wie auch Resolution Team vertreten und kann somit die Anforderungen an die Prozesse gezielt umsetzen. Auch kann dadurch Feedback in die Prozess-Teams einfließen, so dass ein effektives und effizientes Zusammenspiel zwischen Prozessen und Tool erreicht werden kann.

4.2.2 Weitere Aktivitäten im Bereich IT-Service-Management Auch 2010 wurden für Studenten der LMU und der TU München in Zusammenarbeit mit dem Lehrstuhl Prof. Hegering / Prof. Kranzlmüller zwei Seminare zum Thema „prozessorientiertes IT-Service Manage- ment“ angeboten. Wie bei den Schulungen für die Mitarbeiter des LRZ gab es auch für die Studenten die Möglichkeit, im Anschluss an das Seminar die Prüfung „Foundation in IT Service Management according to ISO/IEC 20000“ abzulegen und das entsprechende Zertifikat zu erwerben. Auch ist das LRZ mit Herrn Prof. Dr. Heinz-Gerd Hegering und Herrn Dr. Michael Brenner im Komitee für die IT-Personenzertifizierung nach ISO/IEC 20000 vertreten. Im Rahmen dieses Komitees wurde das Rahmenkonzept für Schulungen, Prüfungen und IT-Personenzertifizierung nach ISO/IEC 20000 festgelegt und wird kontinuierlich weiterentwickelt.

4.3 Arbeitskreis Continuity Der Arbeitskreis trifft sich halbjährlich, um vorgefallene Major Incidents daraufhin zu bewerten, ob Ver- besserungen oder Änderungen am Prozess erforderlich sind. Die Revisionssitzung im Frühjahr 2010 be- fasste sich weitgehend mit Standarthemen wie der Aktualisierung und Verbesserung der Dokumentation in den roten Ordnern. Eine weiter gehende Veränderung am Prozess wurde im Herbst 2010 beschlossen, weil sich viele als Major Incidents einzustufende Ereignisse auf den Fall beschränken, dass ein Administ- rator einen gestörten Dienst wieder in Gang bringt und der Major Incident Coordinator (MIC) dafür sorgt, dass die betroffenen Nutzer und gegebenenfalls andere Administratoren über die Störung informiert werden. Die bisher zwingende vorgeschriebene Anwesenheit des MIC im Krisenraum wurde gelockert und seine Arbeitsweise auf Grund der vorliegenden Störung und ihrer Anforderungen in das Ermessen des MIC gestellt. Bei einzelnen ausgefallenen Diensten, die keine weitere Koordination innerhalb des LRZ erfordern, kann der MIC daher beispielsweise jetzt auch von zu Hause agieren. Angeregt wurde die vollständi- ge Einbindung des Prozesses ins Incident Management, was zu einer automatischen Einschaltung der MICs führen würde. Für die Roten Ordner wurde die technische Dokumentation auf den neuesten Stand gebracht. In der Herbstsitzung des Arbeitskreises Continuity standen darüber hinaus Fragen der Kunden- benachrichtigung im Vordergrund. Es soll eine Kundenliste aufgebaut werden, in die auch die eventuell vorhandene SLAs einfließen, so dass der MIC seine Koordinationstätigkeit entsprechend priorisieren kann.

162 Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen

4.4 Arbeitskreis Informationsmanagement Wie im Jahresbericht 2009 bereits beschrieben, setzt das LRZ historisch bedingt viele Werkzeuge für die verschiedenen klassischen Aspekte des IT-Managements (Netzmanagement, Systemmanagement usw.) ein. 2010 wurde als wichtiger Erfolgsfaktor für ein effektives und effizientes Werkzeugkonzept die Reali- sierung von LRZ-weit gültigen Prozessen für Informationsmanagement und Configuration-Management identifiziert. Nur durch optimale Integration von Information und Bereitstellung konsistenter Dokumenta- tion lassen sich Konsolidierungen von Tools und Optimierungen erreichen. Um diesen Anforderungen Rechnung zu tragen, wurde zusätzlich zum bereits existierenden Control-Team der Arbeitskreis Informa- tionsmanagement gegründet. Im Rahmen des Arbeitskreises Informationsmanagement wurden 2010 unterschiedliche Aktivitäten gestartet, um die Dokumentations- und Informationsstruktur am LRZ zu verbessern. Von insgesamt 38 iden- tifizierten Informationsquellen hat man sich zunächst auf vier Quellen fokussiert, die nach Einschätzen des Arbeitskreises die wichtigsten und verbreitetsten Ablagen für Dokumentation sind. Ziel des Arbeits- kreises war es dann, diese vier Quellen derart zu verbessern, dass übrige Quellen mittelfristig durch diese zentralen Quellen abgelöst werden können. Ein zentraler Aspekt ist dabei die Einführung eines einheitlichen Dienstleistungsbaumes (DLB) gewesen. Dieser Baum repräsentiert eine Kernstruktur, welche Diens- te sowohl intern wie auch extern durch das LRZ erbracht werden. Somit spiegelt dieser Baum eine bestimmte Sichtweise auf den Betrieb des LRZ wider. Der Arbeitskreis hat 2010 damit begonnen, den Dienstleistungsbaum auf die vier zentralen Informationsquellen zu übertragen und die Struktur der Quel- len auf diesen Baum hin anzupassen. Folgende Ziele werden durch diese Maßnahme verfolgt: • Eine einheitliche Struktur verschiedener Informationsquellen nutzt den Wiedererkennungseffekt. Kunden sowie auch Nutzer finden sich dadurch auch in Informationsquellen, die sie selten nutzen, schnell zurecht. • Der DLB gibt eine Struktur wieder, die möglichst unabhängig vom Vorwissen des Nutzers nachvollziehbar und intuitiv ist. • Der DLB beschreibt eine bestimmte Sichtweise auf das Dienstportfolio des LRZ. Mit der LRZ- weiten Etablierung des Dienstleistungsbaumes wird auch ein einheitliches Vokabular angestrebt. • Mit dem Ziel des LRZ, eine ISO-20000-Zertifizierung zu erlangen, sollte das LRZ eine dienst- orientierte Sicht auf den Betrieb zunehmend der gruppen- und abteilungsorientierten Sicht vor- ziehen. Der DLB ist hierfür ein Startpunkt und eine wichtige Voraussetzung. Des Weiteren hat sich der Arbeitskreis damit beschäftigt, Richtlinien und Beispiele zu veröffentlichen, wo und wie Informationen abzulegen sind und wie der Dienstleistungsbaum zu verwenden ist. Hierdurch sollen Hemnisse bei der Dokumentation verringert und die Akzeptanz der zentralen Informationsquellen gesteigert werden. Dieser Punkt wird auch 2011 weiterhin ein zentraler Aspekt sein, mit dem sich der Arbeitskreis beschäftigen wird.

Jahresbericht 2010 des Leibniz-Rechenzentrums 163

5 Organisatorische Maßnahmen im LRZ

5.1 Personalveränderungen 2010

5.1.1 Zugänge

Datum Name Dienstbezeichnung Abteilung 01.01.2010 Schaaf Thomas, Dr. wiss. Mitarbeiter Hochleistungssysteme 01.01.2010 Übelacker Thomas wiss. Hilfskraft Zentrale Dienste 01.02.2010 Goyal Sadhna wiss. Mitarbeiter Benutzernahe Dienste und Systeme 01.02.2010 Laschka Christiane techn. Angest. Benutzernahe Dienste und Systeme 01.03.2010 Georgius Danny techn. Angest. Zentrale Dienste 01.03.2010 Kloppe Andreas techn. Angest. Zentrale Dienste 01.03.2010 Pointner Gernot stud. Hilfskraft Hochleistungssysteme 01.03.2010 Satria Winnu stud. Hilfskraft Hochleistungssysteme 01.03.2010 Schmid Benjamin techn. Angest. Zentrale Dienste 15.03.2010 Gong Jing Werkvertrag Hochleistungssysteme 01.04.2010 Bernau Christoph stud. Hilfskraft Hochleistungssysteme 01.04.2010 Crispien Marco stud. Hilfskraft Benutzernahe Dienste und Systeme 01.04.2010 Kam-Thong Tony stud. Hilfskraft Hochleistungssysteme 01.04.2010 Sollinger Florian Martin stud. Hilfskraft Kommunikationsnetze 01.05.2010 Busam Benjamin stud. Hilfskraft Benutzernahe Dienste und Systeme 01.05.2010 Etzel Oliver stud. Hilfskraft Benutzernahe Dienste und Systeme 01.05.2010 Heins Julius stud. Hilfskraft Benutzernahe Dienste und Systeme 01.05.2010 Kostadinovski Daniel techn. Angest. Zentrale Dienste 01.05.2010 Vicedo Jover Esmeralda stud. Hilfskraft Hochleistungssysteme 01.05.2010 Wiesner Christian stud. Operateur Zentrale Dienste 01.06.2010 Eickeler Felix stud. Hilfskraft Benutzernahe Dienste und Systeme 01.06.2010 Kirnberger Albert techn. Angest. Zentrale Dienste 01.08.2010 Haltmair Gena stud. Hilfskraft Zentrale Dienste 01.08.2010 Lindinger Tobias, Dr. wiss. Mitarbeiter Hochleistungssysteme 01.08.2010 Scherzei Mashud stud. Hilfskraft Zentrale Dienste 01.08.2010 Wank Andreas stud. Hilfskraft Zentrale Dienste 01.09.2010 Neumann Daniel techn. Angest. Hochleistungssysteme 01.09.2010 Ostermeier Christoph Auszubildende Zentrale Dienste 01.09.2010 Podo Alessandro Auszubildende Zentrale Dienste 01.09.2010 Schöfer Renate wiss. Hilfskraft Benutzernahe Dienste und Systeme 20.09.2010 Thiele Roman Praktikant Kommunikationsnetze 01.11.2010 Hubert Mario stud. Operateur Zentrale Dienste 01.11.2010 Längle Bernadette stud. Hilfskraft Kommunikationsnetze 01.11.2010 Willoweit Benno Praktikant Hochleistungssysteme 01.12.2010 Auweter Axel wiss. Mitarbeiter Hochleistungssysteme 01.12.2010 Leicht Ludwig stud. Hilfskraft Zentrale Dienste

164 Organisatorische Maßnahmen im LRZ

5.1.2 Abgänge

Datum Name Dienstbezeichnung Abteilung 31.01.2010 Güntner Benjamin Informationselektroniker Kommunikationsnetze 05.02.2010 Hartmann Daniel Praktikant Kommunikationsnetze 28.02.2010 Weidle Stefan stud. Hilfskraft Benutzernahe Dienste und Systeme 31.03.2010 Donauer Martin stud. Hilfskraft Benutzernahe Dienste und Systeme 30.04.2010 Anger Christian Andreas stud. Hilfskraft Benutzernahe Dienste und Systeme 30.04.2010 Dlugosch Sabine wiss. Hilfskraft Benutzernahe Dienste und Systeme 31.05.2010 Turgut Petra Verw. Angest. Zentrale Dienste 30.06.2010 Berner Stefan wiss. Mitarbeiter Hochleistungssysteme 31.07.2010 Sollinger Florian Martin stud. Hilfskraft Kommunikationsnetze 31.08.2010 Carlson Arthur, Dr. wiss. Mitarbeiter Hochleistungssysteme 31.08.2010 Metko Kerstin stud. Hilfskraft Zentrale Dienste 31.08.2010 Pointner Gernot stud. Hilfskraft Hochleistungssysteme 31.08.2010 Sutter Christopher techn. Angest. Zentrale Dienste 31.08.2010 Zellner Michael Hilfskraft Benutzernahe Dienste und Systeme 30.09.2010 Schöfer Renate wiss. Hilfskraft Benutzernahe Dienste und Systeme 30.09.2010 Stecklum Martin stud. Hilfskraft Zentrale Dienste 30.09.2010 Wagner Frederik wiss. Mitarbeiter Hochleistungssysteme 15.10.2010 Thiele Roman Praktikant Kommunikationsnetze 31.10.2010 Maier Andreas, Dr. wiss. Mitarbeiter Hochleistungssysteme 31.10.2010 Spanner Thomas stud. Operateur Zentrale Dienste 15.11.2010 Übelacker Thomas wiss. Hilfskraft Zentrale Dienste 31.12.2010 Beronov Kamen, Dr. wiss. Mitarbeiter Hochleistungssysteme 31.12.2010 Haltmair Gena stud. Hilfskraft Zentrale Dienste 31.12.2010 Hazrat Lida stud. Hilfskraft Benutzernahe Dienste und Systeme 31.12.2010 Satria Winnu stud. Hilfskraft Hochleistungssysteme 31.12.2010 Strauß Maximilian Thomas stud. Hilfskraft Benutzernahe Dienste und Systeme 31.12.2010 Sytcheva Liudmila wiss. Hilfskraft Hochleistungssysteme

5.2 Gebäudemanagement und Gebäudebetrieb Die Infrastruktur an Elektrizität und Kühlung als wichtigste Aufgabe im Bestandsbau konnte stabil betrieben werden. Hier gab es keine Betriebsunterbrechungen, auch wenn die anhaltenden Bauarbeiten für die angrenzenden Erweiterungsbauten durchaus Risiken für den Rechnerbetrieb bargen. In diesem Zusammenhang wurden u.a. folgende Arbeiten im Bestand durchgeführt: • einzelne Löschsysteme im Bestand wurden bereits demontiert: die Argonlöschung im Höchstleis- tungsrechnerraum, das Löschgas FM200 im Elektrogeschoss; als künftiger Ersatz dafür wurde die Löschtechnik „Hochdruckwassernebel“ in diesen Bereichen vorbereitet • die bisherige Westfassade einschl. Treppenhäusern wurde abgebaut, um den Erweiterungsbau nahtlos anschließen zu können. Während dieser Umbruchphase kam es durch Starkregen zu einem Wassereinbruch mit Schäden bis auf die Elektroebene im UG • die Druckerei musste in Vorbereitung eines Verbindungsganges zum Erweiterungsbau verkleinert werden • Strom- und Kältetechnik mussten mit der Bestandsstruktur gekoppelt werden, wobei die starke Schmutz- und Staubentwicklung Anlass zur Sorge wegen möglicher Langfristschäden gibt.

Jahresbericht 2010 des Leibniz-Rechenzentrums 165

5.2.1 Erweiterung des LRZ (Rechner- und Institutsgebäude) Die Bauarbeiten hatten mit der Betonierung der beiden Grundplatten für die Rechnergebäudeerweiterung und die des Institutsgebäudes (Bauteil „E“) bereits im Herbst 2009 begonnen. Im Herbst 2010 konnte der Rohbau vollendet und das Richtfest mit dem bayerischen Innenminister Herrmann als prominentem Gast und Redner gefeiert werden. Parallel zum Rohbau konnte die technische Gebäudeausstattung bereits weit vorangetrieben werden: USVs und Notstromdiesel sind eingebracht, Transformatoren und Kühlungskom- ponenten folgen noch bis Jahresende, auch der neue Anschluss ans Umspannwerk soll bis dahin fertig gestellt werden.

Abbildung 95: Prof. Bode (Vorsitzender des Direktoriums des LRZ), Bauherr Innenminister Herrmann, Landrätin Rumschöttel, Erste Bürgermeisterin von Garching Gabor, Profs Hegering und Kranzlmüller (Direktorium des LRZ), Baudirektor Hoffmann beim Richtfest am 18.10.2010 (v.l.n.r.)

Die Hauptnutzfläche der Rechnerräume wird um etwa 2/3, die Elektro- und Kühlkapazität auf insgesamt etwa das Fünffache wachsen. Die Serverkühlung wird überwiegend Wasserkühlung sein. Freie Außenluftkühlung soll in größerem Umfang als bisher umgesetzt werden. Die angestrebte sog. „Warmwasserkühlung“ (> 35°C Zulauftempe- ratur) für große Teile des nächsten Höchstleistungsrechners „SuperMUC“ konnte erreicht werden. Die entsprechend revidierte Planung - mehr „freie“ Kühlung ohne Kompressorkälte - wird derzeit umgesetzt. Zurzeit werden mit der Fa. IBM, die den Zuschlag zur Lieferung des „SuperMUC“ erhalten hat, die Be- triebsrandbedingungen und die Aufstellungsgeometrie geklärt, damit der Fertigstellungsprozess des Ge- bäudes mit den neuesten Daten fortgesetzt werden kann.

5.2.2 Energieeffizienz Der hohe und in absehbarer Zeit (ab etwa 2012) kräftig ansteigende Energieverbrauch des Leibniz- Rechenzentrums für seine Server, seine Höchstleistungsrechner und deren Kühlungsinfrastruktur verlangt nach neuen Wegen. Das in diesem Zusammenhang für Umwelt und Budget eminent wichtige Thema Energieeffizienz wurde mit folgenden Maßnahmen vertieft: • Strombeschaffung: das LRZ nutzt die Gelegenheit, nicht mehr über die TU München mit Strom versorgt zu werden, zu einer veränderten Beschaffungsweise für Strom. Der bayernweit ausge- schriebene 2-Jahres-Stromversorgungsrahmen für öffentliche Institutionen soll ab Anfang 2011

166 Organisatorische Maßnahmen im LRZ

nicht länger genutzt werden, sondern das LRZ wird versuchen, seinen weithin gleichmäßigen und vorhersehbaren Strombedarf („Grundlast“-Charakteristik) von zurzeit ca. 20 GWh/a am Strom- markt zu decken. • Maßnahmen zur energiebewussten Luftkühlung der Rechnerräume wurden vertieft: die im Vor- jahr begonnene Trennung von Warm- und Kaltluftströmen wurde verfeinert, indem Vorhänge zwischen und Blenden innerhalb der Serverracks die Trennung verstärken. • Die Kühlungsplanungen für den Erweiterungsbau wurden energetisch nochmals revidiert: es ge- lang, für den künftigen Größtverbraucher SuperMUC die neue Technik der Warmwasserkühlung (Kühlwassertemperaturen > 35°C) zu sichern, so dass einige Kältemaschinen abbestellt werden konnten. • Die Virtualisiserung von Servern wurde weiter vorangetrieben. • Der Stromverbrauch der LRZ-Server - ohne Kühlungsaufwand - liegt am Jahresende 2010 bei einem Leistungswert von o Höchstleistungsrechner: 1.050 KW o Netz- und Server: 380 KW o Daten- und Archive: 50 KW

5.2.3 Personalausstattung der Hauswerkstätte Bedingt durch Altersteilzeit wurde die Stärke des fest angestellten Personals der Hauswerkstätte auf ein Viertel reduziert. Die sehr positiven Erfahrungen mit unserem Facility-Management-Dienstleister führten dazu, dass seit Februar nicht nur die Kerndienste der Elektro-, Kühlungs-, Leit- und Gefahrentechnik von extern betreut werden, sondern auch die komplette Haus- und Veranstaltungstechnik. Allerdings sprengt die derzeitige Zusatzbelastung durch „die Baustelle“ fast die Kapazität. Hier hat sich insbesondere die Überwachung der Fremdhandwerker der Baustelle als äußerst zeitintensiv erwiesen.

5.3 Dienstleistungskatalog Der Wunsch anderer Hochschulen und wissenschaftsnaher 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 2010 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 umfassen, 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“. Diese Schrift hatte 2010 den bisher im Jahresbericht enthaltenen Teil über die Dienstleistungen des Leibniz-Rechenzentrums ersetzt und soll zukünftig regelmäßig den aktuellen Gegebenheiten angepaßt 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 über die Einteilung ist immer noch nicht vollständig abgeschlossen; er erfolgt in enger Abstimmung mit der Bayerischen Akademie der Wissenschaften und unserem Ministerium. Die Aktualisierung des sonstigen Regelwerks (u.a. auch der „Benutzungsrichtlinien des LRZ“) wurde vom Plenum der Bayerischen Akademie der Wissenschaften am 11.06.2010 ohne Ge- genstimmen beschlossen und liegt derzeit zur rechtsaufsichtlichen Genehmigung beim Bayerischen Staatsministerium für Wissenschaft, Forschung und Kunst. Trotz der noch ausstehenden Entscheidungen wurden im letzten Jahr zusätzlich zu den schon in den Vor- jahren erbrachten Dienstleistungen aus dem Bereich der Kommunikationsnetze (Mitnutzung des Münch- ner Wissenschaftsnetzes sowie die Betreuung lokaler Infrastrukturen), dem Bereich des Hostings von Clusterknoten für die Exzellenz-Initiative, dem Bereich Backup-/Archiv- und Langzeitarchivierung für die Bayerische Staatsbibliothek, weitere Dienste für die Hochschulen und die Bayerische Staatsbibliothek insbesondere aus dem Bereich Hosting virtueller Server erbracht.

Jahresbericht 2010 des Leibniz-Rechenzentrums 167

5.4 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 • Wissenschaftsrat: Nationaler Koordinierungsausschuss für Höchstleistungsrechnen • IFIP/IEEE: Diverse Working Groups, Program and Organization Committees • GI: Erweitertes Leitungsgremium Fachgruppe KIVS • IT-Beirat fuer das Bibliothekswesen Bayerns (Bayerische Universitäts- und Fachhochschul- bibliotheken), ehemals: Kommission für EDV-Planung • D-Grid Beirat • DEISA Executive Committee • Gauss Centre for Supercomputing (GCS) • Gauß Allianz • PRACE Management Board • PRACE Council • PROSPECT • GEG (Géant Expert Group)

5.4.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 Metadirectory und Arbeitskreis AAIVHB-Arbeitskreis Authentifizierungs- und Autorisierungsinfrastruktur • DFN-Arbeitsgruppe DFN-AAI • DFN-Arbeitsgruppe E-Learning

5.4.2 Abteilung „Hochleistungssysteme“ • ZKI-Arbeitskreis Supercomputing • KONWIHR (Kompetenznetzwerk für Technisch-Wissenschaftliches Hoch- und Höchstleistungs- rechnen in Bayern) • UNICORE Forum (UNICORE User Group) • D-Grid Technical Advisory Board (TAB) • OGF Production Grid Interoperability (PGI) working group • NGI-DE Joint Research Unit (JRU) • SGI User Group • 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 (SS22), Working Group 5 Fortran) • STRATOS (PRACE Advisory Group for Strategic Technologies) • IESP (International Exascale Software Project)

168 Organisatorische Maßnahmen im LRZ

• EESI (European Exascale Software Initiative)

5.4.3 Abteilung „Kommunikationsnetze“ • BHN (Bayerisches Hochschulnetz) • ZKI-Arbeitskreis Netzdienste • Projektgruppe Datenverkabelung (öffentlicher Gebäude in Bayern) • 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 • International Conference on Networking and Services (ICNS 2010) • The Fourth International Conference on Advanced Engineering Computing and Applications in Sciences (ADVCOMP 2010) • DFN Forum Kommunikationstechnologien 2010 • DFN CERT Workshop 2010 • Second International Conference on Resource Intensive Applications and Services (INTENSIVE 2010) • International Symposium on Integrated Network Management (IM 2011) • Principles, Systems and Applications of IP Telecommunications (IPTComm 2011)

5.4.4 Abteilung „Zentrale Dienste“ • ZKI-Arbeitskreis Softwarelizenzen • ZKI-Arbeitskreis Service-Management und Sicherheit • BSK-Arbeitskreis (Bayerische Software-Kooperation)

5.5 Veranstaltungen am LRZ Titel Datum

Cloud Camp 21.01.2010 ISO/IEC 27000 Foundation (ITSM 0401) 02.02.2010 Microsoft Uni Roadshow 02. – 03.02.2010 Programming with Fortran 08. – 12.02.2010 DEISA WP 3,4,6 09. – 10.02.2010 PRACE Languages and Prototype Workshop 01. – 02.03.2010 ISO/IEC 20000 01. – 05.03.2010 Paralleles Programmieren 08. – 12.03.2010 NGI-DE Meeting 19.03.2010 ITSM Kompaktseminar 13. – 16.04.2010 Girls Day 22.04.2010 ISO/IEC 20000 Kurs 03. – 05.05.2010 und 07.05.2010 PROSPECT Meeting 05.05.2010 ISHARe Meeting 10. – 12.05.2010

Jahresbericht 2010 des Leibniz-Rechenzentrums 169

DRIHMS Workshop 17. – 18.05.2010 ITSM Workshop Airport Simulation 29.06.2010 DEISA Review Meeting 29. – 30.06.2010 BGCE Research Day 01.07.2010 KONWIHR Workshop 12.07.2010 Parallel Programming with CILK 12. – 13.07.2010 HP Networking Technology Day 14.07.2010 Bayerischer Arbeitskreis Virtualisierung 23.09.2010 DGSI Plenarmeeting 27. – 28.09.2010 PRACE 1IP KickOff 30. – 31.09.2010 Iterative Gleichungslösung und Parallelisierung 04.- 08.10.2010 Advanced Fortran 11. – 15.10.2010 ITSM Kompaktseminar 12. – 14.10.2010 IGE Kickoff 18. – 22.10.2010 Strategisches IT-Management 21.10.2010/11.11.2010/25.11.2010/09.12.2010 Stratos Management Board Meeting and General 07.12.2010 Assembly Stratos Steering Board Meeting 20.12.2010

5.6 Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstal- tungen

5.6.1 Abteilung „Benutzernahe Dienste und Systeme“ • HW-Beschaffung Bayern Vorbereitung PC-Ausschreibung -Herstellerpräsentation- 27.01.2010 - 27.01.2010 Nürnberg (Hartmannsgruber) • HW-Beschaffung Bayern Vorbereitung PC-Ausschreibung -Herstellerpräsentation- 04.02.2010 - 04.02.2010 Nürnberg (Hartmannsgruber) • ZKI Treffen des AK Verzeichnisdienste 08.02.2010 - 09.02.2010 Mannheim (Ebner) • AK Netz PC Treffen 11.03.2010 - 11.03.2010 Regensburg (Fakler) • Treffen mit Vodafone - Mobile Tarife und Best Practice 13.04.2010 - 13.04.2010 Regensburg (Schreiner) • ATT Novel Identity Manager 19.04.2010 - 24.04.2010 Düsseldorf (Goyal) • Transport der Poster in die Uni 12.05.2010 - 12.05.2010 München (Podo) • HW-Beschaffung Bayern Vorbereitung Apple Ausschreibung 12.05.2010 - 12.05.2010 Nürnberg (Hartmannsgruber) • EUNIS Konferenz (eigener Vortrag) 22.06.2010 - 25.06.2010 Warschau -PL (Gillmeister) • Security-Vorträge am Gymnasium 06.07.2010 - 06.07.2010 Penzberg (Bötsch) • AK Meta Directory und AK AAI 07.07.2010 - 07.07.2010 Passau (Ebner)

170 Organisatorische Maßnahmen im LRZ

• Besprechung zur Nachfolgelösung des SOPHOS Landeslizenzvertrages 16.09.2010 - 16.09.2010 Regensburg (Fakler, Hartmannsgruber) • Solaris System Performance Tuning 20.09.2010 - 24.09.2010 Heimstetten (Braun) • Secuity-Vorträge am Gymnasium 22.09.2010 - 22.09.2010 Landshut (Bötsch) • DV-Fachseminar 22.09.2010 - 29.09.2010 Paderborn (Oesmann) • Sitzung des AK Netz PC 23.09.2010 - 23.09.2010 Nürnberg (Feck) • ZKI Herbsttreffen 03.10.2010 - 05.10.2010 Duisburg (Ebner) • Besprechung zur Nachfolgelösung des SOPHOS Landeslizenzvertrages 14.10.2010 - 14.10.2010 Regensburg (Fakler , Hartmannsgruber) • AntiVir-Bayern Marktanalyse und Ausschreibungsvorbereitung 01.12.2010 - 03.12.2010 Regensburg (Hartmannsgruber)

5.6.2 Abteilung „Hochleistungssysteme” • VM Ware-Kurs bei HP 18.01.2010 - 22.01.2010 Hulb (Berner) • Workshop Virtualisierung im D-Grid 28.01.2010 - 28.01.2010 Erlangen (Maier) • PRACE TB Meeting 02.02.2010 - 02.02.2010 Paris -FR (Christadler) • PRACE-Hearing, Vormeeting 08.02.2010 - 10.02.2010 Brüssel -BE (Heller) • IBM Laborbesuch 08.02.2010 - 08.02.2010 Böblingen (Brehm, Huber) • EU Proposal Hearing, Call FP7 Infrastructures 2010-2 09.02.2010 - 12.02.2010 Brüssel -BE (Jamitzky, Satzger) • Hearing für EU-Projekt VERCE 09.02.2010 - 11.02.2010 Brüssel -BE (Frank) • AK Netz PC Techn. Workshop VM Ware View 09.02.2010 - 09.02.2010 Nürnberg (Berner) • Meeting of ISO/IEC JTC1/SC22/WG5 14.02.2010 - 21.02.2010 Las Vegas -US (Bader) • Besuch des Klimarechenzentrums 17.02.2010 - 17.02.2010 Hamburg (Baur, Peinkofer) • GCS Marketing Meeting 19.02.2010 - 19.02.2010 Bonn (Brehm) • GPFS Expertenworkshop 22.02.2010 - 23.02.2010 Mainz (Kleinhenz) • PRACE WP6 HPC Workshop (eigener Vortrag) 27.02.2010 - 02.03.2010 Leogang -AT (Rivera) • Konferenz Globus World 01.03.2010 - 06.03.2010 Argonne -US (Heller) • ZKI Arbeitskreis Supercomputing 04.03.2010 - 05.03.2010 Hamburg (Wagner) • LRZ Workshop Parallel Programming of High Performance Systems 08.03.2010 - 12.03.2010 Erlangen (Bader) • LRZ Workshop Parallel Programming of High Performance Systems 08.03.2010 - 10.03.2010 Erlangen (Müller) • ZKI Treffen des AK Sys 09.03.2010 - 11.03.2010 Witten (Biardzki)

Jahresbericht 2010 des Leibniz-Rechenzentrums 171

• OGF-Meeting 15.03.2010 - 18.03.2010 München (Maier) • DEISA2 WP8 Face-to-Face Meeting 17.03.2010 - 19.03.2010 Barcelona -ES (Leong) • Konferenz "Facing the Multicore-Challenge" 17.03.2010 - 19.03.2010 Heidelberg (Christadler) • BG/P Extreme Scaling Workshop 21.03.2010 - 24.03.2010 Jülich (Allalen) • D-Grid All Hands Meeting 22.03.2010 - 24.03.2010 Dresden (Paisios) • Workshop 22.03.2010 - 25.03.2010 Kochel am See (Guillen) • D-Grid All Hands Meeting 22.03.2010 - 24.03.2010 Dresden (Carlson, Saverchenko) • Workshop EU-Russia Joint Call 25.03.2010 - 25.03.2010 Brüssel -BE (Brehm) • IGE Meeting 29.03.2010 - 31.03.2010 Brüssel -BE (Frank) • Operations Workshop EGEE-NGI-DE-transition 30.03.2010 - 30.03.2010 Karlsruhe (Saverchenko) • IGE Meeting 30.03.2010 - 31.03.2010 Brüssel -BE (Heller) • EGI-Meeting Cern 06.04.2010 - 07.04.2010 Genf -CH (Heller) • IESP Workshop 12.04.2010 - 14.04.2010 Oxford -GB (Huber) • CUDA Training 18.04.2010 - 22.04.2010 Jülich (Allalen, Weinberg) • DEISA All Hands Meeting (WP 4) 19.04.2010 - 20.04.2010 Paris -FR (Laitinen) • DEISA All Hands Meeting (WP 7) 19.04.2010 - 20.04.2010 Paris -FR (Beronov) • SLA4 Dgrid 2. Workshop 04.05.2010 - 04.05.2010 Berlin (Paisios) • IDRIS Seminar on Co-array Fortran (eigener Vortrag) 05.05.2010 - 06.05.2010 Paris -FR (Bader) • DEISA Training 05.05.2010 - 06.05.2010 London -GB (Leong) • DEISA PRACE Symposium (eigener Vortrag) 11.05.2010 - 12.05.2010 Barcelona -ES (Huber) • LRZ-CEA Collaboration 19.05.2010 - 20.05.2010 Paris -FR (Brehm, Huber, Steinhöfer) • Lustre Workshop 25.05.2010 - 26.05.2010 Jülich (Steinhöfer) • ISC 2010 28.05.2010 - 03.06.2010 Hamburg (Brehm, Christadler Jamitzky, Satzger, Steinhöfer) • Engaging European DCIs together 31.05.2010 - 01.06.2010 Brüssel -BE (Heller) • ROD Teams Workshop 31.05.2010 - 03.06.2010 Amsterdam -NL (Zrenner) • ISC 2010 31.05.2010 - 02.06.2010 Hamburg (Huber) • ROD Teams Workshop 01.06.2010 - 03.06.2010 Amsterdam -NL (Frank) • 6 th Erlangen International High-End-Computing Symposium

172 Organisatorische Maßnahmen im LRZ

04.06.2010 - 04.06.2010 Erlangen (Rivera) • 2. Treffen der DGI Monitoring Task Force 09.06.2010 - 09.06.2010 Jülich (Saverchenko) • Workshop High Performance Computing, Grids and Clouds 20.06.2010 - 26.06.2010 Cetraro -IT (Heller) • CiHPC Meeting 21.06.2010 - 24.06.2010 Schwetzingen (Hesse) • EESI WP3 and WP4 joint preliminary meeting 28.06.2010 - 28.06.2010 Paris -FR (Huber) • Erweitertes VO-Management Workshop und Mailingliste 29.06.2010 - 29.06.2010 Karlsruhe (Paisios) • Projekttreffen SLA4 Dgrid 05.07.2010 - 05.07.2010 Stuttgart (Paisios) • Kooperation und Besuch der Lomonossov Universität und t-platforms 07.07.2010 - 09.07.2010 Moskau –RU (Brehm, Huber) • Intel Ct Training 24.08.2010 - 26.08.2010 Feldkirchen (Weinberg) • Inca Workshop 25.08.2010 - 31.08.2010 San Diego -US (Saverchenko) • Eigener Vortrag an der Summer School der KTH 26.08.2010 - 27.08.2010 Stockholm -SE (Christadler) • Workshop Distributed Computing and Multidisciplinary Sciences 28.08.2010 - 03.09.2010 Washington -US (Heller) • EuroPar Konferenz 29.08.2010 - 03.09.2010 Ischia -IT (Guillen) • Workshop DGI-2/ FG-2 01.09.2010 - 02.09.2010 Jülich (Paisios, Saverchenko ) • PRACE Management Board Meeting 03.09.2010 - 03.09.2010 Frankfurt am Main (Huber) • Globus-Schulung (eigener Vortrag) 06.09.2010 - 10.09.2010 Karlsruhe (Laitinen, Zrenner) • Workshop Open LUSTRE-for Linux 06.09.2010 - 07.09.2010 Jülich (Biardzki) • EGI Technical Meeting 12.09.2010 - 18.09.2010 Amsterdam -NL (Zrenner) • DEISA Training Course 13.09.2010 - 16.09.2010 Edinburgh -GB (Leong) • EGI Technical Forum 14.09.2010 - 17.09.2010 Amsterdam -NL (Heller, Saverchenko) • EGI Technical Meeting (Projektbetreuung) 15.09.2010 - 17.09.2010 Amsterdam -NL (Frank) • ENA-HPC Konferenz 15.09.2010 - 17.09.2010 Hamburg (Biardzki) • Briefing zum Archivserversystem 20.09.2010 - 20.09.2010 Mainz (Baur, Peinkofer) • DV-Fachseminar 22.09.2010 - 29.09.2010 Paderborn (Hufnagl) • Arbeitstreffen SGI User Group 26.09.2010 - 28.09.2010 Hamburg (Weinberg) • ScalaLife Kick-off Meeting 27.09.2010 - 29.09.2010 Stockholm -SE (Allalen, Jamitzky, Satzger) • PRACE Final Review 30.09.2010 - 01.10.2010 Brüssel -BE (Huber) • 2nd European Workshop on HPC Centre Infrastructures 05.10.2010 - 08.10.2010 Dourdan -FR (Huber)

Jahresbericht 2010 des Leibniz-Rechenzentrums 173

• Mapper Kick-Off-Meeting 06.10.2010 - 08.10.2010 Amsterdam -NL (Saverchenko) • Projekttreffen SLA4 Dgrid 07.10.2010 - 08.10.2010 Jülich (Paisios) • DEISA Arbeitstreffen WP 3,4,6 12.10.2010 - 15.10.2010 Helsinki -FI (Maier, Saverchenko) • DEISA-Arbeitstreffen WP 2, 3, 4, 6 12.10.2010 - 15.10.2010 Helsinki -FI (Heller) • DEISA-Arbeitstreffen WP 8 12.10.2010 - 15.10.2010 Helsinki -FI (Leong) • DEISA-Arbeitstreffen WP 3, 4, 7 12.10.2010 - 15.10.2010 Helsinki -FI (Laitinen) • DEISA Arbeitstreffen WP 2,5,7 13.10.2010 - 15.10.2010 Helsinki -FI (Beronov) • Face-to-Face Meeting PRACE 1 IP 18.10.2010 - 20.10.2010 Amsterdam -NL (Christadler) • Face-to-Face Meeting 19.10.2010 - 20.10.2010 Amsterdam -NL (Huber) • OGF 30 /Grid 2010 24.10.2010 - 29.10.2010 Brüssel -BE (Heller) • PRACE Autumn School 24.10.2010 - 30.10.2010 Barcelona -ES (Allalen) • 6 th International Conference on Network and Services Management (eigene Präsentation) 24.10.2010 - 01.11.2010 Toronto -CA (Lindinger) • UNICORE Forum Members ZKI Arbeitskreis Supercomputing Herbsttreffen 27.10.2010 - 28.10.2010 Göttingen (Wendler) • Blender Conference 2010 (eigener Vortrag) 28.10.2010 - 01.11.2010 Amsterdam -NL (Satzger) • Open Source CFD Intern. Conference 2010 04.11.2010 - 05.11.2010 München (Rivera) • EESI International Workshop 08.11.2010 - 09.11.2010 Amsterdam -NL (Huber) • ISC 2010 12.11.2010 - 20.11.2010 New Orleans -US (Brehm, Bader, Jamitzky) • WP Leaders Face-to-Face Meeting 12.11.2010 - 12.11.2010 Jülich (Huber) • ISC 2010 12.11.2010 - 20.11.2010 New Orleans -US (Christadler, Satzger) • ISC 2010 14.11.2010 - 20.11.2010 New Orleans -US (Huber) • BMBF-Statustagung zum HPC-Isar-Projekt 23.11.2010 - 24.11.2010 Berlin (Guillen) • Meeting zum Deep-Projekt 26.11.2010 - 26.11.2010 Jülich (Huber) • Intel Software Customer Advisory Board (eigener Vortrag) 30.11.2010 - 03.12.2010 Nizza -FR (Bader) • Vmware vSpere 4: Troubleshooting 06.12.2010 - 09.12.2010 Hallbergmoos (Roll) • PRACE 1IP WP7 Face-to-Face Meeting 14.12.2010 - 17.12.2010 Bologna -IT (Rivera, Weinberg) • e-IRGSP3-proposal Kick-off 14.12.2010 - 15.12.2010 Den Haag -NL (Frank) • PRACE 1IP WP7 Face-to-Face Meeting 14.12.2010 - 16.12.2010 Bologna -IT (Christadler) • Seminar (eigener Vortrag)

174 Organisatorische Maßnahmen im LRZ

15.12.2010 - 16.12.2010 Paris -FR (Heller)

5.6.3 Abteilung „Kommunikationsnetze“ • First TF/ CSIRT Meeting 25.01.2010 - 27.01.2010 Hamburg (Metzger) • EWNI 2010 - Call for Papers 27.01.2010 - 27.01.2010 Hamburg (von Eye) • Workshop Virtualisierung im D-Grid 28.01.2010 - 28.01.2010 Erlangen (von Eye) • D-Grid Beiratssitzung 05.02.2010 - 05.02.2010 Hannover (Reiser) • Jährlicher LKN Workshop 05.02.2010 - 05.02.2010 Grainau (Lichtinger) • 17. DFN Workshop "Sicherheit in vernetzten Systemen 09.02.2010 - 10.02.2010 Hamburg (Reiser) • Sitzung des BHN-AK 25.02.2010 - 25.02.2010 Erlangen (Reiser, Tröbs) • 52. DFN Betriebstagung 02.03.2010 - 03.03.2010 Berlin (Marcu) • D-Grid All Hands Meeting 22.03.2010 - 24.03.2010 Dresden (von Eye) • Konferenz ICN2010 (eigener Vortrag) 10.04.2010 - 16.04.2010 Les Menuires -FR (Fritz) • Treffen mit Vodafone - Mobile Tarife und Best Practice 13.04.2010 - 13.04.2010 Regensburg (Gebert) • Weltleitmesse für Architektur und Technik 15.04.2010 - 15.04.2010 Frankfurt (Glose) • MeetITil Kongress 18.04.2010 - 22.04.2010 Bad Neuenahr (Brenner) • MeetITil Kongress 19.04.2010 - 22.04.2010 Bad Neuenahr (Richter Chr.) • OSI Forum 2010 27.04.2010 - 28.04.2010 Schlangenbad (Glose) • RIPE 60 Meeting 03.05.2010 - 07.05.2010 Prag -CZ (Schmidt) • Seminar Cisco Forum für Forschung und Lehre 05.05.2010 - 06.05.2010 Würzburg (Meschederu) • RES-ITIL Seminar + Präsentation 17.05.2010 - 20.05.2010 Santander -ES (Brenner) • DFN Forum 2010 26.05.2010 - 27.05.2010 Konstanz (Reiser) • DFN: 60. Mitgliederversammlung 07.06.2010 - 08.06.2010 Berlin (Reiser) • Beiratstreffen D-Grid 11.06.2010 - 11.06.2010 Frankfurt (Reiser) • Statusmeeting des 100GET-Projektes 15.06.2010 - 17.06.2010 Stuttgart (Lichtinger) • DNSSEC Meeting 16.06.2010 - 16.06.2010 Frankfurt (Schmidt) • Secure Code Training 21.06.2010 - 24.06.2010 Poznan -PL (Fritz) • 9th RoEduNet Conference (eigener Vortrag) 23.06.2010 - 27.06.2010 Sibiu -RO (Hommel, Marcu) • GIDS Meeting

Jahresbericht 2010 des Leibniz-Rechenzentrums 175

30.06.2010 - 30.06.2010 Hamburg (von Eye) • 7th International Conference on Services Computing IEEE SCC 2010 03.07.2010 - 12.07.2010 Miami -US (Yampolskiy) • 1st International Workshop on the perfSONAR Network Measurement Infrastructure 06.07.2010 - 10.07.2010 Washington -US (Fritz) • 10th Workshop on IP EuroView 2010 01.08.2010 - 03.08.2010 Würzburg (Lichtinger) • GN3 Summer Developers School 29.08.2010 - 03.09.2010 Gdansk -PL (Fritz, Marcu, Schmitz, Yampolskiy) • Internet 2000 Konferenz 19.09.2010 - 26.09.2010 Valencia -ES (Yampolskiy) • IBM Tivoli Network Manager 3.8 Workshop 19.09.2010 - 22.09.2010 Hamburg (Loidl, Tröbs) • D-Grid Security Workshop 29.09.2010 - 30.09.2010 Göttingen (von Eye) • Beiratssitzung D-Grid 04.10.2010 - 04.10.2010 Hannover (Reiser) • BHN-Sitzung 14.10.2010 - 14.10.2010 Passau (Reiser, Tröbs) • DFN Tutorium und Betriebstagung 25.10.2010 - 27.10.2010 Berlin (Metzger) • Netforum Expertentagung 27.10.2010 - 28.10.2010 Meckenbeuren (Glose) • DENOG2-Meeting 04.11.2010 - 04.11.2010 Frankfurt (Schmidt) • Schulung F5 LTM Training 11.11.2010 - 12.11.2010 Dornach (Kornberger) • Service Computation 2010 (eigener Vortrag) 20.11.2010 - 26.11.2010 Lissabon -PT (Yampolskiy) • IPv6 Deployment Council (eigener Vortrag) 23.11.2010 - 23.11.2010 Hallbergmoos (Reiser, Schmidt) • 2th GN3 Symposium 24.11.2010 - 26.11.2010 Wien -AT (Fritz, Schmitz) • DFN-Mitgliederversammlung 30.11.2010 - 01.12.2010 Bonn (Reiser)

5.6.4 Abteilung „Zentrale Dienste“ • 2. Netzwerktreffen NEMO Green IT 14.01.2010 - 14.01.2010 Meckenbeuren (Breinlinger) • BSK Sitzung 27.01.2010 - 27.01.2010 Würzburg (Diehn) • Gutachtersitzung Netz 2010 17.02.2010 - 18.02.2010 Münster (Apostolescu) • BSK-Sitzung 02.03.2010 Hochschule München (Diehn, Palm) • ZKI Arbeitskreis Software-Lizenzen 21.03.2010 - 22.03.2010 Berlin (Diehn) • Wirtschaftsprüfer Dr. Küfner 16.04.2010 - 16.04.2010 Landshut (Apostolescu) • BRZL-Klausurtagung 20.04.2010 - 21.04.2010 Hirschberg (Apostolescu) • Workshop „Punktgenau Texten“ 28.04.2010 gate Garching (Palm) • Personal-Fachinformation

176 Organisatorische Maßnahmen im LRZ

29.06.2010 - 29.06.2010 München (Apel) • DFN Betriebsausschussitzung 30.06.2010 - 30.06.2010 Berlin (Apostolescu) • Wirtschaftsprüfer Dr. Küfner 28.07.2010 - 28.07.2010 Landshut (Apostolescu) • Teilnahme am erweiterten Projektsteuerkreis GCS in Bonn 25.08.2010 - 25.08.2010 Bonn (Apostolescu) • Wirtschaftsprüfer Dr. Küfner 02.09.2010 - 02.09.2010 Landshut (Apostolescu) • DV-Fachseminar 22.09.2010 - 29.09.2010 Paderborn (Mende) • 4th Workshop on HPC Best Practices: Power Management 25.09.2010 - 01.10.2010 San Francisco -US (Breinlinger) • ZKI Arbeitskreis Software-Lizenzen Herbsttreffen 27.09.2010 - 29.09.2010 Merseburg (Diehn) • Query-Schulung 06.10.2010 - 06.10.2010 München (Apel) • BSK Sitzung 12.10.2010 - 12.10.2010 Bamberg (Diehn) • Power Building Kongress 13.10.2010 - 14.10.2010 München (Kirnberger) • Besprechung zur Nachfolgelösung des SOPHOS Landeslizenzvertrages 14.10.2010 - 14.10.2010 Regensburg (Diehn) • Werksabnahme von Schaltschränken 15.11.2010 - 15.11.2010 Salzburg -AT (Kirnberger) • Meeting zum Deep-Projekt 25.11.2010 - 26.11.2010 Jülich (Palm) • AntiVir-Bayern Marktanalyse und Ausschreibungsvorbereitung 02.12.2010 - 03.12.2010 Regensburg (Diehn) • Jahresschluss-Tagung TVöD/TV-L 08.12.2010 - 08.12.2010 München (Apel) • Info-Veranstaltung zur Verlängerung des Campus-Vertrages mit Microsoft 15.12.2010 - 15.12.2010 Nürnberg (Diehn)

5.7 Öffentlichkeitsarbeit Seine originären Dienstleistungen als Rechenzentrum der Hochschulen stellte das LRZ u.a. wieder bei der Erstsemesterbegrüßung an der LMU vor. Wie auch in den vergangenen Jahren war das LRZ „Location“ für Foto- und Filmaufnahmen z.B. des Bayerischen Rundfunks oder RTL, für das MPI für Astrophysik, einen Werbefilm für das Informatikstu- dium an der TU München oder künstlerische Technik-Aufnahmen. Der Dokumentarfilm „Plug & Pray“ von Jens Schanze, für den ebenfalls Szenen am LRZ gedreht wurden, wurde vielfach, u.a. mit dem Baye- rischen Filmpreis als „Bester Dokumentarfilm 2010“ ausgezeichnet. Immer häufiger suchen auch die überregionalen Printmedien den Direktor des LRZ oder seine Wissenschaftlichen Mitarbeiter als Ge- sprächspartner. In der „Langen Nacht der Wissenschaften“ am 15. Mai 2010 nutzten etwa eintausend Besucherinnen und Besucher die Möglichkeit, das LRZ zu besichtigen. Auch das Angebot des LRZ zum Girls Day war wieder vollständig ausgebucht. Insgesamt nahmen ca. 2.650 Besucherinnen und Besucher an etwa 90 Füh- rungen teil. Bemerkenswert ist die Zunahme der europaweiten und internationalen Aktivitäten des LRZ, die auch in der wissenschaftlichen und allgemeinen Öffentlichkeit wahrgenommen werden. So beteiligte sich das LRZ an der Organisation des Open Grid Forums im März 2010. Dessen Besuch nutzten Dr. Kostas Gli- nos und Dr. Kyriakos Baxevanidis von der Kommission der Europäischen Union für eine Besichtigung des LRZ. Im August trafen sich am LRZ 121 Teilnehmer aus 21 europäischen Ländern, um den Eintritt

Jahresbericht 2010 des Leibniz-Rechenzentrums 177 des europäischen PRACE-Projektes in eine wichtige Phase zu starten. Und im Oktober besichtigte der Russische Staatsminister für Kommunikation und Massenmedien Igor Shchegolev das LRZ. Einen weiteren Ministerbesuch und ein äußerst großes nationales und internationales Medienecho erlebte das LRZ anlässlich der Unterzeichnung des Vertrages über den nächsten Höchstleistungsrechner. In An- wesenheit des Bayerischen Staatsministers für Wissenschaft, Forschung und Kunst, Dr. Wolfgang Heu- bisch, unterzeichneten am 13. Dezember 2010 Prof. Dr. Arndt Bode und Martin Jetter, Vorsitzender der Geschäftsführung der IBM Deutschland GmbH, den Vertrag für den „SuperMUC“. Das LRZ gab gemeinsam mit dem NIC Jülich und dem Hochleistungsrechenzentrum Stuttgart zweimal im Jahr anlässlich der Supercomputing-Konferenzen die Zeitschrift „inSiDE – Innovatives Supercompu- ting in Deutschland“ mit Beiträgen über Projekte, die auf dem Höchstleistungsrechner des LRZ bearbeitet wurden, heraus. 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 oder Englisch an die allgemeine Öffentlich- keit wenden oder speziell für Studenten die Dienstleistungen des LRZ vorstellen. Für die Zusammenarbeit mit den Medien erwies es sich als äußerst vorteilhaft, ihnen einen festen An- sprechpartner (http://www.lrz.de/presse/) nennen zu können.

5.8 LRZ als Ausbildungsbetrieb Seit 2007 ist das LRZ als Ausbildungsbetrieb anerkannt und bietet Ausbildungsplätze für IT-System- Elektroniker und Fachinformatiker Systemintegration an. Im Jahr 2010 haben die ersten Auszubildenden ihre Ausbildung am LRZ erfolgreich abgeschlossen. Durch eine im Rahmen der Altersteilzeit freiwerden- de Stelle konnte ein Auszubildender erfolgreich übernommen werden. Die bisherigen Erfahrungen mit den Auszubildenden sind so positiv, dass auch mit Beginn des Ausbildungsjahres 2010/2011 zwei weitere Auszubildende eingestellt wurden (1 Fachinformatiker Systemintegration, 1 IT-Systemelektroniker). Auch für das Ausbildungsjahr 2011/2012 ist geplant, wieder zwei Auszubildende einzustellen. Die Be- werberauswahl hierzu hat bereits Ende 2010 in Kooperation mit der Technischen Universität München stattgefunden.

5.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:

• Xia, W., Evaluation des TUM–Trouble Ticket Systems als Ersatz für bestehende lokale Konfigu- rationsmanagementdatenbanken, Fortgeschrittenenpraktikum, Ludwig–Maximilians–Universität München, Januar, 2010. • Nguyen, T. H., Erweiterung des TUM Trouble Ticket Systems um IT Service Management Kom- ponenten, Systementwicklungsprojekt, Technische Universität München, März, 2010.

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

• Abeldt, P., Einführung von Multi–Protocol Label Switching (MPLS) im Münchner Wissen- schaftsnetz, Diplomarbeit, Ludwig–Maximilians–Universität München, September 2010. • Hauser, M., Toolgestützte Umsetzung von Change–Verfahren für VM–Provisioning nach ISO/IEC 20000, Diplomarbeit, Ludwig–Maximilians–Universität München, Juni 2010 • Müller, A., Linux-basierte Personal Firewall für den Einsatz am LRZ, Fortgeschrittenen- praktikum, Ludwig-Maximilians-Universität München, November 2010.

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

178 Organisatorische Maßnahmen im LRZ

• Schulz, Chr., Beurteilung der Sicherheit von Proxy Zertifikaten im Globus Toolkit, Fortgeschrit- tenenpraktikum, Ludwig-Maximilians-Universität München, September 2010.

5.10 Veröffentlichungen der Mitarbeiter 2010 ALLALEN M., M. BREHM, H. STUEBEN, Combining MPI with OpenMP Parallelism in Large Scale QCD Simulations, inSiDE Vol. 8, No. 2, Spring (2010) ALLALEN M., H. SATZGER, F. JAMITZKY, Real World Application Acceleration with GPGPUs, inSiDE Vol. 8, No. 1, Spring (2010) BADER R., A. BLOCK, PGAS – Incorporating parallelism into C and Fortran. PRACE workshop, LRZ. Februar 2010. (http://www.prace-project.eu/documents/12_cafupc_rb.pdf) BADER R., A. BLOCK, PGAS concepts for classical HPC programming languages. Vortrag am IDRIS, Frankreich. Mai 2010. (http://www.idris.fr/data/seminaires/2009-2010/Seminaire-IDRIS-du-6-mai- 2010.html) BADER R., Contributions to WG5 paper N1835 (Requirements for TR of further coarray features, by J. Reid). September 2010. (ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1835.txt) BODE A., IntegraTUM-Lehren aus einem universitären Großprojekt. In: Bode/Borgeest (Hrsgb.): Infor- mationsmanagement in Hochschulen. pp.3-12, Springer, Heidelberg 2010 BODE A., R. BORGEEST, Informationsmanagement in Hochschulen. 446 pp., Springer, Heidelberg, 2010 BENEDICT S., M. BREHM, M. GERNDT, C. GUILLEN, W. HESSE, V. PETKOV, Automatic Perfor- mance Analysis of Large Scale Simulations. In: Proceedings of the Euro-Par 2009 Parallel Processing Workshops. Springer, 2010 BIARDZKI C., W. BAUR, B. REINER, Integrierte Speichersystem-Architektur zur Unterstützung hoch- schulübergreifender IT-Dienste. In: Informationsmanagement in Hochschulen. Springer, 2010 CARLE G., H. REISER, G. CAMARILLO, V. K. GURBANI, (Eds.): Principles, Systems and Applica- tions of IP Telecomunications; Proceedings of IPTComm 2010, Network Architecture and Services, NET 2010-08-1, August 2010 CARLE G., H. REISER, G. CAMARILLO, V. K. GURBANI, (Eds.): Principles, Systems and Applica- tions of IP Telecommunications; Proceedings of IPTComm 2010, ACM Digital Library, 2010 CHRISTADLER I., V. WEINBERG, RapidMind: Portability across Architectures and its Limitations. In: Facing the Multicore-Challenge: Aspects of New Paradigms and Technologies in Parallel Computing (Lecture Notes in Computer Science / Theoretical Computer Sci), Springer 2010 DIAZ M., D. AVRESKY, A. BODE, C. BRUNO, E. DEKEL, Cloud Computing. 271 pp., Springer Hei- delberg, 2010 DIEHN M., IntegraTUM Teilprojekt E-Mail: Aufbau eines man-dantenfähigen Groupware-Services und seine Integration in Identity Management und E-Mail Infrastruktur der Technischen Universität München. In: Informationsmanagement in Hochschulen. Springer, Januar 2010 DIEHN M., A. HAARER , A. SCHREINER, M. STORZ, IntegraTUM Teilprojekt E-Mail: Rezentralisie- rung von E-Mail-Services. In: Informationsmanagement in Hochschulen. Springer, Januar 2010 GONG J., W. TIANDI, R. W. STARK, F. JAMITZKY, W. M. HECKL, H. J. ANDERS, M. LECH, S. C. RÖSSLE, Inhibition of Toll-like receptors TLR4 and 7 signaling pathways by SIGIRR: A computational approach, Journal of Structural Biology, Volume 169, Issue 3, March 2010, Pages 323-330 GONG J., W. TIANDI, N. ZHANG, F. JAMITZKY, W. M. HECKL, S. C. RÖSSLE, R. W. STARK, TollML: a database of toll-like receptor structural motifs Journal of Molecular Modeling, Volume 16, Number 7, 1283-1289 HAMM M. K., S. KNITTL, P. MARCU, M. YAMPOLSKIY, Modellierung Interorganisationaler It– Service–Managementprozesse, Praxis der Informationsverarbeitung und Kommunikation, 2010, K.G. Saur, München, Germany, Dezember, 2010 ILGENFRITZ M., K. KOLLER, Y. KOMA, G. SCHIERHOLZ, V. WEINBERG, Topological Structure of the QCD Vacuum Revealed by Overlap Fermion. In: High Performance Computing in Science and Engineering, Garching/Munich 2009, Springer 2010

Jahresbericht 2010 des Leibniz-Rechenzentrums 179

JAMITZKY F., R. W. STARK, Intermittency in amplitude modulated dynamic atomic force microscopy, Ultramicroscopy Volume 110, Issue 6, May 2010, Pages 618-621 KONIGES A. E., K. YELICK, R. RABENSEIFNER, R. BADER, D. EDER, Supercomputing Tutorial S10: Introduction to PGAS (UPC and CAF) and Hybrid for Multicore Programming. Refereed Tutorial. November 2010. (http://sc10.supercomputing.org/schedule/event_detail.php?evid=tut117) LICHTINGER B., O. HANKA, Secure setup of inter-provider Ethernet services based on a novel naming schema. In: NOMS 2010: 12th IEEE/IFIP Network Operations and Management Symposium. Osaka, Japan, April, 2010 MARCU P., W. HOMMEL, Requirements and concepts for an inter–organizational fault management architecture, In Proceedings of the 9–th RoEduNet International Conference, IEEE Computer Society, Sibiu (Hermannstadt), Romania, Juni, 2010. MARCU P., D. SCHMITZ, A. HANEMANN, S. TROCHA, Monitoring and Visualization of the Large Hadron Collider Optical Private Network, In Proceedings of the 9–th RoEduNet International Confer- ence, IEEE Computer Society, Sibiu (Hermannstadt), Romania, Juni, 2010 SATZGER H., Frankie im Wunderland. In: Aviso. Bayerisches Staatsministerium für Wissenschaft, For- schung und Kunst, 2010 STUEBEN H., M. ALLALEN, Extreme scaling of the BQCD benchmark, Jülich BlueGene/P Extreme Scaling Workshop March 22 - 24, 2010. (http://www.fz-juelich.de/jsc/docs/printable/ib/ib-10/ib-2010- 03.pdf) YAMPOLSKIY M., W. HOMMEL, P. MARCU, M. K. HAMM, An information model for the provisioning of network connections enabling customer–specific End–to–End QoS guarantees. In: Proceedings of the IEEE SCC 2010 International Conference on Services Computing, IEEE Computer Society, Mi- ami, USA, Juli, 2010 YAMPOLSKIY M., W. HOMMEL, B. LICHTINGER, W. FRITZ, M. K. HAMM, Multi–Domain End– to–End (E2E) Routing with multiple QoS Parameters — Considering Real World User Requirements and Service Provider Constraints. In: Proceedings of 2010 Second International Conference on Evolving In- ternet, 9–18, IARIA, Valencia, Spanien, September, 2010 YAMPOLSKIY M., W. HOMMEL, D. SCHMITZ, M. K. HAMM, Generic Function Schema for Opera- tions on Multiple Network QoS Parameters. In: Proceedings of The Second International Conferences on Advanced Service Computing SERVICE COMPUTATION 2010, IARIA, Lisabon, Portugal, November, 2010 WAGNER S., M. STEINMETZ, A. BODE, M. M. MÜLLER, High Performance Computing in Scienöce and Engineering, Garching/Munich 2009, 780 pp. Springer Berlin, Heidelberg, 2010 WEINBERG V., M. BREHM, I. CHRISTADLER, OMI4papps: Optimisation, Modelling and Implemen- tation for Highly Parallel Applications. In: High Performance Computing in Science and Engineering, Garching/Munich 2009, 51-62, Springer Berlin Heidelberg, 2010

Jahresbericht 2010 des Leibniz-Rechenzentrums 181

6 Regelwerk des LRZ Auf den in den früheren Jahren üblichen Abdruck der Dokumente wird verzichtet. Stattdessen finden Sie hier die Sammlung der URLs für die Webseiten des LRZ, auf denen diese Dokumente zu finden sind. Dies dient u. a. der höheren Aktualität, da auf den Webseiten des LRZ immer die aktuelle Fassung steht. http://www.lrz-muenchen.de/wir/regelwerk/

6.1 Satzung der Kommission für Informatik http://www.lrz-muenchen.de/wir/regelwerk/satzung/

6.2 Mitglieder der Kommission für Informatik http://www.lrz-muenchen.de/wir/komm-mitgl/

6.3 Benutzungsrichtlinien für Informationsverarbeitungssysteme http://www.lrz-muenchen.de/wir/regelwerk/benutzungsrichtlinien/

6.4 Betriebsregeln des Leibniz-Rechenzentrums http://www.lrz-muenchen.de/wir/regelwerk/betriebsregeln/

6.5 Richtlinien zum Betrieb des Münchner Wissenschaftsnetzes (MWN) http://www.lrz-muenchen.de/wir/regelwerk/netzbenutzungsrichtlinien/

6.6 Richtlinien zur Nutzung des Archiv- und Backupsystems http://www.lrz-muenchen.de/services/datenhaltung/adsm/Richtlinien/

6.7 Gebühren des Leibniz-Rechenzentrums http://www.lrz-muenchen.de/wir/regelwerk/gebuehren/

6.8 Zuordnung von Einrichtungen zu LRZ-Betreuern http://www.lrz-muenchen.de/wir/betreuer/

6.9 Betriebs- und Organisationskonzept für den Höchstleistungsrechner in Bayern (HLRB) http://www.lrz-muenchen.de/services/compute/hlrb/rules/organisationskonzept/

6.10 Nutzungs- und Betriebsordnung für den Höchstleistungsrechner in Bayern (HLRB) http://www.lrz-muenchen.de/services/compute/hlrb/rules/betriebsordnung/

6.11 Mitglieder des Lenkungsausschusses des Höchstleistungsrechners in Bayern (HLRB) http://www.lrz-muenchen.de/services/compute/hlrb/steering/

182 Regelwerk des LRZ

Jahresbericht 2010 des Leibniz-Rechenzentrums 183

7 Technische Ausstattung

7.1 Speicher

BRUTTOKAPAZITÄTEN ONLINESPEICHER (NAS+SAN)

Typ Modell Anwendung Kapazität E-Mail LRZ, interne Server, Arbeitsplatz- NAS 2x NetApp FAS 3050 46 TB Filedienste, Speicherhosting LMU, WWW NAS 1 x NetApp FAS 3050 Linux compute cluster repository 9 TB

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

NAS 1 x NetApp FAS 270c Staging / Testsystem 0,4 TB

NAS 1 x NetApp R200 Replikation (asynchrones Spiegeln) 36 TB

NAS 2 x NetApp FAS 6070 Speicher für die Wissenschaft (SFW) 117 TB

NAS 1 x NetApp FAS 6070 Replikation für den SFW und VMWare 305 TB

NAS 2 x NetApp FAS 3170 Metrocluster für VMWare 168 TB Projektspeicherplatz HLRB II 97 TB NAS 8 x NetApp FAS 3050 Replikation Projektspeicherplatz HLRB II 49 TB NAS 6 x NetApp FAS 3170 Linux-Computecluster 576 TB

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

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

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

NAS Gesamt NAS 2.084 TB

SAN 2 x SUN Flex Line 380 Cache für Archiv- und Backupsystem 49 TB

SAN 2 x SUN 6540 Cache für Archiv- und Backupsystem 61 TB

SAN 1 x STK D280 Datenbanken, AFS 14 TB

SAN 1 x IBM DS3500 Cache für Archiv- und Backupsystem 58 TB

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

SAN SGI Paralleles Filesystem des HLRB II 600 TB

SAN 6x SGI IS4500 Cache für Archiv- und Backupsystem 170 TB

SAN Gesamt SAN 1.406 TB

Gesamt NAS+SAN 3.490 TB

184 Technische Ausstattung

Die Tabelle gibt differenziert nach Speicherarchitektur einen Überblick über die Bruttokapazität der Plat- tenspeichersysteme des LRZ Ende 2010 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

Bandbibliothek Bandlaufwerke Kassetten Kapazität 10 x IBM LTO 4 IBM TS3500 Tape Library 5.000 7.500 TB 8 x IBM LTO 5 16 x IBM LTO 5 Library SUN SL8500 6.500 9.750 TB 16 x IBM LTO 5 Library SUN SL8500 26 x SUN T10K 9.300 9.300 TB

Gesamt 76 20.800 26.550 TB

7.2 Rechner und Server

7.2.1 Höchstleistungsrechner SGI Altix 4700

Jahresbericht 2010 des Leibniz-Rechenzentrums 185

Kompo- Gesam- Systemdaten nenten ter Anzahl Anzahl der Haupt- (Anzahl Haupt- der Typ der Kom- Prozessoren speicher Aufgabe und speicher Kompo- ponenten der Kompo- der Kom- Typ) (in GB) nenten nente ponente 19 Parti- 38912 19 6 Shared- Je Partition: 19 x 2 TB Höchstleistungsrechner für tionen Memory- 512 Monteci- Benutzer aus den Hochschu- Partitionen mit to Prozessor- len in Deutschland; für die Dual-Socket- kerne Nutzungsberechtigung ist Blades eine spezielle Begutachtung 13 Shared- durch den wissenschaftlichen Memory- Lenkungsausschuss notwen- Partitionen mit dig. Typ: Parallel-Rechner Single-Socket- Blades Alle Partitionen sind über das NumaLink4- Verbindungs- netzwerk eng gekoppelt.

7.2.2 Hochleistungs-Linux-Systeme Am LRZ selbst konfigurierter Linux-Cluster, der aus 838 Komponenten mit insgesamt 14.165 GB Haupt- speicher besteht, die mit Gbit, Myrinet oder 10 Gbit Ethernet vernetzt sind.

Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 837 Linux-Cluster zur Bearbeitung üblicher, auf Linux verfügbarer Anwendungspro- gramme und für Programme, die mittels MPI parallelisierbar sind. Der Cluster besteht aus den im folgenden aufgezähl- ten Komponenten 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 18 diverse 4-8 2 x 64 GB Komponente des Linux-Clusters: 8 x 2 GB Log-, Monitoring, Installations- u.a. Ser- 1 x 4 GB ver 7 x 8 GB

186 Technische Ausstattung

Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 15 diverse 2 1 x 5 GB Test-cluster 4 x 2 GB 1 x 8 GB 9 x 6 GB 1 MEGWARE 4 2 GB Komponente des Linux-Clusters: EM64T, 3600 x86_64-Interaktivrechner MHz 2 MEGWARE 8 32 GB Komponente des Linux-Clusters: Opteron, 2600 x86_64-Interaktivrechner MHz 2 INTEL 8 16 GB Komponente des Linux-Clusters: Itanium2 (Mon- IA64-Interaktivrechner tecito), 1600 MHz 9 MEGWARE 2 1 x 8 GB Attended Cluster-Housing-Knoten des Opteron, 2400 8 x 4 GB Lehrstuhls für Bauinformatik der TU- MHz München 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 8 SGI Altix XE 4 16 GB Attended Cluster-Housing-Knoten des 240 Xeon, 2333 Münchner Astro-GRID-Projektes MHz 35 MEGWARE 4 8 GB Attended Cluster-Housing-Knoten der Xeon X3230, Bayerischen Staatsbibliothek 2667 MHz 37 SUN 4 8 GB Komponente des Linux-Clusters: Opteron, 2600 LCG Tier-2 Rechen-Knoten MHz 124 MEGWARE 4 8 GB Komponente des Linux-Clusters: Xeon X3230, LCG Tier-2 Rechen-Knoten 2667 MHz 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

Jahresbericht 2010 des Leibniz-Rechenzentrums 187

Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 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 10 FMS 2 2 GB Komponente des Linux-Clusters: Opteron, 2200 LCG Tier-2 dCache-Knoten 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 6 NVIDIA Tesla 960 GPUs 16 Attended Cluster-Housing-Knoten der S1070-1/2MX16 LMU, LS Prof. Ruhl 20 SUN Opteron, 4 8 GB Komponente des Linux-Clusters: 2600 MHz Serielle x86_64-Cluster Knoten 36 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 1 SGI Altix 4700 256 1024 GB IA64-SMP-Rechner: Montecito, 1600 • 2 Prozessorkerne dediziert für MHz OS • 14 Prozessorkerne dediziert für interaktives Arbeiten • 240 Prozessorkerne dediziert für par. Jobs

188 Technische Ausstattung

Systemdaten Anzahl Anzahl der Haupt- der Typ der Kom- Prozessoren speicher Aufgabe Kompo- ponenten der Kompo- der Kom- nenten nente ponente 1 SGI Altix 512 1536 GB X86_64-MPP-Rechner ICE8200 Xeon E5540, 2533 GHz 1 SGI uv1000 256 528 GB X86_64-SMP-Rechner Xeon X7550, 2000 GHz

7.2.3 Grid-Rechner

Anzahl Hersteller Typ Anzahl Haupt- Aufgabe Prozes- speicher sor kerne 3 Sun X4100 und 2-4 2-8GB Grid Managementserver (Unicore, Monitoring X2200 M2 und Webserver)

2 Diverse Pentium III, 2-4 0,25-16GB Grid Managementserver (Monitoring) und AMD Opte- User-Interface ron 3 Sun X4150 und 2-8 4-16GB LCG Service Node X4100

7.2.4 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

Grafik- Am LRZ Mit 10 Gbit-E 5 FSC 2 8 GB Immersive 3D-Projektionstechnik (im Hoch- selbst vernetzte AMD Opteron 2400 MHZ Visualisierungs-Labor) als Rechen- leistungs- konfiguriert Opteron Syste- Cluster für eine Holobench Cluster me

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

Jahresbericht 2010 des Leibniz-Rechenzentrums 189

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

7.2.5 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner

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

ca. 18 Dell Dual QuadCore 2,8 GHz 2 8 GB Benutzerarbeitsplätze LRZ

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

190 Technische Ausstattung

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher ca. 90 Dell, Fujitsu- Intel Core i5 M 2.66 Ghz 1 256MB - 4 Laptops für Präsentationen, Notebooks für Siemens GB 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 Dual Core 3,2 GHz 1 4 GB Arbeitsplätze in Kursräumen

4 Sun SPARC Verschiedene 1 0,5-1GB Compute-Server (2 davon für allg. Nutzer, 2 davon LRZ-intern)

BVB- Server und Storage 21 Sun SPARC Verschiedene 2-32 4-92 GB Zentrales Verbundsystem, Lokalsysteme (Da- tenbanken und OPACs) 14 Sun Verschiedene 1-8 8-32 GB Firewall, Suchmaschinen-Cluster 46 FSC Verschiedene 1-8 1-8 GB Suchmaschinencluster, OPACS, weitere Web- dienste, Allegro Datenbanken, Windows und Citrix Server, Mailserver, Netzüberwachung. SUN Storage FC und SCSI 16 TB Storage für Datenbanken

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

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

Jahresbericht 2010 des Leibniz-Rechenzentrums 191

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

1 Advanced Xeon 2,80 GHz 4 2 GB Zope Unibyte 21 VMware Xeon 2,53 GHz 1-2 0,5-8 GB Moodle, Proxy, Apache, Zope

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

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

14 VMware Xeon 2,53 GHz 1-2 0,5-16 GB SQL

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

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

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

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

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

15 Avocent - 1 - Serielle Konsolen

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

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

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

1 Dell Core2 Duo 3,00 GHz 4 4 GB Leitwarte

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 18 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

5 FMS AMD Opteron 2,40 GHz 2 3-7 GB Grafik-Cluster

2 Dell Xeon bis 3,0 GHz 2-4 2-8 GB Grafik-Test

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

192 Technische Ausstattung

An- Hersteller Typ Anz. Haupt- Aufgabe zahl Proz. speicher 25 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

17 VMware Xeon 2,53 GHz 1-8 0,5-32 GB 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

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

6 Advanced Xeon 2,80 GHz 2-4 2-4 GB Installation, Monitoring Unibyte 48 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

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

2 Dell Xeon 2,67 GHz 24 24 GB VoIP

Jahresbericht 2010 des Leibniz-Rechenzentrums 193

7.3 Netzkomponenten

7.3.1 Router

Aktive Aktive Aktive Aktive Ports Ports Ports Ports Ether- 10GE 1GE FE Anzahl Hersteller/Typ Einsatz net Cisco Catalyst Backbone- 8 48 236 8 0 6509 Router Cisco Catalyst 4 LRZ-Router 71 56 1 0 6509 Anbindung 1 Cisco 7206VXR 0 2 0 0 Triesdorf Anbindung 1 Cisco 2821 0 0 2 0 Straubing Standort- 18 Cisco 1811/1812 0 0 42 0 anbindung Standort- 7 Cisco 1721 0 0 0 14 anbindung Site2Site 6 Cisco 1811/1812 0 0 13 0 VPN ISDN- 1 Cisco 801 0 0 0 2 Backup Server Load 2 F5 BigIP 8900 4 0 0 0 Balancer Server Load 3 F5 BigIP 3400 0 11 0 0 Balancer 51 Router gesamt 123 305 66 16

7.3.2 Switches

verfügbare Glasfaser- Anzahl Hersteller/Typ verfügbare TP-Ports ports 10/100/1000 10GE 100/1000 10GE 2 HP E8212zl 23 HP E5412zl 5.217 32 2.177 157 62 HP E5406zl 3 HP5308xl 259 - 6 - 175 HP E4208vl 23.381 - 627 3 44 HP E4204vl

194 Technische Ausstattung

verfügbare Glasfaser- Anzahl Hersteller/Typ verfügbare TP-Ports ports 177 HP 4108gl 21.410 - 3.232 - 111 HP 4104gl 1 HP 4000 24 - - - 5 HP E6600-24XG 240 - - 140 5 HP E6600-48G-4XG 7 HP E2910al-24G 686 - 10 5 11 HP E2910al-48G 7 HP2900-24G 1.704 73 - 40 32 HP2900-48G 22 HP E2810-24G 1.188 - 12 - 14 HP E2810-48G 13 HP3400cl-48G 618 - 6 8 4 HP 6410cl-6XG - 16 - 8 51 HP 2824 2.415 - 9 - 25 HP 2848 10 HP E2610-48 51 HP E2610-24 117 HP E2610-24pwr 5.233 - 60 - 3 HP E2610-48pwr 8 HP E2610-24/12pwr 11 HP E2615-8-PoE 109 1 51 HP E2650 60 HP E2626 2 HP E2626-pwr 4.140 - 76 - 4 HP E2600-8-PoE 2 HP6108 7 HP E2510 170 - 8 - 5 HP 2524 125 - 1 - 1 Cisco Nexus7000 - - - 256 1.126 Switches gesamt 66.919 121 6.225 617

7.3.3 WLAN-Komponenten

Anzahl Hersteller/Typ Verwendung Standards Radios 1077 HP MSM 310 Access Point 802.11b/g 1

Jahresbericht 2010 des Leibniz-Rechenzentrums 195

Anzahl Hersteller/Typ Verwendung Standards Radios 14 HP MSM 310 Gebäudeanbindung 802.11a/g 1 39 HP MSM 320 Access Point 802.11b/g 2 296 HP MSM 422 Access Point 802.11b/g/n 2 12 HP MSM 422 Gebäudeanbindung 802.11n 1 1 HP MSC3200 Controller 6 HP M111 Wireless Client Bridge 802.11b/g 1 1445 WLAN gesamt

7.3.4 Netz-Server

Anzahl Hersteller/Typ Verwendung Betriebssystem Prozessoren Hauptspeicher 4 Cisco ASA5540 VPN-Server proprietär 1 Cisco 3030E VPN-Server proprietär Modem/ISDN- 2 Cisco AS5350XM Server, SIP- proprietär Gateway 1 Cisco ASA5580 Firewall proprietär 2 12 GB 1 Meinberg Lantime NTP-Server Linux 1 32 MB 4 Oxygen X2201 DNS-Server Linux 4 4 GB 1 Sun Fire X2100 M2 DHCP Linux 2 2 GB 2 Oxygen X1101 DHCP Linux 2 1 GB 2 Sun Fire X4100 Radius Linux 4 2 GB 1 Sun Fire X4100 VoIP Linux 2 4 GB 3 Sun Galaxy VoIP Linux 2 4 GB 2 Oxygen X3200 Natomat Linux 4 4 GB 1 Sun Fire X4100 Natomat Linux 4 16 GB 3 Sun Fire X4150 Secomat Linux 8 64 GB 1 Dell PE2550 Accounting Linux 1 2 GB 1 Dell PE2550 IDS Linux 1 512 MB 1 Oxygen X3200 Monitoring Linux 4 4 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 Server gesamt 52

ퟑퟕ