2014 - LRZ

Transcription

2014 - LRZ

Jahresbericht 2014
Juni 2015
LRZ-Bericht 2015-01
Jahresbericht 2014 des Leibniz-Rechenzentrums
Inhaltsverzeichnis
Abbildungsverzeichnis .................................................................................................................... vii
Tabellenverzeichnis .......................................................................................................................... x
Vorwort
1
........................................................................................................................................1
Highlights - Die wichtigsten Ereignisse am LRZ 2014 ................................................................2
1.1
Einführung des neuen LRZ-Logos und Corporate Designs ...................................................2
1.2
Eduroam im WLAN der SWM .................................................................................................2
1.3
Anbindung der Staatlichen Museen und Archive an das MWN .............................................3
1.4
SuperMUC Status and Results Workshop, User Forum und Berichtsband ...........................3
1.5
PRACE ISC Award: 1,4 Petaflops mit SeisSol auf SuperMUC ..............................................4
1.6
Science Veröffentlichung über genetische Algorithmen .........................................................4
1.7
Zweiter Extreme Scaling Workshop .......................................................................................4
1.8
Vorbereitungen für die Phase 2 des SuperMUC ....................................................................4
1.9
Einsparungen beim Energieverbrauch von HPC Systemen ..................................................4
1.10 Überwachungssoftware Persyst .............................................................................................4
1.11 Power Data Aggregation Monitor (PowerDAM)......................................................................5
1.12 Webfrontend für Remote Visualisierung .................................................................................5
1.13 Erneuerung der VMware- und Linux-Cluster-Infrastruktur .....................................................5
1.14 Erhöhung der Redundanz im Münchner Wissenschaftsnetz .................................................5
1.15 Starkes Wachstum bei Exchange am LRZ .............................................................................5
1.16 Desktop-Management TUM-PC .............................................................................................6
1.17 Security Incident and Event Management System ................................................................6
1.18 Die wichtigsten öffentlichen Auftritte des LRZ ........................................................................7
2
Forschung und Projekte ................................................................................................................9
2.1
Forschungskoordination und Projektmanagement .................................................................9
2.2
Energieeffizientes Rechenzentrum ........................................................................................9
2.2.1
Einsparungen beim Energieverbrauch von HPC Systemen......................................9
2.3
Energieseminar ......................................................................................................................9
2.4
Projekte, an denen sich das LRZ beteiligt ............................................................................10
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
Automatic Online Tuning (AutoTune) ......................................................................10
Dynamical Exascale Entry Platform / Extended Reach (DEEP/-ER) ......................12
European Exascale Software Initiative 2 (EESI2) ...................................................13
European Grid Infrastructure (EGI-InSPIRE) ..........................................................15
Ein flexibles Framework zur Energie- und Performanceanalyse
hochparalleler Applikationen im Rechenzentrum (FEPA) .......................................16
2.4.6 GÉANT GN3plus .....................................................................................................17
2.4.7 Intel® Parallel Computing Center (IPCC) ................................................................20
2.4.8 Software-Initiative des KONWIHR ...........................................................................22
2.4.9 Mont-Blanc & Mont-Blanc 2 .....................................................................................24
2.4.10 Mr. SymBioMath ......................................................................................................25
2.4.11 PRACE Second Implementation Phase Project (PRACE-2IP) ...............................26
2.4.12 PRACE Third Implementation Phase Project (PRACE-3IP) ...................................28
i
ii
Inhaltsverzeichnis
2.4.13 Safe And Secure European Routing (SASER) ....................................................... 30
2.4.14 Simulation und Optimierung des Energiekreislaufs von RechenzentrumsKlimatisierungsnetzen unter Berücksichtigung von SupercomputerBetriebsszenarien (SIMOPEK) ............................................................................... 33
2.4.15 Virtuelles Alpen-Observatorium II (VAO-II) ............................................................. 35
2.4.16 Virtual Earthquake and Seismology Research Community in Europe eScience Environment (VERCE) .............................................................................. 36
2.4.17 Webbasiertes Customer Network Management (WebCNM) .................................. 38
2.4.18 Standardisierungsaktivitäten im Bereich der parallelen Programmierung.............. 39
2.5
Mitarbeit in Initiativen zur Förderung und Weiterentwicklung von HPC-Technologien in Europa
39
2.5.1
2.5.2
3
Darstellung des LRZ in der Öffentlichkeit ................................................................................. 40
3.1
Allgemeine Öffentlichkeit und Medien - PR ......................................................................... 40
3.2
Hochleistungsrechnen ......................................................................................................... 41
3.2.1
3.2.2
3.2.3
3.3
Einführung von ISO/IEC 20000 ........................................................................................... 45
4.1.1
4.1.2
4.1.3
4.1.4
4.2
Incident Management ............................................................................................. 45
Change- und Configuration Management .............................................................. 45
Weitere ITSM-Prozesse .......................................................................................... 45
Sonstige Aktivitäten ................................................................................................ 45
Service-Management-Plattform Action Request System .................................................... 46
IT-Sicherheit ................................................................................................................................. 47
5.1
Sicherheitsmanagement ...................................................................................................... 47
5.2
Antivirus ............................................................................................................................... 47
5.3
WSUS .................................................................................................................................. 47
5.4
Virtuelle Firewalls ................................................................................................................. 47
5.5
Technische Aspekte des Sicherheitsmanagements ............................................................ 49
5.5.1
5.5.2
5.5.3
5.5.4
6
Vorträge .................................................................................................................. 42
Veranstaltungen ...................................................................................................... 42
Booklet .................................................................................................................... 44
IT-Service Management ............................................................................................................... 45
4.1
5
Supercomputing Konferenzen ................................................................................ 41
SuperMUC Status and Results Workshop, User Forum und Berichtsband .......... 41
Ergebnisse auf GCS Webseiten ............................................................................. 42
Zentrum für Virtuelle Realität und Visualisierung (V2C) ...................................................... 42
3.3.1
3.3.2
3.3.3
4
ETP4HPC ............................................................................................................... 39
PROSPECT e.V. ..................................................................................................... 39
Secomat .................................................................................................................. 49
Security Information & Event Management ............................................................ 50
Sicherheits- und Netzmanagement: Nyx ................................................................ 50
Self-Service Portal; Sperr- und Entsperrmechanismen .......................................... 51
IT-Basisdienste ............................................................................................................................ 52
6.1
E-Mail ................................................................................................................................... 52
6.1.1
6.1.2
6.1.3
6.1.4
6.2
Migration der lokalen Mailserver im MWN .............................................................. 52
Inhaltsbasierte „Prequeue-Filterung“ von Spam- und Virenmails ........................... 52
Verschlüsselte Übertragung von E-Mails................................................................ 52
Statistiken zur Mailnutzung ..................................................................................... 53
Exchange ............................................................................................................................. 55
6.2.1
6.2.2
6.2.3
6.3
Webhosting ...........................................................................................................................56
6.3.1
6.3.2
6.4
8
Arbeitsgruppe Bibliotheksdienste ............................................................................68
System- und Softwaremanagement ........................................................................68
Projekt Rosetta (Langzeitarchivierung) ...................................................................68
Bibliotheksverbund Bayern (BVB) ...........................................................................68
Münchner Digitalisierungszentrum (MDZ) ...............................................................69
Virtuelle Realität und Visualisierung ..........................................................................................72
7.1
Kooperationen ......................................................................................................................72
7.2
Forschung und Lehre ...........................................................................................................72
IT-Server-Infrastruktur ..................................................................................................................74
8.1
Linux-Server .........................................................................................................................74
8.1.1
8.1.2
8.1.3
8.1.4
8.2
9
Benutzerverwaltung für LRZ-Dienste ......................................................................59
CampusLMU und TUMonline ..................................................................................65
MWN Active Directory..............................................................................................65
DFN-AAI/Shibboleth ................................................................................................66
Bibliotheksdienste .................................................................................................................68
6.6.1
6.6.2
6.6.3
6.6.4
6.6.5
7
Rechnerpools ...........................................................................................................58
TUM-PC ...................................................................................................................58
MWN-MAC ...............................................................................................................59
Benutzerverwaltung und Verzeichnisdienste .......................................................................59
6.5.1
6.5.2
6.5.3
6.5.4
6.6
Performance-Tuning in der neuen Webhosting-Betriebsumgebung .......................56
Verlagerung und Upgrade TUM-Typo3-Projekt .......................................................57
Desktop-Management ..........................................................................................................57
6.4.1
6.4.2
6.4.3
6.5
Migration auf Exchange 2013 ..................................................................................55
Exchange für die Hochschule München ..................................................................55
Nutzung des Exchange-Dienstes ............................................................................55
Virtuelle Server ........................................................................................................74
Analyse von Log- und Diagnosedaten.....................................................................74
Monitoring ................................................................................................................74
Managed Hosting für hochschulstart.de ..................................................................74
Windows ...............................................................................................................................75
Hochleistungssysteme und SuperMUC .....................................................................................76
9.1
Höchstleistungsrechner SuperMUC .....................................................................................76
9.1.1
9.1.2
9.1.3
9.1.4
9.1.5
9.1.6
9.1.7
9.1.8
9.2
Linux-Cluster.........................................................................................................................84
9.2.1
9.2.2
9.2.3
9.3
SuperMUC Phase 2 .................................................................................................76
Das neue Intel Xeon Phi System SuperMIC............................................................77
Das neue Remote-Visualisierungs-System für SuperMUC Benutzer .....................78
Betrieb des Höchstleistungsrechners SuperMUC ...................................................79
Auslastung ...............................................................................................................79
Rechenzeit nach Fachgebieten ...............................................................................81
Jobgröße ..................................................................................................................82
Datentransfer ...........................................................................................................83
Betrieb......................................................................................................................84
Nutzung des Linux-Clusters ....................................................................................84
Antrag zur Ersetzung veralteter Komponenten des Linux-Clusters ........................86
Applikations- und Benutzerunterstützung im Bereich HPC ..................................................87
9.3.1
9.3.2
9.3.3
Supportanfragen ......................................................................................................87
Benutzerverwaltung für die Hochleistungssysteme.................................................88
Software für HPC Systeme ......................................................................................88
iii
iv
Inhaltsverzeichnis
9.3.4
9.4
Application Labs .................................................................................................................. 88
9.4.1
9.4.2
9.4.3
9.4.4
10
Kurse und Ausbildung ............................................................................................. 88
AstroLab (πCS Astro) ............................................................................................. 88
BioLab (πCS Bio) .................................................................................................... 89
GeoLab (πCS Geo) ................................................................................................ 89
Energie und Umwelt................................................................................................ 90
Datenhaltung ................................................................................................................................ 91
10.1 Überblick Datenhaltung ....................................................................................................... 91
10.2 Archiv- und Backupsystem .................................................................................................. 91
10.2.1
10.2.2
10.2.3
10.2.4
Konfiguration ........................................................................................................... 91
Schwerpunkte in den Aktivitäten ............................................................................. 96
Statistik ................................................................................................................... 96
Plattform für digitale Langzeitarchivierung.............................................................. 98
10.3 Datenbanken ..................................................................................................................... 101
10.4 Onlinespeicher ................................................................................................................... 101
10.4.1
10.4.2
10.4.3
10.4.4
Konfiguration und Entwicklung im Überblick ........................................................ 101
Hochverfügbarer Speicher für virtuelle Server ..................................................... 103
MWN Storage Cloud ............................................................................................. 104
Sync+Share Lösung für die Münchner Universitäten ........................................... 105
10.5 Daten- und Archivräume .................................................................................................... 105
11
Münchner Wissenschaftsnetz – Internetzugang .................................................................... 107
11.1 Struktur und Betrieb des Münchner Wissenschaftsnetzes (MWN) ................................... 107
11.1.1
11.1.2
11.1.3
11.1.4
Struktur des Backbone Netzes ............................................................................. 112
Planung von WDM-Systemen im MWN-Backbone .............................................. 113
Struktur der Gebäudenetze im MWN.................................................................... 114
Struktur des Rechenzentrumsnetzes (LRZ-Netz) ................................................. 115
11.2 Anschluss ans MWN und wesentliche Änderungen im Netz............................................. 117
11.2.1 Wesentliche Netzänderungen im Jahr 2014 ......................................................... 117
11.2.2 Netzausbau (Verkabelung); Netzinvestitionsprogramm ....................................... 118
11.2.3 Redundante LWL-Verkabelung und zweiter zentraler Netzknoten auf dem
Campus Garching ................................................................................................. 119
11.2.4 Anbindung Studentenwohnheime ......................................................................... 120
11.3 DNS und Sicherheit im DNS .............................................................................................. 123
11.3.1 DNS-Amplification-Attacks und offene Resolver .................................................. 125
11.3.2 DNSSEC ............................................................................................................... 126
11.4 DHCP ................................................................................................................................. 126
11.5 Radius ................................................................................................................................ 127
11.6 Switch-Infrastruktur / Switch-Erneuerung .......................................................................... 128
11.7 Telefonie ............................................................................................................................ 128
11.7.1
11.7.2
11.7.3
11.7.4
VoIP-Anlage und Betrieb ...................................................................................... 128
Zugang über UMTS .............................................................................................. 129
Verbesserung der Mobilfunkversorgung in den LRZ-Gebäuden ......................... 129
Ausschreibung BayKOM ....................................................................................... 129
11.8 Unterstützung von Infrastrukturdiensten ............................................................................ 129
11.8.1
11.8.2
11.8.3
11.8.4
Server Load Balancer (SLB) ................................................................................. 129
IPv6 ....................................................................................................................... 130
Wellenlängenmultiplexer ....................................................................................... 131
NeSSI .................................................................................................................... 132
11.9 Netzmanagement und –monitoring ....................................................................................133
11.9.1
11.9.2
11.9.3
11.9.4
11.9.5
11.9.6
Netzmanagement ..................................................................................................133
Netzdokumentation ................................................................................................135
MWN-WLAN-Visualisierung mit OpenStreetMap für Endbenutzer .......................135
Inhaltliche Aktualisierung der Netzdokumentation ................................................136
Überwachung der Dienstqualität ...........................................................................136
Reporting für Netzverantwortliche .........................................................................137
11.10 Internetzugang und LAN.....................................................................................................137
11.11 WLAN und Eduroam ...........................................................................................................140
11.11.1 Eduroam ................................................................................................................142
11.11.2 Vorkonfigurierte Profile für eduroam (CAT) ...........................................................143
11.11.3 Eduroam off Campus .............................................................................................144
11.11.4 Gastkennungen .....................................................................................................145
11.11.5 Unterstützung von Veranstaltungen ......................................................................145
11.12 VPN 145
11.12.1 Technik ..................................................................................................................146
11.12.2 VPN-Software ........................................................................................................146
11.12.3 Telearbeitsplätze von LRZ-Mitarbeitern ................................................................146
11.12.4 Entwicklung des Datenverkehrs über die VPN-Server ..........................................146
12
Kurse, Ausbildung und Benutzerbetreuung ............................................................................149
12.1 Kurse und Veranstaltungen ................................................................................................149
12.1.1 Kursübersicht, Statistik 2014 .................................................................................149
13
Software-Bezug und Lizenzen ...................................................................................................154
13.1 Microsoft .............................................................................................................................154
13.1.1 Mietlizenzen für LRZ und Akademie......................................................................154
13.1.2 Zugang der Universitätskliniken zum Bundesvertrag ............................................154
13.1.3 Plausibilisierungen oder: „Damokles-Schwert der Software-Audits“ .....................154
13.2 Adobe .................................................................................................................................154
13.2.1 CLP ........................................................................................................................154
13.2.2 ETLA Desktop ........................................................................................................155
13.3 Ansys ..................................................................................................................................155
13.4 SPSS ..................................................................................................................................155
13.5 VMware...............................................................................................................................155
13.6 Software Asset Management .............................................................................................155
13.7 Verlängerung und Ausbau bestehender Verträge ..............................................................155
13.8 Tagesgeschäft ....................................................................................................................156
13.8.1 Abläufe und Änderungen bei der Versorgung der Kunden des LRZ .....................156
13.8.2 Betrieb von Lizenzservern für Kunden des LRZ ....................................................157
14
Gebäude und Infrastruktur ........................................................................................................158
14.1 Gebäudemanagement ........................................................................................................158
14.2 Energieeffizienz ..................................................................................................................158
15
Personal ....................................................................................................................................160
v
vi
16
Inhaltsverzeichnis
Zahlen und Fakten ..................................................................................................................... 161
16.1 Personal ............................................................................................................................. 161
16.2 E-Mail und Exchange ......................................................................................................... 162
16.3 Poster und Schriften .......................................................................................................... 162
16.4 Benutzerverwaltung und Shibboleth .................................................................................. 162
16.5 Höchstleistungsrechner ..................................................................................................... 163
16.6 Hochleistungs-Linux-System ............................................................................................. 164
16.7 Hochleistungs-Graphik-System ......................................................................................... 166
16.8 Datenspeicher .................................................................................................................... 167
16.9 Das Münchner Wissenschaftsnetz (MWN) ........................................................................ 169
16.10 Netzkomponenten im MWN ............................................................................................... 170
16.10.1 Router ................................................................................................................... 170
16.10.2 Switches ................................................................................................................ 171
16.10.3 WLAN-Komponenten ............................................................................................ 172
16.10.4 Netz-Server ........................................................................................................... 173
vii
Abbildungsverzeichnis
Abbildung 1: Das neue Logo des LRZ ..........................................................................................................2
Abbildung 2: eduroam-WLAN-Standorte am Marienplatz, die von den Stadtwerken München
betrieben werden .......................................................................................................................3
Abbildung 3: Anstieg der Exchange-Nutzung im MWN.................................................................................6
Abbildung 4: Anstieg der Anzahl verwalteter TUM-PCs in 2014 ...................................................................6
Abbildung 5: Stand des LRZ bei den Münchner Wissenschaftstagen ..........................................................7
Abbildung 6: Präsentation beim Akademientag im November 2014 .............................................................8
Abbildung 7: Open Lab Day des V2C am 16. Dezember 2014.....................................................................8
Abbildung 8: GÉANT-TrustBroker-Workflow nach der DAME-Protokollspezifikation ................................ 17
Abbildung 9: SP-side account linking with ORCID ..................................................................................... 18
Abbildung 10: Stand des LRZ bei den Münchner Wissenschaftstagen ..................................................... 40
Abbildung 11: Einband des Berichtsbandes 2014 ..................................................................................... 41
Abbildung 12: Webseiten des Gauß-Zentrums mit Ergebnissen von Projekten am SuperMUC ............... 42
Abbildung 13: Studierende präsentieren ihre Projekte am Open Lab Day ................................................ 43
Abbildung 14: Präsentation einer Gletschervisualisierung am Akademientag in der BAdW ..................... 43
Abbildung 15: Entwicklung der virtuellen Firewalls seit 2007..................................................................... 48
Abbildung 16: Web-Schnittstelle Adaptive Security Device Manager (ASDM) .......................................... 48
Abbildung 17: secomat1 ............................................................................................................................. 49
Abbildung 21: Entwicklung der Exchange-Nutzung seit 2011.................................................................... 56
Abbildung 22: Webserver-Antwortzeit [ms] in alter (KW37) und neuer (KW39) Betriebsumgebung ......... 57
Abbildung 23: Entwicklung des TUM-PCs in 2014 ..................................................................................... 59
Abbildung 24: Serverlandschaft und Einbindung des LRZ-SIM-Systems .................................................. 64
Abbildung 25: Computerkonten im MWN-ADS in 2014 ............................................................................. 66
Abbildung 26: Bavarikon 2 - Produktion. Eines von drei Netzen................................................................ 70
Abbildung 27: Dreigliedrige Netzsegmentierung für MDZ-Dienste ............................................................ 71
Abbildung 28: Das V2C mit seinen einzelnen Komponenten..................................................................... 72
Abbildung 29: Virtuelle Serverinstanzen am LRZ ...................................................................................... 74
Abbildung 30: Blick auf das neu installierte SuperMUC Phase 2-System (Foto: Andreas Heddergott) .... 77
Abbildung 31: Racks des SuperMIC .......................................................................................................... 77
Abbildung 32: Netzwerk-Topologie des Intel Xeon Phi Systems ............................................................... 78
Abbildung 33: Rechenzeitabgabe (in Core-Stunden). Bis 3. Quartal 2012 nur Migrationssystem
(Fat-Nodes), ab 4. Quartal 2013 Thin und Fat-Nodes ............................................................ 80
Abbildung 34: Prozentuale Auslastung (Verhältnis der tatsächlichen zur maximal möglichen
Rechenzeitabgabe) ................................................................................................................. 80
Abbildung 35: Verteilung der Rechenzeit nach Fachgebieten ................................................................... 81
Abbildung 36: Zeitliche Entwicklung der Nutzung von SuperMUC durch Fachgebiete ............................. 82
Abbildung 37: Zeitliche Entwicklung SuperMUC-Nutzung in Abhängigkeit von der Jobgröße .................. 83
viii
Inhaltsverzeichnis
Abbildung 38: Ca. 460 TByte wurden 2014 per GridFTP von und zum SuperMUC übertragen ................ 83
Abbildung 39: Kumulativer Anteil von Jobs in Abhängigkeit von der Wartezeit ......................................... 86
Abbildung 40: Entwicklung der Anzahl von Supportanfragen im Bereich HPC.......................................... 87
Abbildung 41: Überblick Archiv- und Backupsysteme ................................................................................ 92
Abbildung 42: Hochleistungs-Archiv- und Backupsystem Ende 2014 ....................................................... 93
Abbildung 43: LTO-Archiv- und Backupsystem Ende 2014 ....................................................................... 94
Abbildung 44: Desaster Recovery-Archiv- und Backupsystem Ende 2014 ............................................... 95
Abbildung 45: Datenverkehr (TB pro Monat) .............................................................................................. 97
Abbildung 46: Datenumfang (TB pro Monat) .............................................................................................. 97
Abbildung 47: Speicherbelegung seit 1995 ................................................................................................ 98
Abbildung 48: Objektanzahl im LRZ-Archiv (Zweitkopie nicht berücksichtigt) ........................................... 99
Abbildung 49: Datenvolumen im LRZ-Archiv (Zweitkopie nicht berücksichtigt) ......................................... 99
Abbildung 50: Workflow im Google Projekt .............................................................................................. 100
Abbildung 51: Archivierte Daten in TByte ................................................................................................. 101
Abbildung 52: Links: Entwicklung Datenvolumen und Anzahl Festplatten Rechts: Entwicklung der
Anzahl an Filerköpfen ........................................................................................................... 102
Abbildung 53: Primärsysteme, Replikation und Backup........................................................................... 102
Abbildung 54: Hochverfügbares NAS-System für VMware ...................................................................... 103
Abbildung 55: Durchschnittliche Anzahl simultan zugreifender Kennungen ............................................ 104
Abbildung 56: Nutzung der MWN Storage Cloud für TUM Projekte ........................................................ 104
Abbildung 57: Daten- und Archivraum DAR0 ........................................................................................... 105
Abbildung 58: Brandabschnitte im Rechnerwürfel ................................................................................... 106
Abbildung 59: Räumliche Ausdehnung des Münchner Wissenschaftsnetzes (nicht maßstabsgerecht) . 108
Abbildung 60: MWN Unterbezirke und Ausdehnung ................................................................................ 109
Abbildung 61: Standorte und Verbindungen im MWN (Teil 1) ................................................................. 110
Abbildung 62: Standorte und Verbindungen im MWN (Teil 2) ................................................................. 111
Abbildung 63: Struktur des Kernnetzes .................................................................................................... 112
Abbildung 64: Grundlegende Struktur der DWDM-Infrastruktur zwischen Martinsried und Garching ..... 114
Abbildung 65: Entwicklung bei der Anzahl der Switchports ..................................................................... 115
Abbildung 66: Struktur des LRZ-Netzes ................................................................................................... 116
Abbildung 67: Statistik für alle DNS-Server (Autoritativ) .......................................................................... 124
Abbildung 68: Statistik für alle DNS-Resolver .......................................................................................... 124
Abbildung 69: Funktionsweise der DNS Amplification Attack .................................................................. 126
Abbildung 70: DHCP-Infrastrkutur auf den DNS-Servern ........................................................................ 127
Abbildung 71: RADIUS-Struktur im MWN ................................................................................................ 128
Abbildung 72: Durchsatz innerhalb von 7 Tagen am SLB 1..................................................................... 130
Abbildung 73: Struktur des Querverbindungsnetzes ................................................................................ 132
Abbildung 74: Topologie des Münchner Wissenschaftsnetzes Ende 2014 ............................................. 134
Abbildung 75: Eduroam-WLAN-Standorte der Stadtwerke München ...................................................... 136
Abbildung 76: Device-Report mit Interface-Alias ...................................................................................... 137
Abbildung 77: Entwicklung der Nutzung des WiN-Anschlusses des MWN seit 2004 .............................. 138
ix
Abbildung 78: Anbindung des MWN ans Internet .................................................................................... 139
Abbildung 79: Anzahl der jährlich installierten Accesspoints ................................................................... 140
Abbildung 80: Anzahl aktiver WLAN-Verbindungen am 5.11.2014 (5-Minuten-Mittel) ............................ 141
Abbildung 81: Entwicklung der Belegung über das Jahr 2014 (Tagesmittel) .......................................... 141
Abbildung 82: Nutzung des WLAN aufgeteilt nach SSIDs ....................................................................... 143
Abbildung 83: Eduroam Nutzung durch MWN-Nutzer und Gäste ............................................................ 143
Abbildung 84: Dr. Dietmar Unger, Leiter IT bei den SWM und Prof. Dr. Helmut Reiser, LRZ,
nehmen das eduroam im M-WLAN in Betrieb ...................................................................... 144
Abbildung 85: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November ............. 147
Abbildung 86: Anzahl der maximal gleichzeitig an den VPN-Servern angemeldeten Nutzer .................. 147
Abbildung 87: Monatliches Datenvolumen der VPN-Server in Gigabyte im Jahr 2014 ........................... 148
Abbildung 88: Wasseranschlüsse für die Racks des SuperMUC Phase 2 .............................................. 159
Abbildung 89: Entwicklung des Dienstreiseaufkommens 2000-2014 ...................................................... 161
x
Inhaltsverzeichnis
Tabellenverzeichnis
Tabelle 1: Durchschnittliche eingehende und ausgehende Datenübertragungsrate der letzten
12 Monate ............................................................................................................................... 49
Tabelle 2: Angenommene und abgewiesene E-Mails ................................................................................ 53
Tabelle 3: Nutzung des Relaydienstes ....................................................................................................... 53
Tabelle 4: Nutzung des Mailhostings .......................................................................................................... 54
Tabelle 5: Nutzung der POP/IMAP-Server ................................................................................................. 54
Tabelle 6: Nutzung des Weiterleitungs-Service ......................................................................................... 55
Tabelle 7: Nutzung von E-Mail-Verteilerlisten ............................................................................................ 55
Tabelle 8: Nutzung des Exchange-Dienstes in 2014 ................................................................................. 56
Tabelle 9: Clients im MWN-ADS ................................................................................................................ 58
Tabelle 10: Vergabe von Kennungen für LRZ-Plattformen ........................................................................ 60
Tabelle 11: Vergabe von Kennungen an Studierende ............................................................................... 61
Tabelle 12: vom Team Bibliotheksdienste verwaltete Systeme ................................................................. 68
Tabelle 13: SuperMUC-Installationsphasen ............................................................................................... 76
Tabelle 14: Verteilung der Rechenzeit nach Fachgebiet............................................................................ 81
Tabelle 15: Anzahl Nutzer und Projekte ..................................................................................................... 84
Tabelle 16: Auslastung und Rechenzeitabgabe in den Jahren 2013 und 2014 ......................................... 84
Tabelle 17: Verteilung der Rechenzeit nach Institutionen in den Jahren 2013 und 2014 .......................... 85
Tabelle 18: Statistik für 2014 ...................................................................................................................... 96
Tabelle 19: Anzahl der im MWN eingesetzten Switches .......................................................................... 115
Tabelle 20: Wesentliche Netzänderungen 2014 ...................................................................................... 117
Tabelle 21: Die Ende 2014 an das MWN angeschlossenen Wohnheime ................................................ 120
Tabelle 22: Übersicht über die wichtigsten Domains im MWN................................................................. 125
Tabelle 23: Nutzung der Server Load Balancer (SLB) ............................................................................. 130
Tabelle 24: Anzahl der IPv6-Endgeräte 2010 - 2014 ............................................................................... 131
Tabelle 25: WDM-Verbindungen .............................................................................................................. 131
Tabelle 26: Prozentuale Verteilung des Datenverkehrs am WiN Zugang ................................................ 139
Tabelle 27: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November.................. 147
Tabelle 28: Kurse zu PC-Software 2014 .................................................................................................. 149
Tabelle 29: Kurse zum Hochleistungsrechnen 2014 ................................................................................ 150
Tabelle 30: Führungen durch das LRZ und Vorführungen am V2C ......................................................... 150
Tabelle 31: Weitere Veranstaltungen in den Räumen des LRZ ............................................................... 150
Tabelle 32: Die umsatzstärksten Softwarepakete .................................................................................... 156
Tabelle 33: Tabellarische Personal-Übersicht .......................................................................................... 161
Tabelle 34: E-Mail und Exchange ............................................................................................................. 162
Tabelle 35: Poster und Schriften .............................................................................................................. 162
Tabelle 36: Benutzerverwaltung und Shibboleth ...................................................................................... 162
Tabelle 37: Höchstleistungsrechner SuperMUC ...................................................................................... 163
Tabelle 38: Hochleistungs-Linux-Systeme (ohne SuperMUC) ................................................................. 164
Tabelle 39: Hochleistungs-Graphik-System ............................................................................................. 166
xi
Tabelle 40: Bruttokapazitäten Online-Speicher (NAS + SAN) ................................................................. 167
Tabelle 41: Kapazitäten der Nearline-Speicher........................................................................................ 168
Tabelle 42: Das MWN in Zahlen .............................................................................................................. 169
Tabelle 43: Netzkomponenten im MWN: Router ...................................................................................... 170
Tabelle 44: Netzkomponenten im MWN: Switches .................................................................................. 171
Tabelle 45: Netzkomponenten im MWN: WLAN-Komponenten .............................................................. 172
Tabelle 46: Netzkomponenten: Server ..................................................................................................... 173
xii
Inhaltsverzeichnis
1
Vorwort
2014 war für das Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften ein Jahr der
Neuerungen und der Konsolidierung zugleich. Mit den Staatlichen Museen und Archiven wurden neue
Kunden im Münchner Wissenschaftsnetz gewonnen, andererseits wurden viele existierende Dienste weiter
ausgebaut und effektiviert.
Spektakuläre Ergebnisse konnten im dritten Betriebsjahr des SuperMUC erzielt werden: Die Berechnung
des Stammbaums des Lebens der Käfer schaffte es auf das Titelblatt des renommierten Journals „Science“
im November, für die Erdmantelsimulation SeisSol gab es Preise (PRACE Award 2014, Georg Michael
Memorial Award, Gordon Bell Finalist), und mehr als zehn unterschiedliche Anwendungen konnten die volle
Parallelität des Rechners mit ca. 150.000 Rechenkernen nutzen! Die wichtigsten Ereignisse des Jahres
finden Sie in Kapitel 1 zusammengefasst.
Das LRZ partizipiert weiter an der rasanten Entwicklung der IT-Technik und treibt diese selbst in zahlreichen Eigenentwicklungen voran. Besonders zu nennen sind hier alle Anstrengungen, die gesamte Rechnerinfrastruktur extrem energieeffizient zu betreiben, wobei modernste Kühlungsinfrastruktur und Rechnertechnik mit neu entwickelten Methoden und Werkzeugen kombiniert werden.
Alle Anstrengungen des LRZ sind nur möglich durch den hochmotivierten Einsatz aller Mitarbeiterinnen
und Mitarbeiter des LRZ, denen ich für ihr Engagement ausdrücklich danke. Belohnt werden wir alle durch
das ungebrochene Publikumsinteresse an der Arbeit des LRZ, von der Presse bis hin zu dem stets überfüllten „Tag der offenen Tür“.
Auch international ist das LRZ anerkannt, das liegt nicht zuletzt an der großzügigen finanziellen Förderung
der Arbeit des LRZ durch alle Förderer, speziell durch die Bayerische Staatsregierung und das Bayerische
Staatsministerium für Bildung und Kultus, Wissenschaft und Kunst, dem wir zu großem Dank verpflichtet
sind.
Mein besonderer Dank gilt unserer Mutterorganisation, der Bayerischen Akademie der Wissenschaften,
den Mitgliedern der Kommission für Informatik und des Lenkungsausschusses, die das LRZ stets fachkundig gestützt haben. Persönlich danke ich vor allem den Mitgliedern des Direktoriums, den Kollegen HansJoachim Bungartz, Heinz-Gerd Hegering und Dieter Kranzlmüller sowie meinem Stellvertreter Victor Apostolescu.
Die wichtigsten Partner des LRZ sind seine „Kunden in der Wissenschaft“, mit denen uns ein vertrauensvolles Verhältnis verbindet.
Ich danke für die konstruktive Zusammenarbeit in 2014 und freue mich auf neue Vorhaben in 2015.
Univ-Prof. Dr. Arndt Bode Vorsitzender des Direktoriums
des Leibniz-Rechenzentrums
2
Highlights - Die wichtigsten Ereignisse am LRZ 2014
1 Highlights - Die wichtigsten Ereignisse am LRZ 2014
1.1 Einführung des neuen LRZ-Logos und Corporate Designs
Am Beginn des neuen Jahres führte das LRZ sein neues Logo und Corporate Design ein, das im Laufe
des Jahres überall das bisherige Logo ersetzte und dem LRZ nun durchgängig vom Briefkopf bis zur Internet-Präsenz ein zeitgemäßes Image verleiht.
Abbildung 1: Das neue Logo des LRZ
1.2 Eduroam im WLAN der SWM
Die Stadt München betreibt seit 2013 in Kooperation mit den Stadtwerken München ein offenes City-WLAN
(M-WLAN). Anfang 2014 wurde in einer engen Kooperation zwischen den Stadtwerken, dem LRZ und dem
DFN Verein eduroam auf den städtischen Access Points freigeschaltet und in Betrieb genommen. Die Stadt
München und ihre Stadtwerke München (SWM) unterstützen damit die Initiative „eduroam off campus“.
Innerhalb des eduroam-Netzes authentisieren sich die Nutzer mit der Kennung ihrer heimatlichen Einrichtung. Das heißt in allen Organisationen, überall in Europa und dem Rest der Welt, die eduroam unterstützen, ist der Zugang absolut identisch. Für einheimische und auswärtige Wissenschaftler und Studierende
ist die Nutzung denkbar einfach: Einmal im heimischen Netz eingerichtet wählt sich das eigene Gerät,
Laptop, Tablet-PC, Smartphone, automatisch im auswärtigen Netz ein, sobald ihm irgendwo der Zugang
zum eduroam-Netz angeboten wird.
Mit der Unterstüzung von „eduroam off campus“ möchte die Stadt München die Studierenden und Wissenschaftler unterstützen und die Campus-Bereiche der Universitäten und Hochschulen in die Innenstadt hinein ausdehnen. Gestartet wurde mit den Access Points am Marienplatz, dem Odeonsplatz, dem Sendlinger
Tor sowie dem Stachus. Mitte des Jahres wurden über diese Access Points bereits mehr als 50.000 eduroam Nutzer in zwei Monaten registriert. Derzeit werden zehn weitere Standorte mit M-WLAN und damit
eduroam erschlossen.
Das LRZ pflegt eine Karte (http://www.lrz.de/services/netz/mobil/mobil_ap/map/, s.a. Abschnitt 11.11.3) mit
den Zugangspunkten zum WLAN des MWN, auf der nun auch verzeichnet ist, wo die Stadtwerke München
den eduroam-Zugang bieten, wie z.B. am Marienplatz.
3
Abbildung 2: eduroam-WLAN-Standorte am Marienplatz,
die von den Stadtwerken München betrieben werden
1.3 Anbindung der Staatlichen Museen und Archive an das MWN
Die staatlichen Museen Bayerns arbeiten seit mehreren Jahren daran, ihre IT-Infrastruktur zu vereinheitlichen, zu modernisieren und spezifische Dienste zu zentralisieren. Die Voraussetzung dafür ist eine angemessene Netzanbindung, die durch eine Mitnutzung des MWN und anderen Diensten des LRZ erfolgen
soll.
2014 wurden das Neue Museum in Nürnberg, das Bayerische Armeemuseum in Ingolstadt und das Deutsche Theatermuseum in München an das MWN angebunden.
1.4 SuperMUC Status and Results Workshop, User
Forum und Berichtsband
Während der ersten zwei Betriebsjahre konnten mit SuperMUC, dem Höchstleistungsrechner am LRZ, bereits sehr beeindruckende Ergebnisse erzielt werden. Mehr
als einhundert Projekte reichten Berichte für den SuperMUC Berichtsband ein, der im
Juni zur International Supercomputing Conference ISC‘14 in Leipzig veröffentlicht
wurde.
Das LRZ informierte seine Benutzer im Rahmen eines „Status and Results Workshops“ auch über die Pläne für SuperMUC Phase 2, durch die die Rechenleistung
von SuperMUC nochmals verdoppelt wird. Außerdem wurden die neue Insel “SuperMIC” mit Intel Xeon Phi Beschleunigerkarten sowie das neue Remote-Visualisierungscluster vorgestellt.
4
1.5 PRACE ISC Award: 1,4 Petaflops mit SeisSol auf SuperMUC
Bei der Eröffnung der International Supercomputing Conference (ISC’14) in Leipzig wurde die Arbeit „Sustained Petascale Performance of Seismic Simulations with SeisSol on SuperMUC“ mit dem “PRACE ISC
Award” der Partnership for Advanced Computing in Europe (PRACE) ausgezeichnet. Den Autoren der TU
und LMU München gelang es erstmals, unterstützt durch die Experten des LRZ, über einen längeren Zeitraum eine Rechenleistung von 1,4 Petaflops auf dem SuperMUC zu erzielen. Diese Arbeit wurde außerdem
für den Gordon Bell-Preis vorgeschlagen. Ferner erhielt Alexander Breuer aus der Arbeitsgruppe von Prof.
Bader den George Michael Memorial Award für die Arbeiten an SeisSol.
1.6 Science Veröffentlichung über genetische Algorithmen
Wissenschaftlern des internationalen 1KITE-Projektes (1.000 Insect Transcriptome Evolution) ist es mit
einer bisher unerreichten Datenmenge von 1.478 Genen, der Entwicklung völlig neuer Analyseverfahren
und der Verwendung von Höchstleistungsrechnern wie dem SuperMUC gelungen, den Stammbaum der
Insekten aufzuklären. Mit der Veröffentlichung dieser Arbeit auf der Titelseite der Fachzeitschrift Science
(November 2014) werden die Grundlagen für ein besseres Verständnis der Evolution dieser Tiergruppe
gelegt. Dieses Wissen ist deshalb von so großer Bedeutung, weil unsere terrestrischen Lebensräume sowohl in kultureller als auch in kommerzieller Hinsicht entscheidend von Insekten geprägt werden. Die Ergebnisse werden dazu beitragen, ganz neue und auch effizientere Wege bei der Nutzung biologischer
Ressourcen, in der Landwirtschaft oder in der Schädlingsbekämpfung zu beschreiten (http://www.sciencemag.org/content/346/6210/763).
1.7 Zweiter Extreme Scaling Workshop
Im Juni 2014 fand der zweite „Extreme Scaling Workshop“ am LRZ statt, in dem ausgewählte Benutzergruppen die Skalierung ihrer Applikationen bis zur vollen Systemgröße des SuperMUC testen konnten.
Hierbei erreichten drei Applikationen eine Skalierung bis zu achtzehn Inseln (147.456 Cores), fünf Applikationen konnten bis sechzehn Inseln skaliert werden und zwei bis zwölf bzw. acht Inseln. Die Ergebnisse
des Workshops wurden in einem speziellen Teil der Herbstausgabe des GCS Magazins "InSiDe" dargestellt.
1.8 Vorbereitungen für die Phase 2 des SuperMUC
Der 2013 auf Wasserkühlung ertüchtigte Höchstleistungsrechner-Bereich im Obergeschoss des Rechnergebäudes wurde für die „Phase 2“ des SuperMUC vorbereitet. Seit dem Jahresende 2014 wird dort die
neue Hardware installiert. Auch die Elektroversorgung wurde verändert, um der neuen Hardware eine getrennte Versorgungsumgebung bieten zu können.
1.9 Einsparungen beim Energieverbrauch von HPC Systemen
Aus einer Forschungskooperation zwischen LRZ und IBM hervorgegangen, arbeitet der SuperMUC als
erstes System weltweit im Produktiveinsatz mit einer Energie-bewussten Systemmanagement-Software.
Diese analysiert die Anwendungen einzelner Benutzer und passt die Leistung der Prozessoren über die
Taktfrequenz so an, dass der Energieverbrauch ohne merkliche Abstriche der Anwendungsperformance
verringert wird. In Zukunft sollen alle HPC-Systeme des LRZ mit energie-bewussten Managementsystemen
betrieben werden, wozu auch gehört, dass Rechen-Knoten vollautomatisch je nach Bedarf ab- und wieder
angeschaltet werden; für das Linux Cluster am LRZ konnte eine Implementierung des letzteren Konzeptes
im Laufe des Jahres 2014 in Betrieb genommen werden.
1.10 Überwachungssoftware Persyst
Innerhalb des vom BMBF geförderten Projektes "Flexibles Framework zur Energie- und Performanceanalyse hochparalleler Applikationen im Rechenzentrum“ konnte die skalierbare Überwachungssoftware Persyst zur systematischen Effizienzanalyse von Applikationen fertiggestellt werden. Hierbei werden auch die
Energieverbräuche der Applikationen erfasst, und es ist möglich, die vom Prozessor und Memory benötigten Energien von den restlichen Energieströmen in das IT-Equipment zu trennen. Damit steht nun dem
LRZ eine Infrastruktur zur Überwachung der beiden wichtigsten Betriebsparameter Applikationsperformance und Energieeffizienz zur Verfügung.
5
1.11 Power Data Aggregation Monitor (PowerDAM)
PowerDAM ist ein am LRZ entwickeltes Softwarewerkzeug, um wichtige Sensorwerte von Rechenzentrumsinfrastrukturkomponenten und IT-Systemen einzusammeln, in einer zentralen Datenbank abzulegen
und auszuwerten. Das Tool ermöglicht somit einerseits die Bestimmung und Anzeige der aktuellen Energieeffizienz eines Rechenzentrums. Andererseits erlaubt PowerDAM eine weitere Optimierung der Energieeffizienz wichtiger Komponenten in der Elektro- und Kühlinfrastruktur anhand von zeitlichen Verlaufsdarstellungen der abgespeicherten Messwerte und deren Korrelation mit Parametern wie beispielsweise
Außentemperatur und -feuchte sowie IT-Leistungsaufnahme bzw. zu kühlende Wärmelast.
1.12 Webfrontend für Remote Visualisierung
Über ein vom LRZ erstelltes Webfrontend ist Nutzern ab sofort ein unkomplizierter Zugriff auf den LRZRemote Visualisierungsdienst möglich: https://rvs.lrz.de/
1.13 Erneuerung der VMware- und Linux-Cluster-Infrastruktur
Die VMware-Virtualisierungsinfrastruktur des LRZ wurde 2014 grundlegend erneuert: mit insgesamt 94
neuen Blade-Systemen und insgesamt 1.880 Kernen, 24 TB RAM und 500 TB Hintergrundspeicher verfügt
das LRZ über eine sehr leistungsfähige Plattform. Durch eine neue, direkte Anbindung an das LRZ-Backbone mit 320 Gbit/s können selbst anspruchsvollste Anwendungen ausgeführt werden. Die Migration erfolgte im November 2014 unterbrechungsfrei im laufenden Betrieb.
2014 stellte das LRZ einen Großgeräte-Antrag auf Ersetzung technologisch veralteter Segmente des LinuxClusters, mit dem auch eine Erhöhung der Energieeffizienz durch Warmwasserkühlung sowie der Sekundärnutzung der Abwärme durch Bereitstellung von Kühlinfrastruktur auf Basis von Adsorptionskühlung erreicht werden soll. Der erste Teil des Antrages (landesfinanziertes Großgerät nach Art. 143c GG) wurde
bereits genehmigt und mit der Installation auf Basis von gleicher Technologie wie bei SuperMUC Phase 2
wurde schon begonnen.
1.14 Erhöhung der Redundanz im Münchner Wissenschaftsnetz
In den letzten Jahren wurden Standorte mit vielen Nutzern redundant, d.h. mit mehreren Leitungen ans
MWN angeschlossen, um damit die Sicherheit gegenüber Komponenten- oder Faserausfällen zu erhöhen.
In Jahr 2014 konnte die redundante Anbindung der Hochschule München in Betrieb genommen werden.
Damit sind Ende 2014 die LMU und die TU München in der Innenstadt, die Hochschule München sowie
die Standorte Großhadern, der Campus Garching sowie der Campus Weihenstephan redundant angebunden.
1.15 Starkes Wachstum bei Exchange am LRZ
Beim Exchange-Dienst war auch in 2014 wieder ein starkes Wachstum zu verzeichnen. Im Zeitraum November 2013 bis November 2014 stieg die Nutzerzahl um ca. 10.000 auf 40.000 (+33 %) und der durch
die Postfächer belegte Speicherplatz um ca. 4,5 auf knapp 11 TByte (+75 %). Abbildung 3 zeigt die Entwicklung seit Mitte 2011.
2014 führte das LRZ die Migration von „Exchange 2010“ auf die aktuelle Version „Exchange 2013“ durch,
bei der alle Postfächer in die neue Umgebung verschoben werden mussten
Die Hochschule München wurde 2014 an den Exchange-Produktionsbetrieb des LRZ angebunden. Dazu
wurden zuvor einige zusätzlich benötigte Eigenschaften implementiert wie spezielle Sichtbarkeitsregeln für
Adressbücher.
6
Exchange-Nutzung 2011 bis 2014
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Anzahl Postfächer
Speicherplatz [TByte]
Abbildung 3: Anstieg der Exchange-Nutzung im MWN
1.16 Desktop-Management TUM-PC
Im Jahr 2014 stieg die Anzahl der vom LRZ betreuten Microsoft Windows-Systeme auf rund 1.200 an,
davon werden rund 240 Systeme in mehreren Pools für externe Kunden kostenpflichtig betreut. Im MWNADS sind zum Ende des Jahres 2014 über 9.500 Systeme direkt angebunden. Die Anzahl der Kennungen
im MWN-ADS beträgt rund 132.000.
In Kooperation mit der TU München wurde das Projekt TUM-PC in die Produktion überführt. Ziel des Projektes ist es, den Teiladministratoren der TUM die Möglichkeit zu geben, ohne großen Aufwand WindowsRechner zu installieren und die installierten Softwarepakete automatisch zentral pflegen zu lassen. Hierbei
sorgt das LRZ für die Bereitstellung des notwendigen Softwareverteilungssystems und die Pflege der Softwarepakete. Zum Jahresende waren rund 1.000 Rechner der TUM in das System eingebunden, die von
über 64 Einrichtungen an der TUM genutzt werden.
Abbildung 4: Anstieg der Anzahl verwalteter TUM-PCs in 2014
1.17 Security Incident and Event Management System
Für das LRZ-CSIRT, also das Computer Security Incident Response Team, das sich am LRZ um IT-Sicherheitsvorfälle kümmert, wurde in diesem Jahr ein neues, web-basiertes Security Incident Management
System, das im Rahmen einer studentischen Abschlussarbeit konzipiert und implementiert wurde, in Be-
7
trieb genommen. Dieses Werkzeug bietet zum einen eine bedienfreundliche Möglichkeit zur Vorfallsmeldung und stellt zum anderen die Einhaltung des am LRZ festgelegten Security-Incident-Prozesses sicher.
Integrierte Automatismen, etwa zur Benachrichtigung des Vorfallmelders oder der für das betroffene ITSystem zuständigen Abteilungs- und Gruppenleiter oder zur Festlegung maximaler Reaktionszeiten, die
Messung der Bearbeitungsdauer eines Vorfalls, sowie Filter-, Such- und Reportingmöglichkeiten runden
den großen Funktionsumfang ab.
1.18 Die wichtigsten öffentlichen Auftritte des LRZ
Neben zahlreichen, in den folgenden Kapiteln dokumentierten, wissenschaftlichen Auftritten stellt sich das
LRZ regelmäßig einer breiteren Öffentlichkeit vor.
Am 11. Oktober 2014 beteiligte sich das LRZ wie in den Vorjahren am „Tag der offenen Tür“ auf dem
Forschungscampus Garching. Weit über eintausend Besucher nutzten wieder die Gelegenheit, das LRZ
und sein Zentrum für Virtuelle Realität und Visualisierung V2C kennen zu lernen.
Auch bei den Münchner Wissenschaftstagen vom 8. bis 11. November 2014 war das LRZ mit einem eigenen „Marktstand der Wissenschaft“ vertreten und führte eine „Force-Feedback-Molekulardynamik-Simulation“ vor, bei der die Besucher mit eigenen Händen die Kraft der Moleküle spüren und auf der portablen
Stereoprojektionsanlage des LRZ sehen konnten (s. Abbildung 5).
Abbildung 5: Stand des LRZ bei den Münchner Wissenschaftstagen
Am Akademientag im November 2014 zeigte die Kommission für Glaziologie eine am LRZ entwickelte
portable Version der Visualisierung des Vernagtferners mit Hilfe eines Datenhelms.
8
Abbildung 6: Präsentation beim Akademientag im November 2014
Diese Visualisierung war auch einer von insgesamt 16 Beiträgen beim „Open Lab Day“ des V2C am 16.
Dezember 2014, bei dem verschiedene Studien- und wissenschaftliche Arbeiten den Erkenntnisgewinn
durch Virtuelle Realität vorstellten. Das große Interesse am V2C zeigen die insgesamt über 2.500 Besucher
und Nutzer bei über 300 Terminen im Jahr 2014.
Abbildung 7: Open Lab Day des V2C am 16. Dezember 2014
9
2 Forschung und Projekte
2.1
Forschungskoordination und Projektmanagement
Bereits in den letzten Jahren wurden gezielte Maßnahmen getroffen, um die zahlreichen am LRZ stattfindenden Forschungsaktivitäten besser zu unterstützen und in den Vordergrund zu rücken. Mit dem für 2014
angekündigten Start des neuen europäischen Forschungsrahmenprogramms Horizon 2020 war zu erwarten, dass auch die Anzahl der Projektanträge deutlich ansteigen wird. Aus diesen Gründen ist dieser Aufgabenbereich im Jahr 2014 durch weiteres Personal verstärkt worden, so dass zukünftig nicht nur die Forschungstätigkeiten und die administrative Projektbetreuung, sondern auch das Management der Projektfinanzen, die Antragsstellung sowie die Öffentlichkeitsarbeit bezogen auf die Projektergebnisse besser unterstützt werden können.
Diese Verstärkung versetzte das LRZ in die Lage, neben den über zwanzig laufenden Projekten, sich an
zwölf Anträgen für EU-Projekte sowie an weiteren Projekten anderer Fördergeber zu beteiligen. Darüber
hinaus wurden im Rahmen der Partnerschaftsinitative Computational Science (πCS) zehn Informationsworkshops mit Arbeitsgruppen in den Bereichen Astrophysik, Lebenswissenschaften und Geowissenschaften der beiden Münchner Universitäten sowie des Helmholtzzentrums für Gesundheit und Umwelt (HMGU)
durchgeführt, außerdem mit Professoren der Universitäten in Wien, Linz und Innsbruck sowie dem
UNISDR. Für die hausinterne Koordination der entsprechenden Teams sowie der Projektaktivitäten fanden
sechs Koordinationstreffen in zweimonatigem Turnus statt.
Neben der Intensivierung der internen Aktivitäten im Bereich des Wissenschaftsmanagements wurden
auch die externen Kontakte ausgeweitet, so etwa durch mehrere Schulungen, durch die Teilnahme an der
Jahrestagung des Netzwerks Wissenschaftsmanagement und durch Kontakte zu den entsprechenden Referaten der Münchner Universitäten sowie durch die Zusammenarbeit mit der Bayerischen Forschungsallianz (BayFOR).
Zur Vereinfachung der Projektadministration wurde das Projektverwaltungssystem P*NK der Firma MeditCon eingeführt. Zunächst auf den Einsatz für die Verwaltung der Projektfinanzen von BMBF-Projekten (zur
Erstellung der Zahlungsnachweise) beschränkt, kamen im Laufe des Jahres weitere Projekttypen (z.B. EUProjekte) sowie die Nutzung zur Erfassung der Mitarbeiterzeiten hinzu. Da hierzu auch einige Dinge speziell
für das LRZ neu implementiert werden mussten, war diese Einführung mit einem signifikanten Zeitaufwand
verbunden.
2.2 Energieeffizientes Rechenzentrum
2.2.1 Einsparungen beim Energieverbrauch von HPC Systemen
Aus einer Forschungskooperation zwischen LRZ und IBM hervorgegangen, arbeitet der SuperMUC als
erstes System weltweit im Produktiveinsatz mit einer energie-bewussten Systemmanagement-Software.
Diese analysiert die Anwendungen einzelner Benutzer und passt die Leistung der Prozessoren über die
Taktfrequenz so an, dass der Energieverbrauch ohne merkliche Abstriche der Anwendungsperformance
verringert wird. In Zukunft sollen alle HPC-Systeme des LRZ mit energie-bewussten Managementsystemen
betrieben werden, wozu auch gehört, dass Rechenknoten vollautomatisch je nach Bedarf ab- und wieder
angeschaltet werden; für das Linux Cluster am LRZ konnte eine Implementierung des letzteren Konzeptes
im Laufe des Jahres 2014 in Betrieb genommen werden.
2.3
Energieseminar
Im Rahmen des Kompetenzteams Energie wurde im Jahr 2014 eine Seminarreihe zum Thema Energieeffizienz gestartet. Die Motivation für die abteilungsübergreifende Veranstaltung ergab sich aus dem Wunsch,
die Informationsflüsse zwischen den Mitarbeitern, die mit der Thematik betraut sind, zu verbessern.
In insgesamt 10 Vorträgen an 5 Terminen konnten die Teilnehmer ihre Arbeiten vorstellen und in anschließenden Diskussionsrunden Tipps und Anregungen austauschen. Die Qualität der Vorträge war dabei –
nicht zuletzt wegen eines für den besten Vortrag ausgelobten Preises – durchweg hoch.
Auf einstimmigen Wunsch der Teilnehmer hin wird das Seminar in leicht veränderter Form auch wieder im
Jahr 2015 stattfinden.
10
Forschung und Projekte
2.4 Projekte, an denen sich das LRZ beteiligt
Die Drittmittelprojekte des LRZ werden nachfolgend in alphabetischer Reihenfolge aufgeführt.
2.4.1 Automatic Online Tuning (AutoTune)
Das Ziel des seit Oktober 2011 von der EU geförderten FP7
Projektes „Automatic Online Tuning“ (AutoTune) ist die Erweiterung des von der TUM entwickelten Periscopetools um Tuning-Plugins zur automatischen Optimierung von Applikationen
im HPC-Umfeld hinsichtlich Performancesteigerung und Energieeffizienz. Das Periscope Tuning Framework (PTF) benutzt
die wichtigsten Grundsätze des Periscopetools: auf Fachwissen
basierende Formalismen zur automatischen Analyse, Suche auf Basis von Programmabschnitten, und
eine verteilte skalierbare Architektur. PTF hat eine Plugin-basierte Architektur und wurde im Laufe der
Zeit mit unterschiedlichen Plugins erweitert: ein Parallel-Patterns Plugin, ein hybrides Manycore-HMPPPlugin, ein Dynamic Voltage Frequency Scaling (DVFS) Plugin, ein MPI-Parameter-Plugin, ein MasterWorker-MPI-Plugin, und ein Compiler-Flag-Selection-Plugin.
Das LRZ war für die Entwicklung des DVFS Plugins verantwörtlich, welches für den Energieverbrauchsoptimiertierung durch Frequenz-Skalierung sorgt. Verschiedene Optimierungsaspekte bezüglich
der Leistungsaufnahme, Laufzeit und Energie sind im Plugin auch vorhanden, darunter das Total Cost
of Ownership, Power Capping, und das Energy-Delay-Product. Das Plugin basiert auf drei Modelle, je
ein Model für Laufzeit, Leistungsaufnahme, und Energie.
Weiter hat das LRZ die Enopt-Bibliothek entwikelt, um die Frequenzen zu setzen, sowie den Energieverbrauch auf einzelner Abschnitte zu messen. Mittels Enopt greift PTF auf die Energiezähler zu und
setzt die CPU-Frequenzen. Darüber hinaus sind die Anwendungen auch nur mit Enopt instrumentierbar.
Das LRZ hat zum Projekt die Expertise für das Monitoring sowie für die Anwendungsoptimierung beigesteuert und stellte sein HPC-System SuperMUC als Test-Umgebung für die entwickelte Tools zur Verfügung.Im Rahmen des vom LRZ geleiteten Arbeitspaket „Dissemination & Exploitation“ wird dazu eine
geignete Plattform („AutoTune Demonstration Centre“) aufgeführt. Damit soll die Verbreitung im HPCUmfeld und Pflege des im AutoTune entwickelten Softwarepakets nach Projektende realisiert werden.
Highlights in 2014
Workshop: “Energy Days” hat am LRZ im Januar 2014 stattgefunden.
Roll-Out vom ersten Release des PTF-Prototyps und Plugins.
Evaluierung des DVFS (Dynamic Voltage and Frequency Scaling) Plugins.
Optimierung von SeisSol (Geophysik Anwendung) hinsichtlich Energieverbrauch, ‚Power Capping‘,
und ‚Total Cost of Ownership‘.
Projektverlängerung um 6 Monate aufgrund des Wegfalls des Industriepartners CAPS Enterprise.
Memorandum of Understanding (MoU) des AutoTune Demonstration Center wurde von den Partnern
unterschrieben.
Konferenzen & Veranstaltungen
ICS 2014, “CPU Frequency Tuning for Optimizing the Energy to Solution”, Juni 2014, München,
Deutschland.
Energie Tag Workshop, “Enopt library” Januar 2014, Garching bei München, Deutschland.
Webinar mit IBM, “Enopt library”, September 2014, Garching bei München, Deutschland.
Supercomputing 2014, “AutoTune”, Vortrag auf dem LRZ Messestand, November 2014, New Orleans,
USA
Publikationen
Schöne R., Treibig J., Dolz M., Guillen C., Navarrete C., Knobloch M., Rountree B., Tools and methods
for measuring and tuning the energy efficiency of HPC systems. In: Scientific Programming, Volume
22, Issue 4, Januar 2014
11
Navarrete C., Guillen C., Hesse W., Brehm M., Autotuning the energy consumption. In: Parallel Computing: Accelerating Computational Science and Engineering (CSE), Advances in Parallel Computing
25, IOS Press, 2014.
Steckbrief
Projektlaufzeit
Partnerinstitutionen
15.10.2011 – 14.4.2015
Technische Universität München
Leibniz-Rechenzentrum
CAPS enterprise
Universität Autònoma de Barcelona
National Unviersity of Ireland Galway, ICHEC
Universität Wien
IBM (associated partner)
Kontaktperson
Dr. Matthias Brehm
Förderorganisation
European Commission FP7
Website
www.autotune-project.eu
12
2.4.2 Dynamical Exascale Entry Platform / Extended Reach (DEEP/-ER)
The DEEP project is an innovative European response to the
Exascale challenge. The consortium develops a novel, Exascale-enabling supercomputing architecture with a matching
software stack and a set of optimized grand-challenge simulation applications. DEEP takes the concept of compute acceleration to a new level: instead of adding
accelerator cards to Cluster nodes, an accelerator Cluster, called Booster, will complement a conventional HPC system and increase its compute performance. Together with a software stack focused on
meeting Exascale requirements - comprising adapted programming models, libraries and performance
tools - the DEEP architecture will enable unprecedented scalability. The Cluster-level heterogeneity of
DEEP attenuates the consequences of Amdahl’s law allowing users to run applications with kernels of
high scalability alongside kernels of low scalability concurrently on different sides of the system, avoiding
at the same time over and under subscription. An extrapolation to millions of cores would take the DEEP
concept to an Exascale level.
DEEP-ER advances the Cluster-Booster architecture developed in DEEP from a hardware point of view
in terms of processor technology, network interconnect, and storage. On the software side of the project
focuses on two central research topics: highly scalable parallel I/O and resiliency.
With its expertise in energy efficiency, LRZ contributes to hardware design, system software, and operations. With the start of the DEEP-ER project, LRZ is also involved with a demonstration application code
from the field of earthquake simulations. LRZ also manages the project’s dissemination activities ensuring the projects’ visibility to the HPC community, the European Commission and the general public
through a variety of communication channels.
Highlights in 2014
The first DEEP hardware was installed at the Jülich Supercomputing Centre
An image video was produced by the project, that received quite some attention at SC14 in New Orleans as well as online.
Events and Conferences
ISC’14, June 22 – 26 2014, Leipzig/Germany
SC14, November 16 – 21 2014, News Orleans / United States
Fast Facts
Project duration
Partner institutions
1/12/2011 – 31/8/2015 (DEEP)
1/10/2013 – 30/9/2016 (DEEP-ER)
Astron
Barcelona Supercomputing Center
CERFACS
CGG
CINECA
The Cyprus Instiute
École polytechnique fédérale de Lausanne
Eurotech
Jülich Supercomputing Centre
Fraunhofer ITWM
German Research School for Simulation Sciences
INRIA
Intel
Katholieke Universiteit Leuven
ParTec
Universität Heidelberg
Universität Regensburg
Contact person
Axel Auweter (DEEP)
Dr. Ferdinand Jamitzky (DEEP-ER)
Funding agency
Website
www.deep-project.eu
www.deep-er.eu
13
Seagate
2.4.3 European Exascale Software Initiative 2 (EESI2)
One of the main objectives of the EESI2 project is to provide recommendations on strategic European actions with a particular focus on software
key issues improvement, cross cutting issues advances, and gap analysis.
The objective of EESI2 is to build on the work done within the EESI1 project
and to extend this role of external and independent representative synthesis by key issues.
Highlights in 2014
Publication of an EESI-2 special study to measure and model how investments in HPC can ceate
financial ROI and scientific innovation in Europe.
Big Data and Extreme-scale Computing (BDEC) meeting in Fukuoka, Japan, February 26 to February
28, 2014
Fast Facts
Project duration
1/09/2012 – 31/03/2015
Total
PRACE AISBL
Leibniz Supercomputing Centre (LRZ)
Barcelona Supercomputing Center (BSC)
French Alternative Energies and Atomic Energy
Commission (CEA)
National Center for Scientific Research (CNRS)
GENCI
German Research School for Simulation Sciences (GRS)
French Institute for Research in Computer Science and Control (INRIA)
Jülich Supercomputing Centre (JÜLICH)
National Supercomputing and e-Science Support Center in the Netherlands (SARA)
Science and Technology Facilities Council
(STFC)
University of Bristol
School of Mathematics at the University of Edinburgh
University of Manchester
Department of Innovation Engineering (DII) of
the University of Salento
French National Research Agency (ANR)
Moscow State University
CAPS Entreprise
German Aerospace Center (DLR)
Électricité de France (EDF)
14
Intel
Numerical Algorithms Group (NAG)
UK Campus
Ter@tec
Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
Finnish IT Center for Science (CSC)
Technische Universität Dresden
German Climate Computing Centre (DKRZ)
CINECA
European Centre for Research and Advanced
Training in Scientific Computing (CERFACS)
Contact person
Dr. Michael Ott
Funding agency
Website
http://www.eesi-project.eu/pages/menu/project.php
15
2.4.4 European Grid Infrastructure (EGI-InSPIRE)
The EU project EGI-InSPIRE establishes a sustainable European Grid Infrastructure (EGI). EGI provides access to high-throughput computing resources with the
use of grid and cloud computing techniques. EGI is linking research computing centres all over Europe to provide respective computing resources to a broad range of
scientific areas.
In EGI the LRZ acts as the competence centre for the grid middleware Globus. It provides 2nd and 3rd
level support to all EGI sites with a Globus installation as well as researchers using Globus software.
Highlights in 2014
In 2014 Germany decided to leave the EGI. Therefore, the German participation in the support effort was
greatly reduced. However, this process went along with further negotiations about a reorientation of EGI
in general which opened a pathway for Germany to rejoin EGI in 2015.
A webinar for the usage of Grid-Software Gsissh-Term was presented. This webinar can be viewed
online via YouTube: https://www.youtube.com/watch?v=YkxEYIjZww4
Fast Facts
Project duration
1.5.2010 – 30.4.2014
EGI.eu
CERN
EMBL
37 European scientific institutions representing
the respective national grid infrastructures
9 partners from the Asia-Pasific area
Contact person
Dr. Helmut Heller
Funding agency
European Commission
Website
https://www.egi.eu/about/egi-inspire/
16
2.4.5 Ein flexibles Framework zur Energie- und Performanceanalyse
hochparalleler Applikationen im Rechenzentrum (FEPA)
Das Ziel von FEPA ist die Realisierung einer Monitoringssoftware zur systematischen Effizienzanalyse
von Applikationen in Abhängigkeit von den Charakteristiken großer HPC-Systemen. Neben der gezielten
Optimierung bezüglich Performance und Energieverbrauch von Applikationen sollen im Projekt
Erkenntnisse gewonnen werden, die eine Senkung des Energieverbrauchs durch angepasste
Ausführungs-Modalitäten (Frequenzanpassung, Nutzung weniger Kerne/Sockel, etc.) bei vertretbaren
Laufzeit-Zugeständnissen ermöglichen. Die Voraussetzungen dazu bilden unter anderem die
entwickelten Monitoring-Systeme aus den Vorgängerprojekten ISAR und TIMaCS und entwicklen ein
integriertes Monitoring Tool. Ein weiteres Ziel des FEPA-Projekts ist die Umsetzung eines PerformanceEngineering-Prozesses. Im Rahmen dieses Projektes soll u.a. das am LRZ eingesetzte Monitoring-Tool
„PerSyst“ weiterentwickelt werden.
Der Energieverbrauch eines HPC-Systems hängt von der Kühlungsinfrastruktur, sowie von den Eigenschaften der genutzten Applikationen (z. B. Art und Intensität der Nutzung von Instruktionen, Caches
und Hauptspeicher) ab. Für eine kombinierte Performance- und Energieverbrauch -Optimierung der
Applikationen müssen deren Entwickler Hintergrundwissen über die verwendeten Architekturen und
Möglichkeiten der Energieoptimierung erwerben und anwenden. Um die Anwender bei diesen Optimierung zu unterstützen und allgemein die Energie- und Performance-Effizienz des HPC-Systems zu verbessern, benötigen Rechenzentren (wie das LRZ) geeignete Monitoring-Systeme, die den Administratoren, Benutzern und den Mitarbeitern der Applikationsunterstützung jeweils die nötigen Informationen
liefern.
Das im LRZ eingesetzte Monitoring-Tool PerSyst realisiert eine systemweite Performance-Überwachung
und korreliert deren Ergebnisse mit den auf dem HPC-System laufenden Applikationen. Die gewonnenen PerSyst-Daten sind durch eine Weboberfläche, die am LRZ entwickelt wurde, zugänglich.
Highlights in 2014
Roll-Out der GUI für die Visualisierung der Performance Daten.
Konzeption und Implementierung sogenannter Strategy-Maps für die automatische Analyse.
Energy Days Workshop, “Energy Aware Scheduling” Januar 2014, Garching bei München, Deutschland.
Supercomputing 2014, “The PerSyst Tool”, LRZ Messestand-Vortrag. November 2014, New Orleans,
USA.
Publikationen
Guillen C., Hesse W., Brehm M., The PerSyst Monitoring Tool – A Transport System for PerformanceData Using Quantiles. In Euro-Par 2014: Parallel Processing Workshops - Euro-Par 2014 InternationalWorkshops, Porto, Portugal, August 25-26, 2014, Revised Selected Papers, Part II Lecture Notes in
Computer Science, Springer, 2014
Steckbrief
Projektlaufzeit
1.7.2013 – 30.6.2016
Friedrich-Alexander-Universität
NEC Deutschland GmbH
Kontaktperson
Dr. Matthias Brehm
Förderorganisation
BMBF (Call: HPC-Software für skalierbare
Parallelrechner)
17
2.4.6 GÉANT GN3plus
GÉANT is the pan-European data network for the research education community. It interconnects national
research and education networks (NRENs) across
Europe in the Research & Education (R&E) community. GÉANT currently connects over 50 million users
at 10,000 institutions across Europe, enables collaboration on projects ranging from biological science to
earth observation, humanists, and arts. GN3plus is a
project funded by the European Commisson to develop new network functionalities. The project members belong to the European NRENs or the head organization, GÉANT Association.
Highlights in 2014
Identity Management:
Based on the definition of different core and management workflows and hence derived requirements
the GÉANT-TrustBroker project team designs the core services necessary to fully automate the SAML
metadata exchange between IDPs and SPs. From a user’s point-of-view this component is similar to a
standard Centralized Discovery Service as often seen in SAML- and webservice-based. Additionally,
IDP and SP software has to be extended in order to integrate the exchanged SAML metadata and attribute conversion rules shared by other IDP administrators automatically.
Abbildung 8: GÉANT-TrustBroker-Workflow nach der DAME-Protokollspezifikation
For the user-initiated GNTB core workflow, as seen in above figure, the Dynamic Automated Metadata
Exchange (DAME) protocol was specified and submitted as an Internet-Draft (I-D) to the Internet Engineering Task Force (IETF) for standardization and presented at the 90th IETF meeting held in Toronto
as well as at the European Workshop on Identity and Trust in Vienna. To demonstrate the functionality
of the GNTB core service and the workflows, a proof-of-concept was implemented in LRZ’s Shibboleth
testbed.
If an employee wants to change his affiliation but is going to continue using a service as part of his
research, he might want to link his first account to a neutral second account in order to still have access
to the service and his data. There are two options to link an account: Either a central service is used or
the linking is done on the service provider side.
For a central account linking, the architecture was designed, i.e., a database was created for the account
information in JRA3. A service provider in the backend of the central service requests the user information from the user’s identity provider. This user information is needed for link establishment. The service provider, based on the Python implementation of SAML PySAML2, can handle requests in SAML
18
(used in R&E) and OpenID Connect (used in industry). Furthermore, the frontend of the linking service
was created.
Abbildung 9: SP-side account linking with ORCID
For the account linking at the SP side, a linking service based on the SAML implementation SimpleSAMLphp was designed. It can link SAML account information with account information from ORCID,
a unique registry for researchers, as shown in the figure. This SP-side account linking service can easiliy
be expanded for use cases with OpenID Connect.
Network and Service Management:
Originally showcased at the Symposium 2013, CMon has received a lot of positive feedback from potential users. In 2014 CMon interfaced with the automatic provisioning system AutoBAHN (AB) to automatically monitor dynamic circuits. Several installations at different NRENs are currently in test operation
and aim to go productive in 2015. The roadmap for 2015 focuses on the integration with perfSonar (for
monitoring data) as well as perfSonar UI.
Another service of GÉANT, which needs to be monitored, is the Multi-Domain VPN (MDVPN). Not only
the link state is important, but also connection quality according to service level agreements. LRZ proposed to adapt and extend the well-known open-source monitoring tool Nagios in order to fullfill all the
requirements needed for service quality monitoring (SQM) in SA4. Near the end of 2014, a working
prototype was presented by LRZ, which received very positive feedback from the other project members.
Cloud Services:
In SA7, where LRZ became a new participant at the end of 2014, LRZ started the creation of specific
documents relative to the role a NREN will take, e.g., cloud service provider or broker, as well as the
compilation of the relevant standards oriented on the cloud service's lifecycle to better support NRENs
in different phases.
TF-EMC2, GÉANT-TrustBroker project overview, 11/02/2014, Zurich (Switzerland)
FIM4R, GÉANT-TrustBroker, 24/04/2014, Frascati (Italy)
TNC2014, GÉANT TrustBroker: Dynamic inter-federation identity management, 19/05/2014, Dublin
(Ireland)
IFIP SEC 2014, Géant–TrustBroker: Dynamic, Scalable Management of SAML–Based Inter–federation
Authentication and Authorization Infrastructures, 03/06/2014, Marrakech (Marocco)
EUNIS 2014, Géant-TrustBroker: Simplifying Identity & Access Management for International Research Projects and Higher Education Communities, 13/06/2014, Umea (Sweden)
IARIA INFOCOMP 2014, A SAML Metadata Broker for Dynamic Federations and Inter-Federations,
24/07/2014, Paris (France)
90th IETF meeting, Integration of Dynamic Automated Metadata Exchange into SAML 2.0 Web
Browser SSO Profile, 20-25 July 2014, Toronto (Canada)
European Workshop on Identity and Trust, Round table about GÉANT-TrustBroker and Internet-Draft
DAME, 04/12/2014, Vienna (Austria)
19
Project Meeting of JRA3 with presentations, 29-30 April 2014, Stockholm, Sweden
Project Meeting of JRA3 with presentations, 25-26 November 2014, Rome, Italy
CMon Team Meeting at LRZ, 3-5 December 2014, Garching, Germany
GÉANT Secure Code Training, 28-31 October 2104, Berlin, Germany
GÉANT Summer School for Developers, 23-26 September 2014, Poznań, Poland
Publications
Pöhn, D., Metzger, S., Hommel, W., Project GÉANT-TrustBroker – Dynamic Identity Management
across Federation Borders, In: Networking with the World, The 30th Trans European Research and
Education Networking Conference - Selected Papers, Dublin, Ireland, May, 2014.
Pöhn, D., Metzger, S., Hommel, W., GÉANT –TrustBroker: Dynamic, Scalable Management of SAML–
Based Inter–federation Authentication and Authorization Infrastructures, In: ICT Systems Security and
Privacy Protection, 428, S. 307–320, Springer, Berlin; Heidelberg, Deutschland, June, 2014.
Pöhn, D., Metzger, S., Hommel, W., GÉANT -TrustBroker: Simplifying Identity & Access Management
for International Research Projects and Higher Education Communities, In: Proceedings of the 20th
congress of the European University Information Systems Organisation (EUNIS 2014), Umea, Sweden,
June, 2014.
Pöhn, D., Metzger, S., Hommel, W., A SAML Metadata Broker for Dynamic Federations and Inter-Federations, In: Proceedings of INFOCOMP 2014 the Fourth International Conference on Advanced Communications and Computation, S. 132-137, Paris, France, July, 2014.
Fast Facts
Project duration
24/10/2013 – 31/03/2015
01/04/2013 – 30/04/2015
Leibniz Supercomputing Centre
Contact person
PD Dr. Wolfgang Hommel
Funding agency
Website
www.geant.net
TERENA/GÉANT Association
NORDUnet
SURFnet
Leibniz Supercomputing Centre / DFN
GARR
PSNC
20
2.4.7 Intel® Parallel Computing Center (IPCC)
Intel® Parallel Computing Centers,
as described by Intel, are universities, institutions, and labs that are
leaders in their fields, focusing on
modernising applications to increase
parallelisation efficiency and scalability through optimisations that leverage cores, caches, threads, and vector capabilities of microprocessors and coprocessors of Intel. The
main target architecures for these centres are the Intel MIC (many integrated cores), the Intel Xeon Phi
coprocessor.
The IPCC at LRZ and Technische Universität München (TUM) is geared up to optimise four different
acclaimed applications from different areas of science and engineering: earthquake simulation and seismic wave propagation with SeisSol, simulation of cosmological structure formation using Gadget, the
molecular dynamics code ls1 mardyn developed for applications in chemical engineering, and the software framework SG++ to tackle high-dimensional problems in data mining or financial mathematics (using sparse grids). All these codes have already demonstrated very high scalability on SuperMUC (even
up to petascale), but are in different stages of developement with respect to running on the Intel MIC
architecture. While particularly targeting Xeon Phi coprocessors, the project simultaneously tackles fundamental challenges that are relevant for most supercomputing architectures – such as parallelism on
multiple levels (nodes, cores, hardware threads per core, data parallelism) or compute cores that offer
strong SIMD capabilities with increasing vector width, e.g. Intel Haswell architecture.
Within this project, LRZ contributes on optimising Gadget, a numerical simulation code for cosmological
structure formation, for the Intel Haswell and the MIC architectures. Gadget has already established itself
as a community code and been already scaled efficiently on the entire SuperMUC but Xeon Phi was
basically an “unknown territory”; no MIC version of Gadget existed at the project start. This will bring the
opportunity to sqeeze out best possible performance with such a code from the SuperMUC-Haswell
extension or the SuperMUC successor.
The far-reaching goal is to establish a model process and collection of experiences as well as best
practices for similar codes in the computational sciences. All successful code optimizations and improvements will be integrated in the regular software releases of the four research codes.
Highlights in 2014
Hosted and organised the Intel Xeon Phi Workshop at LRZ for all HPC users in Oct. 2014.
Participated and presented first results in the EMEA IPCC User Forum Meeting in Berlin.
Successfully finished all the scheduled work packages for the first year.
Showcased the outcomes together with other partners to Intel.
Intel Xeon Phi Workshop hosted and organized by LRZ, open to all LRZ users, Oct. 2014
International Supercomputing Conference, ISC 2014, June 2014, Leipzig, Germany
EMEA IPCC User Forum Conference, Berlin, September 2014.
SC'14 LRZ booth, New Orleans, November 2014.
Publications
V. Karakasis, L. Iapichino, N. J. Hammer, A. Karmakar, K. Dolag: First steps towards optimising the
Gadget cosmological simulation code for massively parallel architectures. Poster to be presented at the
International Exascale Applications and Software Conference (EASC 2015), Edinburgh, April 2015.
21
Fast Facts
Project duration
23/07/2014 – 22/07/2016
Leibniz Supercomputing Centre
Intel (funding partner)
Contact person
Astro Lab (astrolab@lists.lrz.de)
Funding agency
Intel Inc.
Website
https://software.intel.com/en-us/ipcc
22
2.4.8 Software-Initiative des KONWIHR
Die Software-Initiative des Kompetenznetzwerks für technisch-wissenschaftliches Hoch- und Höchstleistungsrechnen in Bayern zielt darauf ab,
in enger Zusammenarbeit zwischen Forschungsgruppen und Rechenzentren, die effiziente Nutzung von HPC-Ressourcen durch die Anwendungswissenschaftler zu verbessern. Zudem sollen die Rechenressourcen auch für Forschergruppen ohne fundierte HPC-Kenntnisse
zugänglicher und leichter nutzbar werden. Zur Bearbeitung der einzelnen Projekte arbeitet ein Mitarbeiter der Partnerorganisation zu halber Arbeitszeit am LRZ, wobei aufkommende Probleme in einem wöchentlichen Treffen mit LRZ-Mitarbeitern diskutiert und Lösungsansätze entwickelt werden. In diesem
Jahr werden am LRZ drei Projekte aus den Lebenswissenschaften gefördert.
Projektpartner sind Prof. Rost der TU München und PD Dr. Ege vom Haunerschen Kinderspital des
Klinikum der der Ludwig-Maximilians-Universität München und PD Dr. Gerald Mathias von der LudwigMaximilians-Universität München.
Implementierung hochparalleler Rechenverfahren zur Datenreduktion in der Mikrobiomanalyse
Der Hintergrund dieses KONWIHR-Projekts ist das EU-Projekt HERA (Host-environment interactions in
the protection from asthma and allergies), welches Umwelteinflüsse auf die Herausbildung von Asthmaerkrankungen und Allergien im Kindesalter untersucht. Hierbei wird das Metagenom, also die Gesamtheit der genomischen Information der Mikroorganismen der Kinder, mittels einer DNA-Analyse erhoben
und dessen Einfluss auf die Entstehung von Asthmaerkrankungen untersucht. Die für eine solche Metagenomanalyse notwendigen Programme wurden in der Toolbox QIIME („quantitative insights into
microbial ecology“) zusammengefasst. Das Ziel des Projekts besteht in der Portierung sämtlicher Anwendungen von QIIME auf die Rechenressourcen am LRZ sowie der Anbindung der Rechensysteme
an gängige Workflowtools wie Taverna oder Galaxy.
Implementierung von Workflows aus der Bioinformatikauf auf den Rechensystemen des LRZ am
Beispiel von Sequenzvariantenanalysen
Es sollen Workflows zur Sequenzvariantenanalyse auf den Rechensystemen am LRZ implementiert
werden. Der Fokus liegt dabei auf der Anwendung PredictProteine, die vom Rostlab bereits seit dem
Jahr 1992 als Webservice angeboten wird. Der Webservice legt dabei alle bisher berechneten Ergbenisse in einerm großen Datenarchiv ab. Auf diesem Datenarchiv sollen nun Metaanalysen auf den HPCSystemen des LRZ durchgeführt werden.
Iphigenie
Das dritte Projekt Iphigenie hat die Skalierbarkeit und Last-Balancierung des gleichnamigen MolekularDynamik-Codes zum Ziel. Ebenso wird der Einsatz von Intel Xeon Phi Beschleuniger-Karten evaluiert.
Der Code erlaubt bereits die Kopplung von molekularmechanischen und quantenchemischen Simulationen auf vielen Rechenknoten des SuperMUC.
Highlights in 2014
Kickoff-Meeting, 29.10.2014
Steckbrief
Projektlaufzeit
1.11.2014 – 31.10.2015
Kontaktperson
Kinderklinik und Kinderpoliklinik im
Dr. von Haunerschen Kinderspital
Dr. Christoph Bernau, Dr. Helmut Satzger
Ludwig-Maximilians-Universität München
Förderorganisation
Bayerische Forschungsallianz (Kompetenznetzwerk für technisch-wissenschaftliches Hoch- und
Höchstleistungsrechnen in Bayern)
Website
bayfor.org/konwihr, genomezentral.srv.lrz.de,
www.predictprotein.org
23
24
2.4.9 Mont-Blanc & Mont-Blanc 2
Energy efficiency is already a primary concern for the design of any computer system and it is unanimously recognized that future Exascale systems will be strongly constrained by their power consumption.
Since October 2011, the aim of the European project called Mont-Blanc
has been to design a new type of computer architecture capable of setting
future global HPC standards, built from energy efficient solutions used in
embedded and mobile devices. This project is coordinated by the Barcelona Supercomputing Center
(BSC) and has a budget of over 14 million, including over 8 million Euros funded by the European Commission. Two years later, the European Commission granted additional 8 million Euro funds to extend
the Mont-Blanc project activities in the project Mont-Blanc 2 until September 2016.
This three year extension will enable further development of the OmpSs parallel programming model to
automatically exploit multiple cluster nodes, transparent application check pointing for fault tolerance,
support for ARMv8 64-bit processors, and the initial design of the Mont-Blanc Exascale architecture.
Improving the energy efficiency of future supercomputers is one of LRZ’s main research goals. Also,
Hardware prototyping of novel architectures has proven to be successful for the technology watch preceding the selection of large supercomputers. Yet, advances in hardware are only justified if the need
for programmability and thus the productivity of application development is still satisfied. Therefore,
LRZ’s contribution to Mont-Blanc is twofold: application experts successfully ported BQCD, an application from the field of quantum chromodynamics to the new system and analysed the productivity of the
platform based on ARM processor technology and the OmpSs programming model compared to traditional computer architectures and programming models. On the hardware side, LRZ’s computer architecture experts are responsible for system monitoring. In particular the fine-grained power measurements of the Mont-Blanc system require additional scalability of the system monitoring which the LRZdeveloped monitoring solution provides.
Highlights in 2014
Bring-up the first Mont-Blanc prototype hardware at the Barcelona Supercomputing Centre
Presentation of the project at the two major interanational supercomputing conferences (ISC and SC)
as part of the joint “European Exascale Projects” booth in the exhibition area.
7th Workshop on UnConventional High Performance Computing Keynote, “High Performance Computing on ARM Hardware – The Mont-Blanc Project”, August 26, 2014, Porto, Portugal
Fast Facts
Project duration
1/10/2011 – 30/06/2015 (Mont-Blanc)
1/10/2013 – 30/09/2016 (Mont-Blanc 2)
Bull
ARM
Allinea
Jülich Supercomputing Centre
GENCI
CNRS
CINECA
Barcelona Supercomputing Center
University of Bristol
CEA
INRIA
HLRS
Universidad de Cantabria
Contact person
Axel Auweter
Funding agency
Website
www.montblanc-project.eu
2.4.10
25
Mr. SymBioMath
The project High Performance, Cloud and Symbolic Computing in Big-Data
Problems applied to Mathematical Modeling of Comparative Genomics
(Mr.SymBioMath) links different research domains coming up with a coordinated multi-disciplinary approach for the development of tools targeting BigData and computationally intensive scientific applications. Generic solutions for
Big-Data storage, management, distribution, processing and final analysis will
be developed. While these solutions target a broad range of scientific applications, as a concrete proof-of-concept they will be implemented in the Comparative Genomics field of bioinformatics and biomedical domains.
All of these applications are well suited to apply high-performance and cloud computing approaches and
present a high potential for commercialisation. Visualization techniques for different output devices ranging
from from Virtual Reality environments to mobile devices will be developed to enhance the human understanding of the result data sets.
Publications
Tukora B., C. Anthes, P. Heinzlreiter, D. Kranzlmüller, Large-scale Dynamic Visualization of Multiple Comparative Genomic Data. Poster in: Proceedings of the IEEE Information Visualization Conference (InfoVIs
'14), Paris, France, November 2014
Fast Facts
Project duration
1/02/2013 – 31/1/2017
University of Malaga
RISC Software GmbH
Johannes Kepler University Linz
Integromics S.L.
Servicio Andaluz de Salud – Hospital Carlos Haya
of Spain
Contact person
Dr. Christoph Anthes
Funding agency
European Commission Industry-Academia Partnerships and Pathways (IAPP)
Website
http://www.mrsymbiomath.eu/
26
2.4.11 PRACE Second Implementation Phase Project (PRACE-2IP)
The purpose of the PRACE Research Infrastructure is to provide a sustainable high-quality infrastructure for Europe that can meet the most demanding needs of European HPC user communities through the provision of user
access to the most powerful HPC systems available worldwide at any given
time. In tandem with access to Tier-0 systems, the PRACE project will foster the coordination between national HPC resources (Tier-1 systems) to
best meet the needs of the European HPC user community.
To ensure that European scientific and engineering communities have access to leading edge supercomputers in the future, the PRACE-2IP project evaluates novel architectures, technologies, systems,
and software. Optimizing and scaling of applications for Tier-0 and Tier-1 systems is a core service of
PRACE.
PRACE-2IP is organised in twelve interrelated Work Packages that produce the project results in parallel. To structure the work they are grouped in four pillars: Tier-1 integration, Technology & Industry,
Applications and Training and Dissemination. Actions directly visible to the users of PRACE include
regular training events, scientific conferences and publishing a PRACE magazine focusing on the results
from Tier-0 and Tier-1 projects. A special focus will be on the establishment of PRACE Advanced Training Centres (PATC) in Europe.
With its expertise from previous PRACE projects, LRZ lead WP11 “Prototyping” and the Technology &
Industry Pillar, and contributed to WP2 “Framework for Resource Interchange”, WP6 “European HPC
Infrastructure Operation and Evolution“, WP7 “Scaling Applications for Tier-0 and Tier-1 Users”, and
WP10 “Advancing the Operational Infrastructure” in PRACE 2IP.
Highlights in 2014
During the final project review of the PRACE 2IP project the European Commision attested ‘excellent’ work to WP11.
Publications
Torsten Wilde, Axel Auweter, Michael K. Patterson, Hayk Shoukourian, Herbert Huber, Arndt
Bode,Detlef Labrenz, Carlo Cavazzoni: DWPE, A New Data Center Energy-Efficiency Metric Bridging
the Gap Between Infrastructure and Workload; In Proceedings of 2014 International Conference on High
Performance Computing & Simulation (HPCS 2014), July 2014, p.893 – 901; ISBN: 978-1-4799-5311-0
Hayk Shoukourian, Torsten Wilde, Axel Auweter, Arndt Bode: Monitoring Power Data: A first step towards a unified energy efficiency evaluation toolset for HPC data centers; in Elsevier Environmental
Modelling & Software (Thematic issue on Modelling and evaluating the sustainability of smart solutions), Volume 56, June 2014, Pages 13–26; DOI: http://dx.doi.org/10.1016/j.envsoft.2013.11.011
Fast Facts
Project duration
01/09/2011 – 31/08/2014
Contact person
Torsten Wilde
Funding agency
FZJ – Forschungszentrum Jülich GmbH (Germany, Coordinator)
GCS – Gauss Centre for Supercomputing
(GCS) e.V. (Germany)
GENCI – Grand Equipement National de Calcul Intensif (France)
Website
http://www.prace-ri.eu/prace-2ip/
27
EPSRC – The Engineering and Physical Sciences Research Council (United Kingdom)
BSC – Barcelona Supercomputing Center –
Centro Nacional de Supercomputacion
(Spain)
CSC-Tieteellinen Laskenta OY (Finland)
ETHZ – Eidgenössische Technische Hochschule Zuerich (Switzerland)
NCF – Stichting Nationale Computerfaciliteiten (The Netherlands)
JKU – Johannes Kepler Universitaet Linz
(Austria)
SNIC – Vetenskapsradet (Sweden)
CINECA Consorzio Interuniversitario (Italy)
PSNC – Instytut Chemii Bioorganicznej Pan
WPoznaniu (Poland)
SIGMA – UNINETT AS (Norway)
GRNET – Greek Research and Technology
Network S.A. (Greece)
UC-LCA – Faculdade de Ciencias e Tecnologia da Universidade de Coimbra (Portugal)
NUI Galway – National University of Ireland,Galway (Ireland)
UYBHM – Istanbul Technical University,Ayazaga Campus (Turkey)
CaSToRC – The Cyprus Institute (Cyprus)
NCSA – National Centre for Supercomputing
Applications (Bulgaria)
VSC-TUO – VSB – Technical University of
Ostrava (Czech Republic)
IPB – Institute of Physics Belgrade (Serbia)
NIIF – Nemetzi Informacios Infrasrtuctura
Fejesztese Intezet (Hungary)
28
2.4.12 PRACE Third Implementation Phase Project (PRACE-3IP)
The purpose of the PRACE Research Infrastructure is to provide a sustainable high-quality infrastructure for Europe that can meet the most demanding needs of European HPC user communities through the provision of user access to the most powerful HPC systems available worldwide at any given time. In tandem with access to Tier-0 systems, the
PRACE project will foster the coordination between national HPC resources (Tier-1 systems) to best meet the needs of the European HPC
user community
PRACE-3IP is designed to continue, extend and complement the previous and on-going work in the
implementation phase of the PRACE Research Infrastructure. This involves providing a long-term,
high-quality infrastructure for European Tier-0 systems, managing the coordination between the
shared portion of the national HPC resources (Tier-1 systems), and strengthening the established
relationships with industrial users. PRACE-3IP will add a new key activity to the PRACE RI: the use
of Pre-Commercial Procurement (PCP).The following four activities are central to PRACE-3IP:
•
Pre-Commercial Procurement: Pilot exercise for a joint procurement and joint ownership of
innovative HPC prototypes, focusing on high-energy efficiency.
•
Deployment of HPC services for European industry: Proposes a broad set of services suitable for use by industry, including access to HPC resources, knowledge transfer through application support, training and expertise.
•
Application scaling and support to address major socio-economic challenges: Tackles major socio-economic challenges and the use of simulation and modelling to deal with them.
•
Training and outreach for growth: Establishes broad training and outreach activities specifically designed to engage more user communities, including industry, in the use of HPC systems.
The work of PRACE-3IP and its objectives are structured into eight Work Packages that address the
requirements of the European HPC ecosystemRZ contributed to WP2 “Policies and Procedures”,
WP6 “Operation of the Distributed Research Infrastructure”, and WP7 “Application Enabling and
Support”.
Highlights in 2014
In 2014 the following reports were prepared:
Final Report on Applications Enabling (http://www.prace-ri.eu/IMG/pdf/d7.1.2_3ip.pdf)
Second Annual Technology Report (http://www.prace-ri.eu/IMG/pdf/d6.3.2_3ip.pdf )
Second Annual Operations Report (http://www.prace-ri.eu/IMG/pdf/d6.1.2_3ip.pdf )
Fast Facts
Project duration
01/07/2012 – 31/012015
Contact person
Torsten Wilde
FZJ – Forschungszentrum Jülich GmbH (Germany, Coordinator)
GCS – Gauss Centre for Supercomputing
(GCS) e.V. (Germany)
Funding agency
Website
http://www.prace-ri.eu/prace-3ip/
29
GENCI – Grand Equipement National de Calcul Intensif (France)
EPSRC – The Engineering and Physical Sciences Research Council (United Kingdom)
BSC – Barcelona Supercomputing Center –
Centro Nacional de Supercomputacion
(Spain)
CSC-Tieteellinen Laskenta OY (Finland)
ETHZ – Eidgenössische Technische Hochschule Zuerich (Switzerland)
NCF – Stichting Nationale Computerfaciliteiten (The Netherlands)
JKU – Johannes Kepler Universitaet Linz
(Austria)
SNIC – Vetenskapsradet (Sweden)
CINECA Consorzio Interuniversitario (Italy)
PSNC – Instytut Chemii Bioorganicznej Pan
WPoznaniu (Poland)
SIGMA – UNINETT AS (Norway)
GRNET – Greek Research and Technology
Network S.A. (Greece)
UC-LCA – Faculdade de Ciencias e Tecnologia da Universidade de Coimbra (Portugal)
NUI Galway – National University of Ireland,Galway (Ireland)
UYBHM – Istanbul Technical University,Ayazaga Campus (Turkey)
CaSToRC – The Cyprus Institute (Cyprus)
NCSA – National Centre for Supercomputing
Applications (Bulgaria)
VSC-TUO – VSB – Technical University of
Ostrava (Czech Republic)
IPB – Institute of Physics Belgrade (Serbia)
NIIF – Nemetzi Informacios Infrasrtuctura
Fejesztese Intezet (Hungary)
UCPH – Københavns Universitet (Denmark)
IUCC – Inter University Computation Center
(Israel)
PRACE – Partnership for Advanced Computing in Europe AISBL (Belgium)
ULFME – University of Ljubljana, Faculty of
Mechanical Engineering (Slovenia)
30
2.4.13 Safe And Secure European Routing (SASER)
Der Betrieb komplexer Netzinfrastrukturen, die aus Tausenden einzelner aktiver Netzkomponenten bestehen, ist ohne dedizierte Werkzeuge
für das Netzmanagement undenkbar. Heutige Netzmanagement-Plattformen beschränken sich auf funktionale Eigenschaften der Netzinfrastruktur wie Bandbreitenmanagement, Hardware-Störungslokalisierung
und Netzkomponenten-Konfiguration. Eine dedizierte Behandlung von
Sicherheitseigenschaften, wie sie im Rahmen von SASER möglich wird,
kann mit bestehender Netzmanagement-Software nicht erreicht werden.
In dem vom Leibniz-Rechenzentrum bearbeiteten Teilprojekt von SASER sollen deshalb Konzepte und
Implementierungen erarbeitet werden, um bestehende Netzmanagement-Plattformen an die durch
SASER geschaffene, sicherheitsorientierte Netzinfrastruktur anzupassen. Die konkreten Themenbereiche umfassen:
•
•
•
Erweiterung der technischen Schnittstellen zwischen zentralen Netzmanagement-Plattformen
und Netzkomponenten um das Monitoring und die Steuerung von Sicherheitsparametern.
Konzepte und Algorithmen für die dynamische Steuerung dieser Sicherheitsparameter unter Berücksichtigung der ermittelten aktuellen Bedrohungslage und der zu erreichenden Zielsetzungen.
Erfassung von sicherheitsrelevanten Kennzahlen und Aufbereiten der aktuellen Sicherheitslage
zu Sicherheitsberichten.
Highlights in 2014
Im Jahr 2014 wurden das Teilprojekt TP-2 („Umsetzung der dynamischen Steuerungsalgorithmen“) erfolgreich abgeschlossen und das Teilprojekt TP-3 („Security-Monitoring und Security-Reporting“) gestartet. TP-2 umfasst die Unterstützung sicherheitsspezifischer Randbedingungen bei der dynamischen
Steuerung von Netzinfrastrukturen im praktischen Betrieb; hierzu gehört zum einen die Korrelation von
klassischen Netzmanagement-Events (z.B. Ausfälle von Komponenten, Bandbreitenengpässe, weitere
Quality-of-Service-Verletzungen usw.) mit Sicherheitsmeldungen aus zusätzlichen Quellen, beispielsweise den von Intrusion Detection Systemen gelieferten Informationen über mit einer gewissen Wahrscheinlichkeit zuverlässig erkannte Angriffe. Zum anderen müssen Zielvorgaben berücksichtigt werden,
die sich beispielsweise aus Verträgen zwischen Netzbetreiber und Kunden (Service Level Agreements),
in die neben herkömmlichen Quality-of-Service-Parametern wie Bandbreiten-Garantien und Maximallatenzzeiten auch neue, sicherheitsspezifische Parameter aufgenommen wurden.
In Rahmen der Vorbereitung der Live-Demonstration zum SASER-Mid-Term-Review wurden einige weitere funktionale Anforderungen identifiziert und Schnittstellenabsprachen getroffen, die erfolgreich implementiert werden konnten. Darunter fallen insbesondere Managementfunktionen, wie beispielsweise
das manuelle Erzeugen, Umbenennen und Einsortieren weiterer Netzelemente. Weiterhin wurde die
Integration von Security-Meldungen vorangetrieben. In TP-1 wurde definiert, dass Sicherheitsmeldungen im standardisierten XML-Format IDMEF vorliegen sollen. Um solche Security-Meldungen nutzbar
zu machen und den Administratoren grafisch aufbereitet anzuzeigen, wurde eine IDMEF-Unterstützung
entwickelt. Dies ermöglicht Administratoren, Zusammenhänge zwischen Netzverkehranomalien und
Security-Events zu erkennen, um geeignet darauf reagieren zu können, da viele Security-Events Auswirkungen auf die klassischen Kennzahlen des Netzmanagements (wie beispielsweise Bandbreite oder
Datendurchsatz) haben; umgekehrt haben aber auch Netzprobleme oftmals Einfluss auf das Sicherheitsziel „Verfügbarkeit“. Ein Proof-of-Concept der implementierten Konzepte konnte in der Live-Demo
(Demo 5) im Rahmen des SASER-Mid-Term-Reviews präsentiert werden. Das Feedback zum Demonstrator war durchwegs positiv und konstruktiv.
TP-3 umfasst das Monitoring und Reporting von Security-Events, wobei es wichtig ist, dass die Informationen nutzbar für die Administratoren aufbereitet werden, was insbesondere Trendanalysen, Visualisierungen und Schaubilder umfasst. In diesem Teilprojekt wurde intensiv mit der TU München und der FH
Potsdam zusammengearbeitet; gegen Ende 2014 wurde damit begonnen, eine enge Zusammenarbeit
mit den finnischen Partnern von VTT zu etablieren, welche in einen gemeinsamen Demonstrator fließen
soll. Bei der Kooperation mit der FH Potsdam und der TU München wurde initial festgelegt, dass im
besonderen Fokus Amplification Attacken stehen sollen, da diese sowohl auf die Sicherheit als auch auf
die Stabilität der Netze großen Einfluss haben können. Daher wurden zum einen Konzepte entwickelt,
mit denen man zuverlässig Amplification Angriffe erkennen kann. Die Ergebnisse dieser Arbeiten werden
31
2015 auf zwei wissenschaftlichen Konferenzen vorgestellt. Zum anderen mussten Visualisierungen konzipiert werden, die dazu beitragen, die Erkennung durch die zuständigen Administratoren zu verbessern
oder erst zu ermöglichen.
Workshop: „Software Defined Networking – Wie SDN die Welt verändern wird“, 22.01.2014, München
21. DFN Workshop „Sicherheit in vernetzten Systemen“, 18.–19.02.2014, Hamburg (eigener Vortrag;
Titel: Security Knowledge Management auf Basis einer Dokumentenvorlage für Sicherheitskonzepte)
Workshop Trusted Cloud, 02.–03.06.2014, Berlin
7. DFN-Forum Kommunikationstechnologien, 16.–17.06.2014, Hamburg (eigener Vortrag; Titel: Herausforderungen und Anforderungen für ein organisationsweites Notfall-Passwortmanagement)
SASER Mid-Term-Review, 24.–25.06.2014, Berlin (projektintern)
SASER Data Visualization Workshop, 03.09.2014, Potsdam (projektintern)
CELTIC-Plus Flagship Preparation Meeting, 07.–08.10.2014, Stuttgart
Planungstreffen für eine finnisch-deutsche SASER-Demo, 26.–28.11.2014, Oulu, Finnland (projektintern)
Eigene Publikationen
Hommel, Wolfgang, Stefan Metzger, Daniela Pöhn und Felix von Eye: Improving higher education network security by automating scan result evaluation with Dr. Portscan. In: Sukovskis, Uldis (Herausgeber):
ICT Role for Next Generation Universities, EUNIS 2014 – 20th EUNIS Congress, Umea, Schweden, Juni
2014.
Hommel, Wolfgang, Stefan Metzger, Helmut Reiser und Felix von Eye: Security Knowledge Management auf Basis einer Dokumentenvorlage für Sicherheitskonzepte. In: Paulsen, Christian (Herausgeber):
Sicherheit in vernetzten Systemen: 21. DFN Workshop, Seiten B-1–B-19, Norderstedt, Deutschland,
Januar 2014. Books on Demand.
von Eye, Felix, Wolfgang Hommel und Helmut Reiser: Herausforderungen und Anforderungen für ein
organisationsweites Notfall-Passwortmanagement. In: Müller, Paul, Bernhard Neumair, Helmut Reiser
und Gabi Dreo Rodosek (Herausgeber): 7. DFN-Forum Kommunikationstechnologien – Beiträge der
Fachtagung, Nummer 231 in GI-Edition – Lecture Notes in Informatics (LNI): Proceedings, Seiten 109–
119, Bonn, Deutschland, Juni 2014. Gesellschaft für Informatik.
von Eye, Felix, Wolfgang Hommel und David Schmitz: A Secure Logging Framework with Focus on
Compliance. In: Savola, Reijo (Herausgeber): International Journal on Advances in Security, Band 7,
Seiten 37–49. IARIA, Dezember 2014. URL: http://www.iariajounals.org/security/sec_v7_n34_2014_
paged.pdf.
Betreute Abschlussarbeiten
Böttger, Timm: Detection of Amplification Attacks in Amplifier Networks. Masterarbeit, Technische Universität München, München, Mai 2014.
Bernhard, Andreas: Netzbasierte Erkennung von Systemen und Diensten zur Verbesserung der IT–Sicherheit. Bachelorarbeit, Ludwig–Maximilians–Universität, München, März 2014.
Bosh, Zoya: Evaluation von Open–Source–Werkzeugen zum Management von Sicherheitsdokumenten.
Bachelorarbeit, Ludwig–Maximilians–Universität, München, Mai 2014.
Peschel, Michael: Webbasiertes Management von Sicherheitskonzepten. Bachelorarbeit, Ludwig–Maximilians–Universität München, München, Juli 2014.
Söhner, Manuel: Privileged User Password Management in Shared Environments. Masterarbeit, Technische Universität München, München, April 2014.
Scherf, Achim: Sicherheitsrisiken durch Spionage ausländischer Nachrichtendienste. Masterarbeit, Ludwig–Maximilians–Universität, München, August 2014.
Simon, Christian: Härtungs– und Sicherheitskonzepte für Web– und Applikationsserver. Masterarbeit,
Ludwig–Maximilians–Universität, München, März 2014.
Tarabai, Omar: A Penetration Testing Framework for the Munich Scientific Network. Interdisziplinäres
Projekt, Technische Universität München, München, Januar 2014.
Wörner, André: Konzeption und Implementierung eines Webfrontends für die mandantenfähige Konfiguration eines Delta–Reporting Portscan–Werkzeugs. Bachelorarbeit, Ludwig–Maximilians–Universität,
München, April 2014.
32
Steckbrief
Projektlaufzeit
01.08.2012 – 31.07.2015
Nokia Solutions and Networks Management International GmbH
Coriant R&D GmbH
Technische Universität Berlin
Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften
Fraunhofer Gesellschaft HHI
Ruhr Universität Bochum
Zuse Institut Berlin (ZIB)
Technische Universität Braunschweig
Universität Tübingen
Universität Würzburg
FH Potsdam, IxDS GmbH
Fraunhofer AISEC
Technische Universität Dortmund
Kontaktperson
Felix von Eye
Förderorganisation
Bundesministerium für Bildung und Forschung
Website
www.saser.eu
33
2.4.14 Simulation und Optimierung des Energiekreislaufs von Rechenzentrums-Klimatisierungsnetzen unter Berücksichtigung von Supercomputer-Betriebsszenarien (SIMOPEK)
Die Reduzierung des Energieverbrauches und die
Wiederverwendung von Abwärme sind heute wichtige
Themen bei der Konzeption und dem Betrieb von großen
Rechenzentren. Das Hauptziel des vom BMBF
geförderten Vorhabens SIMOPEK ist die ganzheitliche
Betrachtung und Optimierung der Energieeffizienz von
Höchstleistungsrechenzentren.
Erstmalig sollen Methoden und Softwarekomponenten zur Modellierung und Simulation aller
Energiekreisläufe eines Rechenzentrums entwickelt werden, die sowohl ein hochdynamisches
Lastverhalten der Verbraucher als auch neue technische Komponenten und Konzepte zur
Wiederverwertung der erzeugten Abwärme berücksichtigen.
Als konkreter Demonstrator wird im Projekt das Leibniz-Rechenzentrum, genauer die beiden
Höchstleistungsrechner SuperMUC und CooLMUC betrachtet. Diese werden mit "High Temperature
Liquid Cooling" (HTLC) betrieben. Der entsprechende Energiekreislauf wird im Detail untersucht und
optimiert. Im Projekt wird so zum ersten Mal ein Rechenzentrum ganzheitlich betrachtet, nämlich als
Einheit aus seiner Infrastruktur, externen Einflussfaktoren, Rechenzentrumszielen, Betriebsszenarien
und Rechnerverhalten. Einsparungen in Höhe mehrerer Millionen Euro über Fünfjahreszeiträume
(Rechnerlebenszeit) scheinen in der Praxis möglich.
Konzepte zur Übertragbarkeit von Projektergebnissen auf andere Rechenzentren (beispielsweise der
Gauss-Allianz) werden im Projekt gemeinsam erarbeitet. Zudem ist geplant, Weiterentwicklungen von
SIMOPEK auch für die Planung neuer Rechenzentren einzusetzen, wobei insbesondere eine
Berücksichtigung von variablem Lastverhalten der Hochleistungsrechner, von verschiedenen
Kühlungstechnologien sowie von innovativen Konzepten zur Abwärmenutzung ermöglicht werden soll.
Eine Ausweitung auf weitere Anwendungen im Energiemanagement ist ebenfalls geplant. Für eine Reihe
der im Projekt entwickelten Module soll der Quelltext öffentlich zugänglich gemacht werden.
Highlights in 2014
SIMOPEK Workshop, ISC'14, 2014-06-23, Leipzig
Publikationen
Hayk Shoukourian, Torsten Wilde, Axel Auweter, Arndt Bode: Monitoring Power Data: A first step towards a unified energy efficiency evaluation toolset for HPC data centers; published by Elsevier in: Environmental Modelling & Software (Thematic issue on Modelling and evaluating the sustainability of
smart solutions), Volume 56, June 2014, Pages 13–26; DOI: http://dx.doi.org/10.1016/j.envsoft.2013.11.011
Hayk Shoukourian, Torsten Wilde, Axel Auweter, Arndt Bode: Predicting the Energy and Power Consumption of Strong and Weak Scaling HPC Applications; published in Supercomputing frontiers and
innova-tions (an international journal): Vol 1, No 2 (2014), p.20 –41, open access (http://superfri.org/superfri/article/view/9/8)
Torsten Wilde, Axel Auweter, Michael K. Patterson, Hayk Shoukourian, Herbert Huber, Arndt Bode,
Detlef Labrenz, Carlo Cavazzoni: DWPE, a new data center energy-efﬁciency metric bridging the gap
between infrastructure and workload; published by IEEE in: Proceedings of 2014 International Conference on High Performance Computing & Simulation (HPCS 2014), July 2014, p.893 – 901; ISBN: 9781-4799-5311-0
34
Steckbrief
Projektlaufzeit
1.7.2013 – 30.6.2016
Fraunhofer SCAI
SorTech AG
Kontaktperson
Torsten Wilde
Förderorganisation
Bundesministerium für Bildung und Forschung
(BMBF)
Website
www.simopek.de
35
2.4.15 Virtuelles Alpen-Observatorium II (VAO-II)
Auf Initiative der Umweltforschungsstation Schneefernerhaus (UFS) auf der Zugspitze bündelt das Netzwerk „Virtuelles Alpenobservatorium“ (VAO) die Forschungsaktivitäten der alpinen Höhenforschungsstationen in Italien, Frankreich,
der Schweiz, Österreich, Norwegen und Deutschland. Der Einfluss des Klimawandels auf die sensible Alpenregion spielt bei den Forschungen eine zentrale Rolle.
Die Untersuchung geophysikalischer und chemischer Prozesse unter den aufgrund der exponierten Lage für qualitativ hochwertige Messungen hervorragenden
Bedingungen trägt dazu bei, die vielfältigen Vorgänge im Erdsystem besser zu
verstehen.
Das LRZ entwickelt im Rahmen des Alpenobservatoriums/VAO-II zusammen mit dem DLR, der UFS
und der Universität Augsburg das "Alpen-Datenanalysezentrum" (Alpen-DAZ), in dem die Daten der
internationalen Klimaforschungsstationen gesammelt und analysiert werden. Auf der Grundlage des bestehenden Datenanalysezentrums auf der UFS wird eine moderne und innovative informationstechnische Architektur zur Vernetzung mit anderen Forschungsinstituten, zur Datenarchivierung und zum
Computing on Demand (CoD) für die Simulationsrechnung entwickelt.
Highlights in 2014
Aufgrund von verwaltungstechnischen Hürden konnte das Projekt nur mit Verzögerung starten. So fand
zwar im März unter internationaler Beteiligung das Kickoff-Treffen in Freising statt, der offizielle Beginn
des Alpen-DAZ-Teilprojekts war aber erst im August, die Aufnahme der Arbeiten sogar erst im Dezember
möglich.
VAO-II Kickoff, 5.-6. März, Kardinal-Döpfner-Haus, Freising
Steckbrief
Projektlaufzeit
1.8.2014 – 31.9.2017
Umweltforschungsstation Schneefernerhaus
Umweltbundesamt
Helmholtzzentrum für Gesundheit und Umwelt
Karlsruher Institut für Technologie
Bayerisches Landesamt für Umwelt
Universität Augsburg
Deutsche Gesellschaft für Luft- und Raumfahrt
Kontaktperson
Dr. Anton Frank
Förderorganisation
Bayerisches Staatsministerium für Umwelt und
Verbraucherschutz
Website
www.schneefernerhaus.de/station/virtuelles-alpenobservatorium/internationale-vernetzung.html
36
2.4.16 Virtual Earthquake and Seismology Research Community in
Europe e-Science Environment (VERCE)
VERCE is developing an e-science environment for data-intensive
seismic applications to enable innovative data analysis and data
modelling methods that fully exploit the increasing wealth of open
data generated by the observational and monitoring systems of the
global seismology community. The VERCE environment builds
upon a service-oriented architecture and a data-intensive platform delivering services, workflow tools,
and software as a service to integrate the distributed European public data and computing infrastructures
(HPC, grid and cloud) with private resources and the European integrated data archives of the seismology community.
The LRZ is leading WP2 “Integration and evaluation of the platform services”, which has the curial role
of quality assessing and testing of software modules to be integrated into the platform. WP2 is performing
regular release cycles with a fixed frequency of six months to ensure that only fully functional and compatible software is integrated into the VERCE e-science environment.
Highlights in 2014
In June the 3rd review meeting took place at the LRZ. All project partners, the reviewers as well as a
representative of the EC joined here to review the current status of the project and discussed further
steps for the coming months. In addition, LRZ supported the VERCE project with their supercomputing
and visualization facilities and thus enabled the project to perform a live demonstration of preparing,
performing, and visualizing a seismological simulation using the VERCE e-science environment.
VERCE also conducted successfully two web-training sessions in July where LRZ was actively involved
in both, the frontend and backend. An introduction to the resources hosted at LRZ and our in-house tools
and services were given. LRZ’s excellent background support and supercomputing facilities from both
the DRG and HPC groups were paramount to the success of the training.
•
2-4 April, ICRI Conference, Athens, Greece
o A. Frank
o OTHER: VERCE's official poster for dissemination
•
27 April - 02 May 2014, EGU, Vienna, Austria
o S.H.Leong, A. Frank
o OTHER: EGU2014: A data management system to enable urgent natural disaster
computing
•
7-9 May 2014, SCI-BUS Meeting, Cesme, Turkey
o S.H. Leong, A. Spinuso, M. Atkinson
o PRES: Technical: Science Gateway & wish list (Leong)
•
19-23 May 2014, EGI Community Forum, Helsinki, Finland
o S.H.Leong, A.Frank
Publications
S. H. Leong, D. Kranzlmüller, and A. Frank. A data management system to enable urgent natural disaster computing. In EGU General Assembly Conference Abstracts, volume 16 of EGU General Assembly
Conference Abstracts, page 4699, May 2014.
A. Spinuso, A. Krause, C.R. Garcia, E. Casarotti, F. Magnoni, I.A. Klampanos, L. Frobert, L. Krischer, L.
Trani, M. David, S.H. Leong and V. Muraleedharan, The VERCE Science Gateway: enabling user
friendly seismic waves simulations across European HPC infrastructures. In EGU General Assembly
Conference Abstracts, volume 16 of EGU General Assembly Conference Abstracts, May 2014
37
A. Spinuso, A. Krause, C.R. Garcia, E. Casarotti, F. Magnoni, J. Matser, L. Krischer, L. Trani, M. David, S.H. Leong and V. Muraleedharan, THE VERCE SCIENCE GATEWAY: INTERACTIVE FORWARD
MODELING AND METADATA MANAGEMENT. In Second European Conference on Earthquake Engineering and Seismology (2ECEES), August 2014.
Fast Facts
Project duration
1/10/2011 – 31/9/2015
Institut de Physique du Globe de Paris
Université Joseph Fourier de Grenoble
The University of Edinburgh
Koninklijk Nederlands Meteorologisch Instituut
Euro-Mediterranean Seismological Centre
Istituto Nazionale di Geofisica e Vulcanologia
The University of Liverpool
Fraunhofer-Institut für Algorithmen und Wissenschaftliches Rechnen
Consorzio Interuniversitario Cineca
Contact person
Dr. Anton Frank
Funding agency
European Commission
Website
www.verce.eu
38
2.4.17 Webbasiertes Customer Network Management (WebCNM)
Customer Network Management (CNM) bezeichnet allgemein die kontrollierte Weitergabe von Managementinformationen durch den Anbieter eines Kommunikationsdienstes an die Dienstnehmer sowie das
Bereitstellen von Interaktionsschnittstellen zwischen Dienstnehmer und Diensterbringer. CNM ermö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.
Im X-WiN (Deutsches Forschungsnetz) wird mittels dieses Konzepts seit 2002 den DFN-Anwendern
(Hochschulen und Forschungseinrichtungen Deutschlandweit) der Zugriff auf IP-Dienst-Abrechnungsdaten und eine Übersicht der Topologie- sowie deren Status- und Kennzahlinformationen angeboten.
Die bisherige Architektur des CNM, die insbesondere im X-WIN seit 2002 eingesetzt wird, basierte auf
C++/Java/CORBA. Im Rahmen dieses Projektes wurde ein im vorrangegangenen GN3-Projekt entwickelter Prototyp des CNM-Systems mit einer webbasierten Client/Server-Architektur, das sogenannte
WebCNM, so angepasst und mit allen bis dahin fehlenden allgemeinen und X-WiN-spezifischen Funktionen erweitert, dass er in Zukunft das alte CNM-System für das X-WiN voll ersetzen kann.
Desweiteren wurde die komplette operative und datenmäßige Administration, die Kundenbetreuung und
alle anderen Aufgaben, die seit 2002 hierbei vom LRZ erledigt wurden, an die DFN-Geschäftsstelle
Stuttgart übergeben.
Ereignisse 2014
Die 2013 begonnene Anpassung des in GN3 entwickelten WebCNM wurden sowohl bezüglich X-WiNspezifischer Funktionalitäten wie z.B. User-Autorisierung- und IP-Dienst-Unterstützung als auch bezüglich generischer Funktionalitäten, die für den Einsatz im X-WIN noch fehlten, fortgesetzt: Wesentliche
hinzugefügte generische Funktionalitäten sind die Unterstützung von Status-Events, sowohl SNMP-Interface-Status als auch die experimentelle Integration des X-WiN-DiData-Trouble-Ticketsystems, die Korelation, Anzeige und Filterung von und nach Statuswerten im Kartenbaum, die gleichzeitige Anzeige
von aktuellen oder historischen Knotenmetriken, Linkmetriken und Status für Knoten und Links.
Weiter wurden sowohl die vom WebCNM-Client aus intern steuerbaren als auch die externen, d.h. rein
CLI-basierten, Verwaltungs- und Managementschnittstellen im CNM-Backend vom CORBA-Backend
auf das WebCNM-Backend portiert, sowie erweitert: So sind nun z.B. einerseits im Admin-Editor des
WebCNM-Clients sowohl herkömmliche Datenbank-basierte als auch Dotfile-basierte Karten einheitlich
verwaltbar, andererseits wurde im Backend ein generischer Perl-intern als auch von der CLI aus nutzbares Objekt-Framework für die Verwaltung der Topologie und Karten entwickelt, das somit das alte
CORBA-Object-Framework nahtlos ersetzt und ablöst.
Zuletzt wurde ein CNM-Server, der nur WebCNM beinhaltet - bezogen sowohl auf Nutzer- als auch auf
Managementfunktionalität, auf einer neuen virtuellen Maschine bei der DFN-Geschäftstelle Stuttgart eingerichtet. Dieser ersetzt ab 01.12.2014 das bisherige am LRZ gehostete Java-CNM und wird direkt von
der DFN-Geschäftstelle Stuttgart kunden- und datentechnisch betreut und gemanagt.
60. DFN-Betriebstagung, März 2014, Berlin
Steckbrief
Projektlaufzeit
04/2013 – 12/2014
DFN-Verein Berlin
Kontakt
Dr. David Schmitz
39
Fördergeber
Deutsches Forschungsnetz DFN
Website
http://www.cnm.dfn.de
2.4.18
Standardisierungsaktivitäten im Bereich der parallelen Programmierung
Unter Beteiligung des LRZ wurde eine technische Spezifikation (ISO/IEC TS 18508) für zusätzliche parallele Semantik der Programmiersprache FORTRAN im Laufe des Jahres weiter vorangetrieben. Die Erweiterungen zielen darauf ab, den Programmierer bei der effizienten Nutzung moderner Parallelrechner
mit typischerweise stark hierarchischer und/oder heterogener Struktur besser zu unterstützen.
2.5 Mitarbeit in Initiativen zur Förderung und Weiterentwicklung
von HPC-Technologien in Europa
2.5.1 ETP4HPC
Das LRZ ist Gründungsmitglied der European Technology Platform for High Performance Computing
(ETP4HPC). Ziel der ETP4HPC ist es, sowohl die Anwendung als auch die Herstellung von HPC-Technologien in Europa zu fördern.
Ende Februar wurde mit der europäischen Kommission ein contractual Public Private Partnership (cPPP) – Vertrag zur gemeinsamen Förderung von neuen HPC-Technologien, der Paneuropäischen HPC-Infrastruktur sowie zur Förderung von HPC-Anwendungen in Industrie und
Wissenschaft abgeschlossen. Weitere wichtige Aktivitäten der ETP4HPC im Berichtsjahr waren:
• Die Erstellung und Einreichung eines EU-Antrages zur Koordination und Unterstützung
der cPPP-Aktivitäten
• Die Erstellung eines Positionspapiers zum H2020-Förderprogramm in den Jahren 2016
und 2017
• Arbeiten zur Aktualisierung der Strategic Research Agenda (SRA)
2.5.2 PROSPECT e.V.
Das LRZ ist gemeinsam mit dem FZ Jülich und dem Barcelona Supercomputing Center Gründungsmitglied
von PROSPECT e.V. und im Vorstand vertreten (Prof. Bode). PROSPECT dient der Förderung von HPCTechnologien durch W issenschaft und W irtschaft. Der Fokus der Arbeiten lag in 2014 auf den Themen
datenintensive Anwendungen in der Wissenschaft und aktuelle Entwicklungen im internationalen HPCÖkosystem.
40
Darstellung des LRZ in der Öffentlichkeit
3 Darstellung des LRZ in der Öffentlichkeit
3.1 Allgemeine Öffentlichkeit und Medien - PR
Die öffentlich wahrnehmbaren Höhepunkte am LRZ betrafen im Jahr 2014 vor allem neue Spitzenleistungen auf dem Höchstleistungsrechner SuperMUC. Es gelang erstmals, über längere Zeit eine Erdbebensimulation mit mehr als einem Petaflops zu rechnen. Diese Leistung wurde in der HPC-Welt gewürdigt und
für den Gordon-Bell-Preis vorgeschlagen. Die entsprechende wissenschaftliche Veröffentlichung war dann
„Gordon Bell Finalist“, konnte den ersten Platz aber leider nicht erzielen. Im November erschien die Wissenschaftszeitschrift „Science“ mit einem Titelbild zu einer Publikation über Insektengenome, deren
Stammbaum von insgesamt 200 Wissenschaftlern genauer entschlüsselt werden konnte. Auch hierfür waren die Simulationen auf dem SuperMUC eine notwendige Voraussetzung. Beide Ergebnisse wurden mit
Pressemitteilungen bekannt gemacht und führten zu weiteren Veröffentlichungen in den Medien. Die BR
Rundschau und das BR Rundschau Magazin berichteten ausführlich über die Erforschung des Insektenstammbaums. Dem BR-Redakteur Christoph Arnowski waren LRZ und SuperMUC bereits von seinem Bericht anlässlich der Inbetriebnahme 2012 bekannt. Hier zahlt sich die konstant positive Wahrnehmung des
LRZ in den Medien und der Öffentlichkeit aus. Auch in der Süddeutschen Zeitung und im Münchner Merkur
wurden Artikel und Interviews mit dem Leiter des LRZ veröffentlicht.
Die hervorragenden Ergebnisse, die mit dem SuperMUC erzielt wurden, sowie seine weltweit vorbildliche
Energieeffizienz waren auch Themen für internationale Medien. Valéry Marchive von LeMagIT/TechTarget
und Robert Roe von Scientific Computing World besuchten das LRZ und ließen sich von seinem Leiter
über SuperMUC und Energiethemen informieren.
LRZ und SuperMUC werden auch gern als Hintergrund zur Erläuterung wissenschaftlicher Themen genutzt, so vom Bayerischen Rundfunk für ein Interview mit Prof. Mainzer, TU München, für einen Beitrag
über Robotik und Künstliche Intelligenz und vom Auswärtigen Amt für Aufnahmen mit Prof. Knoll, TU München, über Neurorobotics im Human Brain Project.
Abbildung 10: Stand des LRZ bei den Münchner Wissenschaftstagen
41
Am LRZ selbst fand am 11. Oktober der Tag der offenen Tür gemeinsam mit dem Campus Garching der
TU München statt, den wieder weit über eintausend Besucher nutzten, das LRZ und sein V2C kennen zu
lernen. Am V2C fand am 16. Dezember der „Open Lab Day“ statt.
Am 9. Oktober konnte das LRZ seine Dienstleistungen für Studenten bei der Erstsemesterbegrüßung der
LMU mit einem Infostand vorstellen.
Das LRZ beteiligte sich in diesem Jahr an den Münchner Wissenschaftstagen vom 8. bis 11. November
mit einem eigenen „Marktstand der Wissenschaft“ und führte eine „Force-Feedback-MolekulardynamikSimulation“ vor, bei der die Besucher mit eigenen Händen die Kraft der Moleküle spüren konnten.
3.2
Hochleistungsrechnen
3.2.1 Supercomputing Konferenzen
Das LRZ hat sich wieder auf den Supercomputing-Konferenzen ISC14 in Leipzig und SC14 in New Orleans
präsentiert. Auf der ISC14 in Leipzig traten die drei Gauss-Mitgliedszentren mit einem gemeinsamen Stand
auf. Das LRZ hat für beide Konferenzen neue Videoanimationen erstellt. Darin werden neben dem GCS
und den beteiligten Zentren insbesondere auch wissenschaftliche Projektaktivitäten auf den Rechnern des
LRZ vorgestellt. Schwerpunkte dieser wissenschaftlichen Projekte lagen in den Bereichen Astrophysik,
Geophysik und Lebenswissenschaften.
Das LRZ war ebenfalls mit einem eigenen Stand auf den Münchner Wissenschaftstagen präsent, einer
viertägigen Großveranstaltung mit dem Ziel, wissenschaftliche und technische Themen auf allgemeinverständliche Weise einem breiten Publikum zu vermitteln. Die Besucher hatten dabei die einzigartige Möglichkeit, über einen 3D-Monitor live mit einer Molekül-Simulation zu interagieren und die dabei entstehenden Kräfte mittels eines Force-Feedback-Sensors direkt zu spüren.
3.2.2 SuperMUC Status and Results Workshop, User Forum und
Berichtsband
Während der ersten zwei Betriebsjahre konnten mit SuperMUC bereits eine sehr große Menge von Ergebnissen erzielt werden. Mehr als 100 Projekte reichten Berichte für den SuperMUC-Berichtsband ein, der im
Juni zur International Supercomputing Conference ISC14 in Leipzig veröffentlicht wurde. Hiervon wurden
28 Projekte ausgewählt, ihre Ergebnisse auf dem SuperMUC Status and Results Workshop am 8. und
9. Juli 2014 zu präsentieren. Dabei wurde bewusst auf eine Gruppierung der Vorträge in thematischen
Blöcken verzichtet, so dass ein Austausch von Informationen über die Fachgebietsgrenzen hinweg stattfinden konnte.
High Performance Computing in Science und Engineering –
Garching/Munich 2014 (2014)
Editors: S. Wagner, A. Bode, H. Satzger, and M. Brehm
ISBN: 978-3-9816675-0-9
Der Berichtsband ist auch als PDF und E-Book verfügbar: Siehe
www.lrz.de/services/compute/supermuc/magazinesbooks
Abbildung 11: Einband des Berichtsbandes 2014
42
Die Teilnehmer beteiligten sich mit großem Interesse an den Diskussionen der einzelnen Vorträge und
insbesondere auch im User Forum. Die Benutzer erhielten hier die Gelegenheit, ihre Anforderungen und
Vorschläge für den weiteren Betrieb des SuperMUC und auch für zukünftige Rechensysteme mit den Verantwortlichen am LRZ zu diskutieren. Während des gesamten Workshops konnten die Benutzer direkt mit
System Administratoren und Applikationsexperten von IBM, Intel und LRZ interagieren. Das LRZ informierte im Rahmen des Workshops auch über die Pläne für SuperMUC Phase 2. Außerdem wurden die
neue Insel “SuperMIC” mit Intel Xeon Phi Beschleunigerkarten sowie das neue Remote-Visualisierungscluster vorgestellt.
Eine Übersicht über die Vorträge des Workshops sowie die Folien ausgewählter Vorträge sind verfügbar
unter http://www.lrz.de/services/compute/supermuc/magazinesbooks/supermuc_results_2014/ .
3.2.3 Ergebnisse auf GCS Webseiten
Zusätzlich zu dem Berichtsband werden die Ergebnisse von am SuperMUC durchgeführten Projekten auch
auf den Seiten des Gauß-Zentrums www.gauss-centre.eu dargestellt.
Abbildung 12: Webseiten des Gauß-Zentrums mit Ergebnissen von Projekten am SuperMUC
3.3 Zentrum für Virtuelle Realität und Visualisierung (V2C)
2014 wurden mehrere Vorträge über die Forschungsergebnisse am V2C gehalten. Es fanden einige öffentliche Veranstaltungen, auch außerhalb des V2C, an denen am LRZ erstellte Projekte auf V2C Hardware
präsentiert wurden, statt. Insgesamt wurde über 2.500 Gästen und Anwendern an über 300 Terminen die
Möglichkeit gegeben, das V2C zu besuchen.
3.3.1
Vorträge
Im Rahmen von Fachvorträgen auf internationalen Tagungen in Vietnam, Frankreich und Schottland wurde
das V2C sowie verschiedenste Forschungsergebnisse vorgestellt.
3.3.2 Veranstaltungen
Das LRZ war mit dem Schwerpunkt V2C Gastgeber bei mehreren Veranstaltungen.
43
In Zusammenarbeit mit der CAD-Stelle des Staatlichen Bauamts München 2 (StBaM2) wurden VR Umsetzungen von Entwürfen und Planungen mit Architekten und Entscheidungsträgern im V2C diskutiert.
Das Zwischenreview des Projekts VERCE, welches sich mit Simulationen im Bereich der Seismologie beschäftigt, wurde am LRZ abgehalten. In einem gesonderten Zeitfenster der Veranstaltung war es Teilnehmern des Projekts und den Gutachtern möglich, Ausschnitte des Ablaufs von der Simulation bis hin zur VR
Visualisierung im V2C zu beobachten.
Im Rahmen des EU Projektes MrSymBioMath fand im September eine Summer School mit 30 Teilnehmern
statt. Das Thema der Summer School war Maschinelles Lernen und Visualisierung. Viele Expertenvorträge
brachten die Themengebiete fokussiert auf das Anwendungsgebiet der Bioinformatik dem interessierten
Publikum näher.
Im Dezember hatten die Studierenden der Lehrveranstaltung Virtual Reality die Möglichkeit, ihre in der
Lehrveranstaltung erstellen Projekte am Open Lab Day der Öffentlichkeit zu präsentieren. Das LRZ konnte
über 100 Gäste begrüßen. Die Süddeutsche Zeitung berichtete.
Abbildung 13: Studierende präsentieren ihre Projekte am Open Lab Day
Das V2C beteiligte sich auch an Veranstaltungen außerhalb der gewohnten Räumlichkeiten.
Abbildung 14: Präsentation einer Gletschervisualisierung am Akademientag in der BAdW
44
Das gemeinsame Projekt „senseparation“ des Studiengangs Kunst und Multimedia der LMU, Interface Culture der Universität für Gestaltung (UfG), Linz, Österreich und des LRZ beschäftigt sich mit separierter
Sinneswahrnehmung. Ein dunkler Raum mit Audio und haptischem Feedback wird über Netzwerk mit einer
virtuellen Umgebung innerhalb der 5-seitigen Projektionsinstallation des V2C verbunden. Dieses Projekt
wurde auf der abArt in der Mohr Villa in München und am Ars Electronica Festival in Linz präsentiert.
Am Akademientag im November war es der Kommission für Glaziologie möglich, publikumswirksam eine
am LRZ entwickelte portable Version der Visualisierung des Vernagtferners mit Hilfe eines Datenhelms zu
präsentieren.
3.3.3 Booklet
Eine vollständig überarbeitete Neuauflage des Booklets, welches das V2C und die dort angesiedelten Projekte vorstellt, wurde im Dezember herausgegeben. Die 64 Seiten starke Broschüre enthält einen Überblick
über Virtuelle Realität und Visualisierung im Allgemeinen, die im V2C verwendeten Technologien und die
verwendete Hardware. 22 Anwendungsbeispiele werden vorgestellt.
45
4 IT-Service Management
Der professionelle Betrieb von IT-Dienstleistungen erfordert klar definierte Regelungen, wie die drei Komponenten People, Processes & Technology zusammenspielen. Eine bewährte Möglichkeit zur Strukturierung stellt dabei eine Orientierung an Rahmenwerken wie ISO/IEC 20000, FitSM oder ITIL dar. Nachfolgend werden die organisatorischen Maßnahmen und Werkzeuge zu ihrer technischen Umsetzung beschrieben, mit denen das LRZ eine kontinuierliche Verbesserung seiner IT-Dienstleistungen verfolgt.
4.1 Einführung von ISO/IEC 20000
Die Zuverlässigkeit und Verfügbarkeit von IT-Services ist in erheblichem Maß von der effektiven Kommunikation, Kooperation und Koordination zwischen den Mitarbeitern eines IT-Service-Providers abhängig.
Ein optimales Management von IT-Diensten muss folglich über die Überwachung und Steuerung der technischen Komponenten hinausgehen und auch die betrieblichen Abläufe bzw. die Prozesse des IT-ServiceProviders kontrollieren und lenken. Die Ausgestaltung eines solchen, prozessorientierten IT-Service-Managements (ITSM) ist Gegenstand verschiedener so genannter ITSM-Rahmenwerke wie der IT Infrastructure Library (ITIL) oder des internationalen Standards ISO/IEC 20000. Das LRZ ist bemüht, ein Managementsystem nach ISO/IEC 20000 zu etablieren.
4.1.1 Incident Management
Für das 2011 eingeführte Incident Management nach ISO/IEC 20000 lag der Fokus 2014 auf der weiteren
kontinuierlichen Verbesserung. Die Zahl der Incidents stieg im Vergleich zum Vorjahr mit durchschnittlich
ca. 750 gemeldeten Störungen und Service Requests pro Monat leicht an.
Mittels erfasster Kennzahlen lässt sich eine leichte Verbesserung in Hinblick auf die Nutzung des LRZServicedesk-Portals und die Einhaltung der intern definierten Ziele für die Reaktions- und Lösungszeiten
nachweisen.
Eine Anhebung der Erstlösungsrate, also des Anteils der direkt durch den Servicedesk gelösten Incidents,
stellt allerdings, angesichts des Umfangs des LRZ-Dienstangebots und der dadurch resultierenden Vielfalt
eingehender Incidents, weiterhin eine massive Herausforderung dar.
4.1.2 Change- und Configuration Management
Im Change- und Configuration-Management wurden die Vorarbeiten aus 2013 aufgegriffen und weitere
Dienste in den Produktivbetrieb überführt. Die vorhandenen Verfahren zu Standard-Changes wurden entsprechend ausgeweitet. Es wurden weitere Anpassungen am zentralen ITSM-Tool vorgenommen und
Schulungen für alle beteiligten Personen durchgeführt.
Die 2014 gesammelten Erfahrungen sind die Basis für das Vorgehen bei der Erweiterung des ChangeManagement-Geltungsbereichs 2015.
Die Ausweitung des Change-Management-Geltungsbereiches wird von einer schrittweisen Erweiterung der
Configuration-Management-Database (CMDB) um die Dokumentation der entsprechenden Dienste und
Dienstkomponenten begleitet.
4.1.3 Weitere ITSM-Prozesse
Das LRZ ist dabei, ein Service-Portfolio-Management auf Basis von FitSM einzuführen, um eine transparentere Steuerung des LRZ-Dienstleistungsangebotes zu erreichen und dieses zukünftig in einer einheitlicheren, strukturierteren und kundenorientierteren Weise zu beschreiben.
4.1.4 Sonstige Aktivitäten
Parallel zu den Einführungsprojekten wird am LRZ auch weiterhin das Zertifizierungs- und Lehrgangskonzept für IT-Service-Management nach ISO/IEC 20000 erfolgreich fortgesetzt. Nachdem in den letzten Jahren das Schulungsprogramm sehr erfolgreich gelaufen ist, beschränkt sich mittlerweile die Ausbildung zum
Foundation-Zertifikat nach ISO/IEC 20000 größtenteils auf neu hinzu gekommene Mitarbeiter. Als schulungsbegleitende Prozesssimulation konnte weiterhin „Fort Fantastic“ von BuGaSi Labs, einer Ausgründung der Hochschule Bochum, genutzt werden. Ergänzend wurde das Schulungskonzept für Informationssicherheit nach ISO/IEC 27000 erfolgreich fortgesetzt. Das Qualifikationsprogramm für FitSM wurde mit
einer englischsprachigen „advanced level“ Schulung im Bereich Service Planning and Delivery weiter geführt.
46
IT-Service Management
4.2 Service-Management-Plattform Action Request System
Das Action Request System (ARS) von BMC wird am LRZ seit 20 Jahren zur Unterstützung des IT Service
Managements eingesetzt, insbesondere für das Change Management, Beschaffungswesen, Asset-Management und die IP-Adressverwaltung. Es befindet sich in Ablösung durch die iET ITSM Suite und andere
Werkzeuge.
Das KOM-Change-Record Formular unterstützt den Change-Management-Prozess in der Abteilung Kommunikationsnetze. 2014 wurden insgesamt 1.154 KOM-Change-Record-Tickets abgeschlossen. Im Bereich Asset Management wurden 2014 insgesamt 3.874 Einzelteile und 974 Geräte im System neu erfasst.
Für das Beschaffungswesen (Stabeg) wurden 35 neue Einträge angelegt. Im Rahmen der IP-Adress-Verwaltung wurden 20 Subnetze neu vergeben.
47
5 IT-Sicherheit
Informationssicherheit ist eine Querschnittsaufgabe, die sich durch alle Abteilungen und Dienste zieht. Im
Folgenden wird auf ausgewählte technische Sicherheitsmaßnahmen eingegangen, die das LRZ zum
Schutz vor Schadsoftware und Angriffen aus dem Internet sowie zum Security-Monitoring innerhalb des
Münchner Wissenschaftsnetzes einsetzt.
5.1 Sicherheitsmanagement
Der Arbeitskreis Sicherheit (AK-Security) hat sich auch in diesem Jahr mit einigen wichtigen Themen im
Bereich der Informationssicherheit beschäftigt. Beispielsweise wurde die bereits im Vorjahr begonnene Erstellung einer Leitlinie, die den administrativen Zugriff auf LRZ-Server regeln soll, fortgeführt und Ende des
ersten Quartals erfolgreich abgeschlossen. Neben der Verpflichtung, definierte Zugangspfade nutzen zu
müssen, wird hierin etwa auch die Auswertung und regelmäßige Auditierung festgelegter Zugangsmaschinen festgelegt. In diesem Zusammenhang sollte auch die generelle Sicherheit von LRZ-Servermaschinen
erhöht werden. Eine aus Mitgliedern des AK-Security zusammengesetzte Arbeitsgruppe hat begonnen,
effektive und meist mit geringem Aufwand umsetzbare Härtungsmaßnahmen zusammenzutragen. Dieser
daraus entstandene Hardening Guide soll auch zukünftig weiter ergänzt und auf einem aktuellen Stand
gehalten werden. Um die Zugangsmöglichkeiten auch netzseitig entsprechend existierender Anforderungen zu beschränken, galt es das bereits vorhandene Netzzonenkonzept zu aktualisieren, was auch dazu
führte, die bisherige Vorgehensweise bei der IP-Adressvergabe in diesen neu festgelegten Netzzonen zu
überprüfen und bei Bedarf anzupassen.
Im Zuge des Aufbaus eines Informationssicherheitsmanagementsystems (ISMS) am LRZ war das Ziel,
konkrete Sicherheitsmaßnahmen auf Basis einer strukturierten Identifikation, Analyse und Bewertung existierender Bedrohungen und Risiken zu ergreifen. Dazu erarbeitete der AK-Security in diesem Jahr eine
entsprechende Leitlinie für das Risikomanagement, welche zukünftig durch eine prozessorientierte Vorgehensweise und konkrete Verfahrensbeschreibungen umgesetzt werden soll. Für das LRZ-CSIRT, das sich
im Gegensatz zu dem eher proaktiv agierenden AK-Security mit der reaktiven Sicherheit und damit der
strukturierten Bearbeitung von auftretenden Sicherheitsvorfällen auseinandersetzt, wurde im Rahmen einer
studentischen Arbeit ein elektronisches Security Incident Management System entwickelt, welches neben
einer sehr benutzerfreundlichen Meldemöglichkeit für LRZ-Mitarbeiter auch die Dokumentation ergriffener
Gegenmaßnahmen und eine nachgelagerte Auswertung der Vorfallsbearbeitung erlaubt. In diesem Jahr
nahm ein Mitglied des LRZ-CSIRT an einem vom DFN-CERT angebotenen IT-Forensik-Workshop teil, mit
dem Ziel, dort vorgestellte Vorgehensweisen und eingesetzte Werkzeuge in den Security-IncidentResponse-Prozess und die Bearbeitung von Sicherheitsvorfällen am LRZ einfließen zu lassen.
5.2 Antivirus
Auf der Grundlage eines Landesvertrages über die Antiviren-Software der Fa. SOPHOS betreibt das LRZ
eine Service-Infrastruktur zur automatischen Verteilung und Installation von SOPHOS-Virensignaturen für
alle Nutzer im Münchner Wissenschaftsnetz, verbunden mit entsprechenden Beratungsleistungen zur Nutzung für Endbenutzer und CID-Betreiber in Bayern. Der Dienst wird täglich von rund 25.000 Clients im
MWN genutzt. Der gesamte First-Level-Support wird von den Auszubildenden am LRZ geleistet.
5.3 WSUS
Zur Versorgung von Clients im MWN mit Sicherheitsupdates für Windows-Betriebssysteme 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 wird
täglich aktiv von rund 8.500 Rechnern genutzt.
5.4 Virtuelle Firewalls
Das LRZ betreibt 5 Cisco Firewall Service Module (FWSM), die sich auf verschiedene Backbone-Router
im Münchner Wissenschaftsnetz (MWN) verteilen, und zwei ASA5580-40 zentral am LRZ (technische Details siehe Jahresbericht 2009). Derzeit werden damit rund 132 Kunden (123 im Vorjahr) mit virtuellen Firewalls (VFW) bedient.
48
IT-Sicherheit
Abbildung 15: Entwicklung der virtuellen Firewalls seit 2007
Die folgende Abbildung zeigt die Web-Schnittstelle zur Administration einer virtuellen Firewall.
Abbildung 16: Web-Schnittstelle Adaptive Security Device Manager (ASDM)
Nach über 2 1/2 Jahren konnte endlich der Betrieb des Firewall-Clusters, bestehend aus den beiden
ASA5580-40, im Active-Active-Modus aufgenommen werden. Vorausgegangen waren mehrere instabile
Betriebssystem-Versionen des Herstellers und ein aufwändiger Migrationsprozess der vorhandenen Konfiguration. Im Vergleich zum Active-Passive-Modus, der zu Beginn verwendet wurde, erlaubt der ActiveActive-Modus eine deutlich höhere Bandbreite und einen unterbrechungsfreien Betrieb. Damit konnte dem
SuperMUC deutlich mehr Firewall-Kapazität zur Verfügung gestellt werden. Das Firewall-System ist redundant auf zwei Brandabschnitte aufgeteilt und an die Hausrouter angeschlossen.
Da die bis jetzt eingesetzten Firewall-Module auf den Routern von Cisco nicht mehr unterstützt werden und
außerdem dringend benötigte Funktionen (z.B. VPN) fehlen, muss eine neue Lösung für die Firewalls im
MWN gefunden werden. Im vergangenen Jahr wurde der Markt nach in Frage kommenden Produkten
eruiert. Im Vorfeld fand eine Befragung der LRZ-Kunden zu den Erfahrungen mit den bisherigen Systemen
statt, deren Ergebnis in eine Anfrage an verschiedene renommierte Firewall-Hersteller einfloss. Die Anfrage
enthielt eine Beschreibung der LRZ-Umgebung und die Spezifikation der LRZ-Anforderungen. Nach Auswertung der Antworten konnten drei Hersteller herausdestilliert werden, deren Produkte dann über ein halbes Jahr ausgiebig mit mehreren repräsentativen Testkunden auf ihre Tauglichkeit überprüft wurden. Bei
den drei Produkten handelte es sich um Palo Altos PA5060, Fortinets Fortigate FG3600 (beide kommerziell) und pfSense in den Versionen 2.1.2 und 2.1.3 (open-source) als Virtual Appliance auf bestehender
VMware-Infrastruktur. PfSense konnte die meisten LRZ-Anforderungen zufriedenstellend erfüllen und
setzte sich damit gegen seine kommerziellen Konkurrenten durch. Es wurde eine vergleichende Bewertung
mit ausführlichem Testbericht erstellt.
49
5.5 Technische Aspekte des Sicherheitsmanagements
Für die technischen Aspekte des Sicherheitsmanagements setzt das LRZ eine Reihe von Werkzeugen ein,
die nachfolgend näher vorgestellt werden.
5.5.1 Secomat
Das automatische proaktive Intrusion Prevention System (IPS) Secomat (vormals NAT-o-MAT) besteht
derzeit aus einem Cluster mit 4 Nodes (Geschichte siehe Jahresbericht 2007 und 2009). Jeder Node kann
eine theoretische Datenübertragungsrate von 10Gbit/s bewältigen. Die eingesetzte Technik zur Lastverteilung spaltet jedoch nur einmal 10Gbit/s auf die 4 Nodes auf. Diese Obergrenze wird vom MWN-Backbone
vorgegeben, da es auf dem 10-Gbit/s-Ethernet-Standard basiert.
Die folgenden Abbildungen zeigen Datenübertragungsraten, Benutzer und gesperrte Benutzer des Secomat-Clusters im Zeitraum von einer Woche in der vorlesungsfreien Zeit.
Abbildung 17: secomat1
In der Spitze verarbeitete der Secomat 28.000 gleichzeitige Benutzer. Die folgende Tabelle zeigt die durchschnittliche Datenübertragungsrate der letzten 12 Monate.
Tabelle 1: Durchschnittliche eingehende und ausgehende Datenübertragungsrate der letzten 12
Monate
Durchschnittliche Datenübertragungsrate
der letzten 12 Monate
MWN eingehend
ca. 3,7 Gbit/s
MWN ausgehend
ca. 0,8 Gbit/s
50
IT-Sicherheit
Der Secomat-Cluster zeigt sich im Betrieb zuverlässig. Probleme macht im Großen und Ganzen hauptsächlich Skype, das sich vermutlich aufgrund der Distanz zwischen Secomat und Skype-Client im MWN so
verhält, als sei es nicht hinter einem NAT-Gateway (laut Dokumentation soll Skype erkennen können, ob
es sich hinter einem NAT-Gateway befindet). Das führt dazu, dass Skype-Clients mit privaten IP-Adressen
zu sogenannten „Supernodes“ werden und dann wegen ihres auffälligen Kommunikationsverhaltens durch
den Secomat gesperrt werden. Die Sperrungen können am Secomat leider nicht verhindert werden, da
sich das auffällige Kommunikationsverhalten der Skype-Clients nicht zuverlässig von Netzmissbrauch wie
z.B. Portscans unterscheiden lässt. Deshalb muss das Verhalten des Skype-Clients auf dem Client-PC
beeinflusst werden. Je nach Betriebssystem gibt es dafür unterschiedliche Lösungen. Zur Unterstützung
der Kunden bietet das LRZ über sein Webportal eine ausführliche FAQ an.
5.5.2 Security Information & Event Management
Die Auswertung der im Rahmen des LRZ-Security-Monitorings detektierten sicherheitsrelevanten Ereignisse findet am LRZ mithilfe einer Security Information und Event Management (SIEM) Lösung statt. Das
bislang nun mehrere Jahre erfolgreich eingesetzte Open-Source-SIEM der Firma Alienvault, OSSIM, wurde
in diesem Jahr durch eine neue Software der Firma IBM (QRadar) ersetzt. QRadar wurde im Rahmen einer
Produktevaluation und -auswahl als geeignete Lösung für den Einsatz am LRZ ermittelt. Notwendig wurde
die Ersetzung zum einen aufgrund des nahezu flächendeckenden Einsatzes von IPv6 im MWN, was OSSIM bislang nicht unterstützt, und zum anderen durch die beschränkte Leistungskapazität der OpenSource-Lösung. Die Installation der neuen SIEM-Lösung bereitete keine unlösbaren Probleme, die Anbindung der Datenquellen, insbesondere sowohl der am X-WiN-Übergang betriebenen Intrusion-DetektionSensoren als auch der X-WiN-Router, welche die Netflow-Daten an die SIEM-Lösung weiterleiten, war mit
geringem Aufwand umzusetzen. Höchste Priorität hatte bei der Inbetriebnahme die schnellstmögliche Ersetzung der von OSSIM bereitgestellten Auswertungs-, Korrelations- und automatischen Alarmierungsmechanismen. Besonders der letzte Punkt verursachte einiges an Aufwand, da QRadar, im Gegensatz zu
OSSIM, leider keine Möglichkeit bietet, um bei Auftreten bestimmter Ereignisse Skripte anzustoßen, die
automatisiert für das betreffende System zuständige Netzverantwortliche, den Switchport, an dem das System angeschlossen ist, oder den zu einer VPN-IP-Adresse zugeordneten Nutzer ermitteln. Nachdem nun
die Basis für die Erkennung ausgewählter Angriffe oder mit Malware infizierter Systeme, insbesondere das
immer noch im MWN zu beobachtende Trojanische Pferd Zeus, vorhanden ist, lassen sich weitere Auffälligkeiten nach demselben Prinzip mit vergleichsweise geringem Aufwand erkennen und entsprechende
Reaktionen auslösen. Beispielsweise wurde nach diesem Prinzip die Ransomware, die mitunter Festplatten oder auf einem System vorhandene Dateien verschlüsseln kann oder weitere Schadsoftware aus dem
Internet nachladen kann, in die automatische Reaktionskette aufgenommen.
Die weitaus größeren Leistungskapazitäten von QRadar erlauben nun auch nahezu eine Echtzeit-Auswertung von Netflow-Daten, um Anomalien im Kommunikationverhalten zu identifizieren. Dabei werden sowohl
ein- als auch ausgehende Kommunikation analysiert, wobei der Schwerpunkt auf der Erkennung von Angriffsmustern im ausgehenden Verkehr liegt. Zu den zu erkennenden Mustern zählen etwa (Distributed)
Denial-of-Service-Angriffe, bei denen ans Münchner Wissenschaftsnetz angeschlossene Systeme beteiligt
sind, als auch Port- und Netzscans oder die plötzlich auftretende Kommunikation auf ausgewählten, aber
für ein System untypischen Ports, etwa E-Mail-Ports, was meist ein Indiz für den Versand von SPAM-EMails, hervorgerufen durch eine Kompromittierung des Systems oder Infektion mit einem entsprechenden
Schadprogramm, ist. Neben der technischen Umsetzung der Erkennung von Verkehrsanomalien, sollen
zukünftig auch weitere Datenquellen an das SIEM-System angebunden werden, um die bislang weitestgehend isolierte Auswertung sicherheitsrelevanter Ereignisse durch entsprechende regelbasierte Korrelation
noch weiter zu verbessern und dadurch die Anzahl von Falsch-Alarmierung weiter zu senken.
5.5.3 Sicherheits- und Netzmanagement: Nyx
Das Sicherheits- und Netzmanagementwerkzeug Nyx, mit dem einzelne Rechner im MWN lokalisiert werden können, liefert nach Eingabe einer bestimmten MAC- oder IP-Adresse den Switchport, an dem der
Rechner angeschlossen ist. Außerdem wird, falls hinterlegt, die Bezeichnung der Netzwerkdose ausgegeben, zu welcher dieser Switchport gepatcht ist. Dies ist gerade auch im Hinblick auf das schnelle Auffinden
von Rechnern und Geräten wichtig.
Das Nyx-System wurde im letzten Jahr weiterentwickelt. Besonders zu nennen ist hier der Umbau auf ein
Code-Verwaltungssystem und entsprechende Anpassungen des Codes für neue Geräte. Insbesondere
können nun auch Geräte mit beliebigen SNMP-Communities ausgelesen werden.
51
5.5.4 Self-Service Portal; Sperr- und Entsperrmechanismen
Das durch die Security Information & Event Management (SIEM) Lösung unterstützte LRZ Security-Monitoring erlaubt eine zum Großteil automatische Reaktion bei Erkennen sicherheitsrelevanter Auffälligkeiten.
Ein in diesem Zusammenhang umgesetzter Eskalationsmechanismus weist die zuständigen Netzverantwortlichen im ersten Schritt lediglich auf die erkannte Auffälligkeit hin. Bei wiederholtem Auftreten derselben
Auffälligkeit wird eine private IP-Adresse am Secomat automatisch gesperrt, was in diesem Fall gleichzusetzen ist mit einer Beschränkung des Internetzugangs. Nutzer, deren Kommunikation über das SecurityGateway Secomat stattfindet, werden bei der Sperrung ihrer IP-Adresse auf eine spezielle Webseite umgeleitet, auf der zum einen der Grund für die Sperrung und zum anderen nützliche Hinweise und Informationen zur Behebung des Problems aufgeführt sind. Die Freischaltung einer gesperrten IP-Adresse erfolgte
bisher durch Mitarbeiter des LRZ Abuse-Response-Teams (LRZ AR-Team), an das sich der Nutzer per EMail unter Angabe der durchgeführten Maßnahmen (Entfernen der Schadsoftware durch eine Anti-VirenSoftware, Neuinstallation des betroffenen Systems) wenden musste.
Um hier zum einen die Mitarbeiter des LRZ AR-Teams von derartigen Routinetätigkeiten zu entlasten und
zum anderen Nutzern auch eine zeitnahe Freischaltung außerhalb der üblichen Bürozeiten, etwa am Wochenende, zu ermöglichen, wurde in diesem Jahr ein Self-Service zur Verfügung gestellt, welcher über die
dem Nutzer einer gesperrten IP-Adresse angezeigte Webseite zugänglich ist. Eine Freischaltung erfolgt
jedoch erst dann, wenn der Nutzer, wie bisher auch, die von ihm ergriffenen Maßnahmen in einem übersichtlich gestalteten Web-Formular beschreibt. Um zu verhindern, dass ein Nutzer die Freischaltung einer
IP-Adresse ohne wirksame Maßnahmen ergriffen zu haben beliebig oft wiederholt, ist diese derzeit nur
zweimal pro Monat möglich. Desweitern wird durch nachgelagerte, automatische Plausibiltätsüberprüfungen versucht, sicherzustellen, dass die ergriffenen Maßnahmen oder deren Kombination auch tatsächlich
ausreichend und wirksam sind. So ist ein systemweiter Scan mit einer Anti-Viren-Software, welche nicht
auf dem aktuellen Stand ist, als nahzu nutzlos anzusehen; gleiches gilt, wenn die gefundenen Dateien nicht
gelöscht oder vollständig gesäubert wurden und das etwa durch eine Wiederholung des Scans bestätigt
ist. Zu Statistikzwecken wird das LRZ AR-Team per E-Mail über eine durch den Nutzer selbst per SelfService vorgenommene Freischaltung informiert.
52
IT-Basisdienste
6 IT-Basisdienste
6.1 E-Mail
6.1.1 Migration der lokalen Mailserver im MWN
Im Bereich der klassischen Maildienste konnte in 2014 die seit mehreren Jahren andauernde Migration von
Maildomains auf die neue, Postfix-basierte Infrastruktur abgeschlossen werden. Damit konnten auch die
letzten physischen Server abgeschaltet werden und die klassischen Maildienste werden jetzt durchgehend
von virtuellen Servern erbracht. Die Infrastruktur besteht nun aus zwei großen Blöcken:
•
Postrelays, Postforwarder und Postout zur Versorgung der fünf vom LRZ betriebenen Message
Stores mit 512 verschiedenen Maildomains
• Mailrelays und Mailout zur Versorgung der 139 lokalen Mailserver im MWN mit 422 Maildomains
Daneben gibt es eine Reihe weiterer Mailserver für Spezialzwecke, wie z.B. für Mailinglisten oder die Verteilung von administrativen E-Mails.
6.1.2 Inhaltsbasierte „Prequeue-Filterung“ von Spam- und Virenmails
Die inhaltsbasierte Filterung von E-Mails ist sehr rechenintensiv. Daher wird sie normalerweise erst durchgeführt, nachdem eine E-Mail vollständig übertragen, d.h. vom Mailserver angenommen und in der Queue
abgespeichert ist. Stellt man dann fest, dass es sich um eine Virenmail oder um eine Spammail handelt,
kann man sie nicht mehr ablehnen, da man sonst Backscatter erzeugt. Sie muss daher entweder in Quarantäne gelegt oder an den Empfänger ausgeliefert werden. Diese Art der Filterung nennt man PostqueueFilterung. Es ist aber wünschenswert, dass eine E-Mail, die einen Virus enthält oder sicher als Spammail
erkannt wird, erst gar nicht angenommen sondern gleich abgewiesen wird. Dazu muss sie sofort, noch
bevor sie endgültig angenommen wurde, untersucht werden. Dies nennt man dann Prequeue-Filterung.
In 2013 wurden die Mailrelays, die wesentlich weniger E-Mails als die Postrelays verarbeiten müssen, auf
Prequeue-Filterung umgestellt. Nachdem es damit keine Probleme gab, erfolgte dieser Schritt in 2014 auch
bei den Postrelays. Die Postrelays wurden dafür im Vergleich zu den Mailrelays von 2 auf 4 CPUs und von
2 auf 8 GByte Hauptspeicher aufgerüstet. In der Regel können damit alle ankommenden E-Mails sofort
verarbeitet werden. Im Durchschnitt wird etwa alle 10 Tage ein Teil der ankommenden E-Mails ein paar
Minuten lang verzögert angenommen, da alle Verarbeitungskapazitäten ausgeschöpft sind.
6.1.3 Verschlüsselte Übertragung von E-Mails
Nachdem das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) im September 2014 zahlreiche
Unternehmen abgemahnt hat, da ihre Mailserver kein TLS zur verschlüsselten Übertragung von E-Mails
bereitgestellt haben, hat sich das LRZ mit dem Thema intensiv auseinander gesetzt.
Ähnlich wie bei dem Projekt „E-Mail made in Germany“ der großen Provider Telekom, GMX, WEB.DE, 1&1
und Strato, sollen auch beim LRZ nicht nur alle Übertragungswege zwischen den Mailprogrammen der
Nutzer und den Mailservern des LRZ als auch den Mailservern im Internet mit TLS verschlüsselt werden,
sondern auch dafür gesorgt werden, dass sich kein Angreifer in die Übertragungswege einschalten und
damit die übertragenen Daten mitlesen kann (MITM = man-in-the-middle-Angriff). Im Gegensatz zu den
oben genannten Providern, die dafür ein proprietäres Protokoll einsetzen und damit alle anderen Betreiber
von Mailservern, die sich die teure Zertifizierung nicht leisten können, von der Teilnahme ausschließen,
setzt das LRZ auf den offenen Standard DANE (DNS-based Authentication of Named Entities), an dem
jeder Mailserver weltweit teilnehmen kann. Im Herbst wurde mit der kryptographischen Signatur der Domain lrz.de (DNSSEC) und der Veröffentlichung der TLSA-Records der LRZ-Mailserver im DNS dafür die
Voraussetzung geschaffen. Seither kann jeder Mailserver im Internet überprüfen, ob er für den Versand
einer E-Mail auch mit dem richtigen Mailserver am LRZ verbunden ist, vorausgesetzt die Domain des Empfängers ist signiert. Bis Ende des Jahres waren neben den Domains lrz.de und stusta.de eine Reihe von
Domains der TUM – insbesondere die Domain tum.de, aber auch einige Subdomains dazu – signiert.
53
6.1.4 Statistiken zur Mailnutzung
6.1.4.1
Spam- und Virenabwehr
Das Gros der Spam- und Virenmails wird bereits von den Post- bzw. Mailrelays, die für die Annahme von
E-Mails aus dem Internet zuständig sind, durch die dort implementierten Abwehrmechanismen abgewiesen. Bevor die E-Mails angenommen werden, werden sie auch einer inhaltlichen Überprüfung unterzogen
und mit Viren infizierte E-Mails sowie eindeutig als Spam erkennbare E-Mails werden ebenfalls abgewiesen. E-Mails, bei denen nur vermutet wird, dass es sich um Spammails handelt, werden angenommen,
entsprechend markiert und an den Nutzer weitergeleitet. Die Markierung kann dann dazu verwendet werden, die betreffenden E-Mails auszufiltern (durch Konfiguration von Regeln im Webmailer Roundcube oder
im eigenen Mailprogramm).
Das durchschnittliche E-Mail-Aufkommen an den Post- und Mailrelays lag 2014 bei ca. 800.000 E-Mails
pro Tag. Davon wurden durch die Spam- und Virenabwehr gut drei Viertel direkt abgewiesen und nur ein
knappes Viertel zugestellt – Details siehe nachfolgende Tabelle.
Tabelle 2: Angenommene und abgewiesene E-Mails
Anzahl E-Mails
pro Tag
in Prozent
Von den Post- und Mailrelays abgewiesene E-Mails
aufgrund allgemeiner Abwehrmechanismen
(z.B. Nutzung von Blacklists)
als Spammails erkannt
als Virenmails erkannt
604.000
5.500
290
75,51 %
0,69 %
0,04 %
Von den Post- und Mailrelays angenommene E-Mails
„gute“ E-Mails
als mögliche Spammails markiert
186.000
4.050
23,25 %
0,51 %
ca. 800.000
100,00 %
Behandlung eingehender E-Mails
Gesamt
6.1.4.2
Relaydienst
Am Übergang vom Internet in das Münchner Wissenschaftsnetz (MWN) ist der Port für das SMTP-Protokoll
für fast alle Rechner gesperrt. Nur einige ausgewählte Mailserver – neben den Post- und Mailrelays 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 Relayserver benutzen.
Der Vorteil ist, dass sich ein lokaler Mailserver im MWN nicht um Viren- und Spamfilterung kümmern muss,
das wird bereits durch den Relayserver erledigt.
Den Relayservice des LRZ, d.h. die Mailrelays, nehmen zurzeit 139 (Vorjahr 149) Mailserver im MWN mit
insgesamt 422 (Vorjahr 416) verschiedenen Maildomains in Anspruch. Die Anzahl der lokalen Mailserver
hat letztes Jahr nur leicht abgenommen, da die TUM weniger Mailserver auf das zentrale Exchange-System
migriert hat wie im Vorjahr.
Tabelle 3: Nutzung des Relaydienstes
Einrichtung
Mailserver im MWN
Domains
34
(34)
115
(116)
66
(74)
180
(191)
andere Hochschulen und hochschulnahe Einrichtungen
39
(41)
127
(109)
Gesamt
139
(149)
422
(416)
54
6.1.4.3
IT-Basisdienste
Mailhosting (virtuelle Mailserver)
Das LRZ bietet Hochschul- und hochschulnahen Einrichtungen, die keinen eigenen Mailserver betreiben
wollen, an, den Maildienst am LRZ zu „hosten“. Es wird dann ein virtueller Mailserver eingerichtet, in dem
sich der Name der betreffenden Einrichtung widerspiegelt (z.B. jura.uni-muenchen.de) und Angehörige
dieser Einrichtungen erhalten entsprechende Mailadressen. Ein virtueller Mailserver kann wiederum mehr
als eine virtuelle Maildomain haben, z.B. im Zuge einer Umbenennung der zugehörigen Einrichtung. Die
zu den virtuellen Mailservern gehörenden Mailboxen können sich sowohl auf dem POP/IMAP-Server
mailin.lrz.de als auch auf dem vom LRZ betriebenen Exchange-Server befinden. Die 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.
Ende 2014 waren am LRZ 210 (Vorjahr: 213) virtuelle Mailserver eingerichtet. Eine Aufteilung auf die
Hauptnutzer ist der folgenden Tabelle zu entnehmen.
Tabelle 4: Nutzung des Mailhostings
virtuelle
Mailserver
Einrichtung
Domains
über LRZ-Benutzerverwaltung
über TUMonline
87
(89)
144
42
(43)
72+20 (98)
139+20 (107)
Bayer. Akademie der Wissenschaften (inklusive LRZ)
38
(40)
77
(77)
2
(0)
7
(1)
41
(41)
53
(48)
Gesamt
210
(213)
492+20 (475)
Hochschule München
(144)
Die Angabe +20 bedeutet, dass sich Ende des Jahres 20 Domains in Migration von der LRZ-Benutzerverwaltung nach TUMonline befanden und die Domains daher in beiden Benutzerverwaltungen existierten.
6.1.4.4
Nutzung der POP/IMAP-Messagestores
Die Anzahl der Mailboxen an den POP/IMAP-Servern war aufgrund der verstärkten Nutzung des
Exchange-Dienstes erneut rückläufig. Ende 2014 gab es 94.503 Mailboxen (Vorjahr: 103.248). Nachfolgend eine Aufteilung nach Server bzw. Benutzergruppen:
Tabelle 5: Nutzung der POP/IMAP-Server
POP/IMAP-Server für …
Anzahl Benutzer
… Mitarbeiter der vom LRZ bedienten Einrichtungen (Mailserver „mailin“):
8.517
7.187
303
Hochschule München
279
andere bayerische Hochschulen
52
andere wissenschaftliche Einrichtungen
2.575
18.913
… Mitarbeiter und Studenten der TU München (Mailserver „mytum“)
18.418
… Studenten der Ludwig-Maximilians-Universität München (CampusLMU)
(inkl. Mitarbeiter, die ihre CampusLMU-Mailadresse behalten haben)
54.975
… Studenten anderer Münchner Hochschulen
Gesamt
2.197
94.503
6.1.4.5
55
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 Weiterleitungsservice
für ganze Domains, zu denen es keine Mailboxen gibt. Bei der LMU handelt es sich dabei um die Domain
lmu.de, bei der TUM um die Domain alumni.tum.de.
Tabelle 6: Nutzung des Weiterleitungs-Service
Einrichtung
Weiterleitungen
Gesamt
6.1.4.6
22.464
6.106
28.570
Nutzung von E-Mail-Verteilerlisten
Das LRZ bietet seinen Nutzern die Möglichkeit eigene E-Mail-Verteilerlisten einzurichten (auf Basis von
Mailman). Ende 2014 gab es 1.051 Listen (Vorjahr: 922), die sich wie folgt verteilten:
Tabelle 7: Nutzung von E-Mail-Verteilerlisten
Einrichtung
E-Mail-Verteilerlisten
266
554
159
Gesamt
72
1.051
6.2 Exchange
6.2.1 Migration auf Exchange 2013
Im Berichtsjahr wurde eine neue Exchange-Umgebung auf Basis der aktuellen Exchange-Version 2013
aufgebaut und das bisherige System dorthin migriert. Besonders aufwendig war dabei die Migration der
Postfächer, da für Exchange 2013 neue Datenbanken notwendig waren und alle Postfächer – mit einem
Umfang von insgesamt ca. 11 TByte – in die neue Umgebung verschoben werden mussten. Allein dieser
Teil der Migration zog sich über ca. zwei Monate hin. Erfreulich war, dass die Migration für unsere Benutzer
weitgehend problemlos verlief.
6.2.2 Exchange für die Hochschule München
Nach den umfangreichen Vorarbeiten im letzten Jahr, insbesondere Anbindung des Identity Management
Systems der Hochschule München an das Identity Management System des LRZ und Abschluss einer
Vereinbarung zur Auftragsdatenverarbeitung, konnte in 2014 der Benutzerbetrieb aufgenommen werden.
Ab März wurden zunächst die Mailboxen von Mitarbeitern der zentralen IT und der Verwaltung nach
Exchange umgezogen. Nach weiteren Mitarbeiterumzügen erhielten im September auch alle Erstsemester
eine Exchange-Mailbox und im Laufe des Dezembers wurde der Dienst schließlich für alle Studenten freigegeben. Bevor die ersten Studenten aufgenommen wurden, wurden auf Wunsch der Hochschule München noch spezielle Sichtbarkeitsregeln für die Adressbücher implementiert, durch die gesteuert werden
kann, welche Personengruppen welche anderen Gruppen im Adressbuch sehen bzw. nicht sehen können.
6.2.3 Nutzung des Exchange-Dienstes
Wie schon in den Vorjahren war beim Exchange-Dienst auch im Jahr 2014 wieder ein starkes Wachstum
zu verzeichnen. Die Nutzerzahl stieg um ca. 11.500 auf knapp 42.000 (+ 38 %) und der durch die Mailboxen
56
IT-Basisdienste
belegte Speicherplatz um ca. 5 auf 12 TByte (+ 70 %). Die folgende Grafik zeigt die Entwicklung seit Mitte
2011.
Exchange-Nutzung 2011 bis 2014
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Anzahl Postfächer
Speicherplatz [TByte]
Abbildung 21: Entwicklung der Exchange-Nutzung seit 2011
Ende 2014 haben sich die Nutzer dabei wie folgt auf die teilnehmenden Einrichtungen verteilt:
Tabelle 8: Nutzung des Exchange-Dienstes in 2014
Einrichtung
Hochschule München
Exchange-Nutzer
1.879
33.213
5.354
Katholische Stiftungsfachhochschule
350
984
Gesamt
41.780
6.3 Webhosting
6.3.1 Performance-Tuning in der neuen Webhosting-Betriebsumgebung
Im Berichtsjahr fanden, wie auch schon im Jahr davor, umfangreiche Arbeiten im Bereich der Datenablage
und Verwaltung der gehosteten Webserver statt. Obwohl die Leistungsfähigkeit der Systeme zufriedenstellend war, wurde eine Reihe von Maßnahmen zur Verbesserung durchgeführt. Dies diente neben den damit
verbundenen üblichen Verbesserungen der Sicherheit unter anderem auch dazu, den Betrieb robust gegenüber dem stetig ansteigenden Leistungsbedarf zu machen.
Weder die auf den Webservern eingesetzten Eigenentwicklungen der Anwender noch die Software anderer
Entwickler (vorwiegend Freie Software) sind in jedem Fall robust gegenüber größeren Upgrades der zugrunde liegenden Infrastruktur, wie sie 2014 geplant waren. Daher wurden für alle rund 1.200 Webserver
nach und nach Testumgebungen bereitgestellt, um die Auswirkungen des Upgrades im Vorfeld testen und
Fehler und Probleme beheben zu können. Für viele der Webserver mussten individuelle Lösungen gefunden werden, um den Webserver in der neuen Betriebsumgebung wieder voll funktionsfähig zu machen.
Dabei wurden die Betreiber intensiv betreut und unterstützt.
6.3.1.1
57
Update Apache Webserver und PHP
Auf allen Webservern der Webfarm wurde eine neue Version des Apache-Webservers ausgerollt (Update
von Apache 2.2. auf 2.4.). Parallel dazu wurde auch auf allen Webservern der Webfarm eine neue PHPVersion eingespielt (Update PHP 5.3. auf 5.5).
6.3.1.2
Ausbau von Memcached
Für die Moodle-Instanzen der LMU wurden, wie auch schon im Jahr davor für TUM-Moodle, MemcachedServer eingerichtet, was zusammen mit den von den Betreibern der Moodle-Instanzen durchgeführten
Moodle-Updates einen weiteren Performance-Gewinn brachte.
6.3.1.3
Optimierung der Zugriffe auf das Dateisystem
Die Konfigurationen der Webserver wurden systematisch daraufhin untersucht, ob zeitaufwändige Zugriffe
auf das Dateisystem vermieden werden können. Viele einzelne, bisher dezentral liegende Konfigurationen
konnten dadurch zusammengeführt werden.
6.3.1.4
Grafische Darstellung der Performance-Gewinne
An der folgenden Abbildung wird der Gewinn durch die genannten Maßnahmen besonders deutlich erkennbar. Die Abbildung zeigt die Anwortzeiten eines Webservers über einen Zeitraum von 5 Wochen. Zwischen
Woche 37 und 38 gab es eine Testphase – hier ist die Kurve flach - danach wurde die alte Betriebsumgebung kurzfristig reaktiviert, und schließlich vollständig in die neue Umgebung geschwenkt. Die Antwortzeiten waren mit 100 bis 200 Millisekunden ohnehin schon vor der Umstellung sehr gut, konnten aber durch
die Maßnahmen um mehr als einen Faktor 10 gesteigert werden. Dadurch ist insbesondere bei den weiterhin wachsenden Diensten wie TUM-Moodle oder LMU-Moodle für ausreichend Wachstumsmöglichkeit
gesorgt.
Abbildung 22: Webserver-Antwortzeit [ms] in alter (KW37) und neuer (KW39) Betriebsumgebung
6.3.2 Verlagerung und Upgrade TUM-Typo3-Projekt
Das IT-Service-Zentrum der TUM betreibt im Rahmen des Webhostings am LRZ rund 400 Webserver für
Institute, Einrichtungen und Lehrstühle der TUM. Die Webserver werden mit dem Content Management
System Typo3 betrieben, für das seit Mitte 2014 ein großes Upgrade ansteht. Zusammen mit dem ITSZ
wurde ein Konzept für eine Betriebsumgebung entwickelt und umgesetzt, um die für dieses Upgrade notwendige Einzelbehandlung eines jeden der 400 Webserver möglichst ohne Ausfälle und Risiken durchführen zu können. Die Typo3-Upgrades selber werden vom ITZS organisiert und durchgeführt.
6.4 Desktop-Management
Für das Deployment und Management von Windows Desktop- und Serversystemen kommt am LRZ Microsoft System Center Configuration Manager (SCCM) zum Einsatz. Der SCCM ermöglicht ein Betriebssystemrollout als Bare-Metal Variante (auf einem leeren System) sowie als in-place Upgrade oder Neuinstallation über ein bereits vorhandenes System. Im letzteren Fall werden dabei auch Einstellungen und Nutzerdaten migriert. Des Weiteren ist es möglich, Software auf den gemanagten Clients zu installieren, aktualisieren oder deinstallieren. Ein integriertes Reporting gibt Aufschluss über die Erfolgsrate des Rollouts
und etwaige aufgetretene Fehler. Über den SCCM werden sowohl Mitarbeiter-PCs und -Laptops als auch
Serversysteme und virtuelle Maschinen installiert und verwaltet.
Um das verfügbare Software Repository stets aktuell zu halten und an die Bedürfnisse der Nutzer auszurichten, wurden im vergangenen Jahr fortlaufend Software-Pakete aktualisiert sowie neue Software in das
58
IT-Basisdienste
Repository eingepflegt. Dabei wurden die Methoden weiter verfeinert. Insgesamt stehen derzeit über 500
Software-Pakete aus den unterschiedlichsten Anwendungsbereichen (Office, Internet, Architektur, Musik,
Biologie, Wirtschaft, uvm.) für die Verteilung zur Verfügung. Unterstützt werden alle aktuellen Windows
Betriebssysteme. Insgesamt, d.h. MWN-weit, werden vom SCCM rund 2.000 (1.400) Client-Systeme und
160 (135) Serversysteme verwaltet.
Im Rahmen des MWN-ADS wird noch der Light-Desktop/Server angeboten, bei dem Institutionen im MWN
Rechner in die Infrastruktur integrieren können und so die Vorteile des zentral gepflegten MWN-ADS für
das Desktop- und Server-management mitnutzen können, ohne selbst eine ADS-Infrastruktur betreiben zu
müssen. Die komplette Administration der integrierten Light-Desktop/Server liegt dabei aber in voller Verantwortung der lokalen Administratoren der jeweiligen Institutionen.
6.4.1 Rechnerpools
Das LRZ hat unterschiedliche Modelle für die Bereitstellung von aktuellen Windows-Arbeitsplätzen für verschiedene Kundengruppen entwickelt. Die Lösungen reichen dabei vom vollwertigen Mitarbeiterarbeitsplatz über Terminalserverlösungen für Mitarbeiter bis zum virtuellen Desktop für Testzwecke. Für Studenten werden sowohl vollwertige Rechnerpools als auch auf Terminalserverlösungen basierende Pools angeboten. Diese Fullmanaged Desktops (MWN-PC) werden vom LRZ von der OS Installation, über die Softwarepflege bis zum Monitoring betreut. Bei den vom LRZ betreuten Systemen an der LMU, HMT (Hochschule Musik und Theater), BAdW oder TUM wird der First Level Support von Vorortbetreuern der jeweiligen Mandanten wahrgenommen, die bei Problemen oder Änderungswünschen als Ansprechpartner zum
LRZ agieren. Das bisherige Modell wurde an der TUM sukzessive in das Betriebsmodell „TUM-PC“ überführt.
Für die Abrechnung der Druckaufträge in den Pools der HMT, TUM und am LRZ wird die Druckkostenabrechnung Papercut verwendet. In 2014 wurde die Fakultät Soziologie der LMU in das Abrechnungssystem
als weiterer Mandant aufgenommen. Die Papercut-Lösung ermöglicht ein voneinander unabhängiges Agieren der jeweiligen Einrichtungen und erfüllt die Erfordernisse des Datenschutzes. Die Teileinheiten können
das Geld für die Druckkosten selbstständig, ohne Zutun des LRZ, einnehmen und verrechnen.
Die verschiedenen Rechnergruppen setzen sich zahlenmäßig Ende 2014 wie in Tabelle 9 zusammen:
Tabelle 9: Clients im MWN-ADS
Mandanten
Light Desktop
LRZ
Pool und Kurs
38 (51)
BAdW
TUM
5.995 (5.241)
203 (154)
LMU
743 (458)
20 (20)
HMT
Summen
Fullmanaged Desktop
211
(214)
201
(201)
1237
(289)
1649
(704)
54 (52)
6338
(5.818)
315
(277)
6.4.2 TUM-PC
Ein wichtiges Ziel ist es, den SCCM für eine Nutzung durch Teiladministratoren des MWNs freizugeben.
Obwohl der SCCM keine Mandantenfähigkeit im eigentlichen Sinn aufweist, konnte hierzu für die Teiladministratoren eine Möglichkeit geschaffen werden, über die SCCM Console ihre jeweiligen Systeme zu
verwalten, ohne selbst eine komplette Softwareverteilungsinfrastruktur zu betreiben.
Darum wurde in enger Kooperation mit der TUM und einem externen Dienstleister in 2013 das Projekt
TUM-PC ins Leben gerufen. Im Rahmen des kostenpflichtigen TUM-PCs nutzen nun verschiedene Teiladministratoren an der TUM die Methoden des SCCMs am LRZ, um Ihre Rechner an den jeweiligen Instituten
zu installieren und zu verwalten. Ende 2014 waren bereits 64 Einrichtungen der TUM im System registriert.
Dem externen Dienstleister kommt hierbei eine besondere Rolle zu. Er übernimmt die allgemeine Vorortbetreuung an der Einrichtung, begleitet Vorort die Anbindung der Einrichtungen an den SCCM und fungiert
als fachlich kompetenter Ansprechpartner gegenüber dem LRZ.
Mit dem TUM-PC können nun die teilnehmenden Einrichtungen Software-Pakete vom LRZ, die sich bereits
im Software Repository befinden, jederzeit mitbenutzen - entsprechende Lizenzierung durch den Kunden
59
vorausgesetzt. Software, die nicht vorhanden ist, in der Regel Spezialsoftware von Fakultäten, wird für den
Kunden, je nach Aufwand, kostenpflichtig paketiert. Das LRZ übernimmt zudem die aus Sicherheitsgründen
regelmäßig erforderliche Aktualisierung von Standardsoftware, wie z.B. Java, Mozilla Firefox oder Adobe
Flash. Der TUM-PC ist des Weiteren in die definierte Infrastruktur für verwaltete Systeme am LRZ eingebettet. Dies beinhaltet das zentrale Patchmanagement, die Antivirenlösung, vordefinierte Gruppenrichtlinien und das Monitoring der einzelnen Systeme.
1200
1000
800
600
400
200
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 23: Entwicklung des TUM-PCs in 2014
6.4.3 MWN-MAC
In 2014 wurden die Arbeiten für den Aufbau eines Client-Management-Systems für Apple-Clients basierend
auf der Caspersuite der Firma JAMF für MAC OSX und iOS Systeme fortgesetzt. Die Caspersuite bietet
dabei die Möglichkeit der zentralen Verteilung von Software wie auch der Konfiguration der Clients. Für die
Erstellung der notwendigen Software-Pakete wurde in 2014 AutoPkg erfolgreich getestet und in die Umgebung übernommen. AutoPkg beschleunigt das Erzeugen der notwendigen Software-Pakete auf Basis von
„Recipes“, die von einer breiten Community erzeugt und bereitgestellt werden. Mit dem Angebot MWNMAC soll der zunehmenden Verbreitung von Apple Geräten auf dem Campus Rechnung getragen und das
kostenpflichtige Angebot des MWN-PCs erweitert werden.
6.5 Benutzerverwaltung und Verzeichnisdienste
6.5.1 Benutzerverwaltung für LRZ-Dienste
Im Zentrum der Benutzerverwaltung steht das LRZ-Identity-Managementsystem (LRZ-SIM) mit seinen Verzeichnisdiensten. Nach einem Überblick über die derzeit vergebenen LRZ-Kennungen und ihre Verteilung
auf die Hochschulen und LRZ-Plattformen wird über Entwicklungen von LRZ-SIM im Frontend, in den angebundenen Diensten und Plattformen sowie im LRZ-SIM-Serverbetrieb berichtet. Danach folgen der
Stand der Verzeichnisdienste-Kopplungen mit den beiden Münchner Universitäten sowie die Entwicklungen beim MWN Active Directory als zentralem Infrastrukturdienst im gesamten Münchner Wissenschaftsnetz. Das Kapitel schließt mit Neuigkeiten zur Authentifikations- und Autorisierungsföderation des DFN
(DFN-AAI), in der das LRZ als Dienstleister und Identity-Provider für die Münchener Universitäten fungiert.
6.5.1.1
Für LRZ-Systeme vergebene Kennungen
6.5.1.1.1
An Hochschuleinrichtungen vergebene Kennungen
Die folgende Tabelle gibt einen Überblick über die vom LRZ an Hochschuleinrichtungen vergebenen Berechtigungen, und zwar pro Dienst bzw. Plattform und mit Stand von Ende 2014. Für die LMU und die TU
München sind dabei außer den via Master User vergebenen Berechtigungen auch die Kennungen aufgelistet, die direkt an den Hochschulen vergeben und via CampusLMU bzw. TUMonline importiert wurden.
60
IT-Basisdienste
691
1.154
236
75
110
96
37
63
Bayer. Akademie der
Wissenschaften
422
119
293
396
–
24
17
28
6
–
11.555 10.364
1.879
4.739
881
118
394
539
160
55
2.728
–
–
–
–
–
–
– 1.228
571
151 1.110
507
197
LMU München
von CampusLMU
importiert
TU München
von TUMonline
importiert
34.744
–
–
8.585
8.559
–
20.576
– 33.213* 20.576
TSM
Webserver
WebDNS
Linux-Cluster
263
NeSSI
(NV-Portal)
PC/OnlineSpeicher
620
persönliche
Homepages
Mail
LeibnizRechenzentrum
Exchange
Einrichtung
VPN / WLAN
Tabelle 10: Vergabe von Kennungen für LRZ-Plattformen
–
–
–
–
–
–
Hochschule München
409
374
5.354*
–
39
–
76
5
6
3
andere bayerische
Hochschulen
810
288
–
2
240
10
9
12
10
3
5.303
3.068
350
1.858
33
53
66
76
46
20
26
1
–
–
14
–
1
1
3
–
–
–
–
–
428
–
–
–
–
–
112
15
–
47
32
–
–
9
1
–
83.162 23.051 41.780 31.500 3.131
851
824 1.876
776
341
Öffentlich-rechtliche
Einrichtungen
sonstige Einrichtungen
GridKooperationsprojekte
Nutzer des SuperMUC
Gesamt
*
inkl. Studierende (17.661 an der TU München bzw. 4.410 an der Hochschule München)
Nicht in der Tabelle enthalten sind die Kennungen für den Höchstleistungsrechner SuperMUC, da es hier
häufig Kooperationen gibt und daher keine klare Zuordnung zu einer Einrichtung möglich ist. Ende 2014
waren für diesen Rechner insgesamt 3.876 Kennungen vergeben, davon 1.060 für Projekte aus dem GridBereich.
6.5.1.1.2
An Studierende vergebene Kennungen
An der Ludwig-Maximilians-Universität und der Technischen Universität werden Kennungen für Studierende direkt an den Hochschulen vergeben und anschließend von dort ans LRZ übernommen (via CampusLMU bzw. TUMonline). Für Studierende anderer Münchner Hochschulen erfolgt die Vergabe individuell
und direkt durch das LRZ.
Ende 2014 hatten 95.382 Studierende eine Kennung am LRZ (Vorjahr: 91.922), die u.a. für die Dienste
VPN, WLAN und Mail genutzt werden konnte. Studierenden der LMU München, der TU München und der
Hochschule für Musik und Theater München stehen außerdem 40 GByte Online-Speicher in der MWN
Storage Cloud zur Verfügung (ab 2015: 50 GByte). Hier die Aufteilung auf die Hochschulen mit den meisten
Kennungen:
61
Tabelle 11: Vergabe von Kennungen an Studierende
Hochschule
53.248
39.937
Hochschule für Musik und Theater München
1.585
Hochschule für Fernsehen und Film München
348
Akademie der Bildenden Künste München
158
Hochschule für Philosophie München
52
Verwaltungs- und Wirtschaftsakademie München
11
FernUniversität Hagen
17
sonstige Hochschulen
26
Gesamt
6.5.1.2
Anzahl
Kennungen
95.382
Identity Management und Verzeichnisdienste
Das LRZ Identity-Management-System LRZ-SIM (LRZ Secure Identity Management) ist die Zentrale, ohne
die kaum noch ein Zugang zu den vielfältigen Dienstangeboten des LRZ denkbar ist. Hier laufen die für die
Authentifizierung notwendigen Kennungsdaten aus dem LRZ und den IDM-Systemen der Hochschulen
zusammen, hier sind die Zugriffsberechtigungen für den überwiegenden Teil der LRZ-Dienste zentral hinterlegt und über Authentifizierungs-Server abrufbar und nutzbar.
LRZ-SIM basiert auf einem Cluster von Verzeichnisdiensten (NetIQ eDirectory und OpenLDAP), deren
Datenbestände durch Konnektoren (sog. Treiber des NetIQ Identity Managers) live synchronisiert, transformiert und in die LDAP-Authentifizierungsserver sowie in die direkt angebundenen Plattformen provisioniert werden. Eine kurze Übersicht über die Infrastruktur folgt in Abschnitt 6.5.1.2.3. Als universelles Webfrontend dient das LRZ Id-Portal (Identity-Management-Portal, https://idportal.lrz.de) sowohl für die Benutzer als auch für die Master User, die LRZ-Betreuer, den Servicedesk und die Plattform-Administratoren.
6.5.1.2.1
Benutzerverwaltung und Id-Portal
Nachdem im Vorjahr ein Schwerpunkt der Weiterentwicklung von LRZ-SIM auf dem Datenschutz und der
Ausrichtung an Compliance-Vorgaben lag, wurden im Berichtsjahr Konzepte entwickelt und großteils umgesetzt, die den Aufwand in der Benutzer- und Projektverwaltung durch Umstellung von papiergebundenen
auf elektronische Verfahren reduzieren.
So ist es seit Dezember 2014 für LRZ-Benutzer nicht mehr erforderlich, die Benutzungsrichtlinien auf Papier beim zuständigen Master User zu unterschreiben. Die Zustimmung erfolgt nun vielmehr auf elektronischem Weg im Id-Portal. Dies ist nicht nur eine wesentliche Arbeitserleichterung für die Master User, sondern garantiert auch, dass die Zustimmung vor jeglicher Dienstnutzung tatsächlich abgegeben wird. Weiterhin müssen die Master User ebenfalls keine Erklärung mehr gegenüber dem LRZ unterschreiben und
einschicken. Stattdessen erhält jeder neue Master User automatisch eine Mail mit der Zusammenfassung
seiner Aufgaben und mit Hinweisen zu seiner Arbeit, sobald ihm der zuständige LRZ-Betreuer auf Veranlassung des Einrichtungsleiters in LRZ-SIM die Master-User-Rechte zuteilt.
Kontinuierliche Detailverbesserungen im Id-Portal tragen dazu bei, dass die Master User ihre Arbeit bei der
Vergabe und dem Entzug von Kennungen und einzelnen Dienstberechtigungen einfacher erledigen können, sei es durch klarere Hinweistexte, sei es durch eine geeignetere Vorauswahl von Dienstberechtigungen oder auch Warnungen, wenn die Deprovisionierung aufgrund weiterer Zuständigkeiten (TSM-Nodes,
Netzverantwortlichkeit) nicht sofort möglich ist.
Für Dienste- und Plattform-Administratoren bietet das Id-Portal seit Mitte 2014 eine neue Gruppenverwaltung, und zwar separat für jeden Dienst, der Gruppen benötigt. Diese Gruppenverwaltung beinhaltet zusätzlich eine Webschnittstelle für die automatisierte Pflege von Gruppen. Mit der Gruppenverwaltung wur-
62
IT-Basisdienste
den auch die Vergabemöglichkeiten von Berechtigungen und Kontingenten durch Plattform-Administratoren ausgeweitet. Dies wird zunehmend wichtiger für Dienste, bei denen eigene Antrags- und Genehmigung-Workflows vorgeschaltet sind, etwa bei der demnächst produktiv gehenden LRZ-Compute-Cloud.
Ein noch in Arbeit befindliches Entwicklungsprojekt wird die Betreuer spürbar entlasten, und zwar sollen
die jährlichen LRZ-Projektverlängerungen künftig auf elektronischem Weg erfolgen, was viel der bisherigen
Arbeit beim Kontrollieren und Übertragen der Angaben auf den Papierformularen einsparen wird. Allerdings
weist das Projekt einige Komplexität auf, da auch die Verlängerungsmöglichkeiten für Einrichtungsleiter
ohne LRZ-Kennung sowie die Delegation der Verlängerungsrechte vorgesehen werden müssen.
6.5.1.2.2
Entwicklungen bei der Anbindung von Plattformen und Diensten
Der große Mehrwert des Identity Managements für das gesamte LRZ ist die zentrale Aggregation, Pflege
und Verwaltung von Benutzerdaten und Zugriffsberechtigungen (Access Management). Davon profitieren
momentan 44 angebundene Plattformen und Dienste, mit jeweils wieder einer teils beträchtlichen Zahl von
Einzelsystemen.
Seit Frühjahr 2014 können Mitarbeiter der Hochschule München (HM) und seit dem Wechsel zum Wintersemester auch HM-Studierende das Exchange-Angebot des LRZ mit ihrer von der HM vergebenen Kennung nutzen. Dies wird durch die Datenkopplung des Identity-Management-Systems der HM mit LRZ-SIM
ermöglicht. Die Kopplung läuft über einen selbst entwickelten Konnektor nunmehr produktiv und stabil.
Nach der LMU- und TUM-Anbindung (siehe Abschnitt 6.5.2) ist das die dritte große Live-Anbindung eines
Quellsystems für Benutzer- und Berechtigungsdaten an LRZ-SIM.
Für die Exchange-Nutzung durch die HM gab es bedeutende Erweiterungen in LRZ-SIM selbst: Das Directory-Schema deckt nun alle Exchange-relevanten Aspekte in den Benutzerdaten ab, insbesondere getrennte Gruppen für Mailboxbesitzer und Sendeberechtigte. Die von Benutzern im HM-Portal eingestellte
Sichtbarkeit ihrer Kennungsdaten für bestimmte Benutzergruppen wird von der HM übernommen. Auch die
automatische Antwortmöglichkeit bei Funktionsmailboxen und bei Mailboxen von ausgeschiedenen HMAngehörigen kann über diese neue IDM-Anbindung gesteuert werden.
Darüber hinaus wurden in der HM-Anbindung technische Optimierungen umgesetzt wie die bevorzugte
Abarbeitung von denjenigen Eventtypen, die in der Benutzerwahrnehmung besonders dringend sind: Das
Neuanlegen von Kennungen und die Änderung von Passwörtern. Ein nächtlicher Abgleich aller Funktionsobjekte garantiert die Konsistenz mit den im HM-Portal vorgenommenen und angezeigten Einstellungen.
Die aufwendige und für Exchange notwendige Datenübertragung von LRZ-SIM ins MWN Active Directory
(MWN-ADS) wurde entscheidend beschleunigt, indem die Kennungen der großen Mandanten über eigene
parallele Kanäle provisioniert werden (siehe dazu Abbildung 24, provisionierte Systeme). Große Mandanten wie die Hochschule München sind somit nicht mehr beeinträchtigt durch zeitliche Verzögerungen, die
hohe Datenaufkommen in anderen Mandanten verursachen.
Für folgende weitere Dienste – neben MWN-ADS und Exchange – erfolgten im Laufe des Jahres 2014
ebenfalls Anpassungen in LRZ-SIM:
•
•
•
•
•
Um die Verwaltung und ggf. Freigabe von Speicherplatz im Archiv- und Backup-System (TSM) zu
ermöglichen, werden die TSM-Administratoren automatisch benachrichtigt, sobald Kennungen und
vor allem Projekte gesperrt, gelöscht oder zu einer anderen Einrichtung verlagert werden.
Die Anbindung des IT-Service-Managementsystems iET ITSM durch einen eigenen Treiber hat
sich bewährt. Verbesserungen konnten bei der Auswahl der primären Einrichtungszugehörigkeit
erreicht werden. Damit einher geht die passendere Wahl der primären Kontaktdaten von Kunden,
die mehr als eine Kennung in LRZ-SIM besitzen.
Für das Universe-Cluster bietet LRZ-SIM seit diesem Jahr Plattenplatz-Kontingentierung und die
Möglichkeit der Gruppenverwaltung.
Die SIM-seitigen Arbeiten für die Anbindung der LRZ-Compute-Cloud sind weitgehend abgeschlossen und produktionsreif. Berücksichtigt werden kann auch eine gemischte Berechtigungsvergabe
durch Administratoren auf Projektebene und Master User auf Kennungsebene. Es wird angestrebt,
die Zustimmung zu den Cloud-Benutzungsrichtlinien über Formulare im Id-Portal abzubilden - ähnlich wie schon die Zustimmung zu den Exportkontrollverordnungen bei HPC-Nutzung.
Das Visualisierungszentrum (V2C) ist prototypisch an LRZ-SIM angebunden. Wie bei der Compute-Cloud vergeben in erster Linie die Administratoren die Berechtigung auf bereits existierende,
importierte oder von Master Usern verwaltete Kennungen.
63
Im HPC-Bereich wurde der schon im Vorjahr definierte Lebenszyklus von SuperMUC-Projekten in allen
Punkten umgesetzt. So ist eine zeitnahe Deprovisionierung garantiert, um einerseits Platten- und Archivplatz zu sparen und andererseits aber denjenigen Projekten, die auch nach der aktiven Phase ihre Forschungsergebnisse aufbewahren wollen, langfristig den Archivplatz bereitstellen zu können. Um nach Ablaufen der SuperMUC-Zugangsberechtigung noch Zugriff auf die Daten zu gewährleisten, wurde ein neues
SSH-Gateway angebunden. Auch die differenzierten Mails – je nach Projekttyp, Projektstatus und Ablaufdatum – sind nun in allen Phasen aktiviert.
Erst in Planung befindet sich die Möglichkeit, zusätzlich zum TSM-Speicher auf Wunsch auch die Homeund Share-Speicherbereiche nach der aktiven Projektphase zu erhalten. Welche Services diesen sog.
„Data-only“-Projekten angeboten werden und wie diese Verwaltung in LRZ-SIM aussehen soll, ist noch
offen.
Bei den SuperMUC- und Grid-Projekten fand die nun jährliche Bereinigungsaktion statt. Es wurden alle
Projekte und Kennungen inkl. belegtem Speicherplatz gelöscht, deren Karenzzeit bereits mehr als ein Jahr
gedauert hatte. Außerdem wurden die Ländernamen in den Personen- und Einrichtungsanschriften vereinheitlicht, die nicht nur für Statistiken, sondern auch wegen der Exportkontrollverordnungen von Interesse
sind.
Schließlich wurde ein weiterer Infoservice zur Entlastung des Grid-Supports aufgesetzt: Grid-Benutzer, die
zum ersten Mal ein Benutzerzertifikat eingetragen bekommen (im Self Service oder über den Grid-Support),
erhalten eine automatische Mail mit dem Hinweis, dass sie ihre Kennung für Grid-Dienste zuerst durch
Zustimmung zu den Exportkontrollverordnungen auf einem eigenen Portal aktivieren müssen.
6.5.1.2.3
Server- und Dienstbetrieb
Die für LRZ-SIM und die oben beschriebene IDM-Dienste implementierte Infrastruktur ist in Abbildung 24
mit den vielfältigen Datenflüssen und Verflechtungen schematisch dargestellt. Die Pfeile geben die Hauptdatenflussrichtung an. Grüne Pfeile symbolisieren Push-Verfahren (Events, Trigger), blaue Pfeile Pull-Verfahren (Requests). Nicht dargestellt ist die Rückprovisionierung von Quotas und Verbrauchs/Belegungsdaten und weiteren Berechtigungen aus den angebundenen Systemen. Rote Beschriftungen zeigen, an welchen Komponenten die hauptsächlichen Weiterentwicklungen in 2014 stattgefunden haben.
64
IT-Basisdienste
Abbildung 24: Serverlandschaft und Einbindung des LRZ-SIM-Systems
Zusätzliche LDAP-Authentifizierungsserver wurden eingerichtet, um den unterschiedlichen Anforderungen
der angebundenen Dienste – i.e. hoher Durchsatz bei großer Request-Last von den Compute-Clustern
gegenüber kurzen Antwortzeiten für Einzelrequests z.B. von Mailsystemen – besser gerecht zu werden.
Diese Ressourcenanpassung war auch deshalb notwendig, weil das dedizierte Eduroam-Active-Directory
aufgegeben und die LRZ-Radius-Authentifizierung komplett auf die LRZ-SIM-Authentifizierungsserver umgestellt wurde.
Für Recovery-Zwecke bei den OpenLDAP-Servern wurde eine Möglichkeit zum schnellen Kopieren der
ganzen Replika-Datenbank als Alternative zur zeitintensiven Resynchronisierung bereitgestellt. Bei den
OpenLDAP-Replikas innerhalb des SuperMUC konnte ein sporadisch aufgetretenes Aktualisierungsproblem der Replikadaten gelöst werden.
Da bei der MWN-ADS-Provisionierung Staus in der Event-Verarbeitung ein wiederkehrendes Problem darstellen, wurden Monitoring-Skripte entwickelt, die solche Staus in den IDM-Treibern ermitteln. Automatische Mails informieren die jeweiligen Servicedesks, damit diese bei Benutzeranfragen gezielter Hilfe und
Auskunft zum Status einzelner Kennungen geben können.
65
Um die Stabilität und Sicherheit des LRZ-SIM-Systems im Dienstbetrieb zu gewährleisten, werden immer
möglichst zeitnah die aktuellen Versionen sowohl der Directory-Software (NetIQ eDirectory und OpenLDAP) als auch der IDM-Komponenten (NetIQ Identity Manager) installiert. Die 2014 bekannt gewordenen,
gravierenden Sicherheitslücken in Linux-Basiskomponenten wie der OpenSSL-Bibliothek (Heartbleed),
dem SSLv3-Protokoll (Poodle) und der Bash-Shell mussten auf den zentralen IDM- und Authentifizierungsservern besonders rasch geschlossen werden.
Mit der konsequenten Umstellung aller Administrator-Zugänge zu den Directory-Servern auf SIM-Kennungen mittels SSSD (System Security Services Daemon) konnten alle Root-Passwörter gelöscht werden.
Erlangung von Root-Rechten ist damit nur noch über den zuvor erfolgten Login mit einer persönlichen
Kennung möglich. Für die Administratoren der angebundenen Systeme wurde eine Möglichkeit geschaffen,
das Passwort ihrer sog. LDAP-Proxyuser im Self Service oder per Programmierschnittstelle regelmäßig zu
ändern.
6.5.2 CampusLMU und TUMonline
Annähernd zwei Drittel der aktiven Kennungen im Bestand von LRZ-SIM entstammen den zentralen Verzeichnisdiensten von LMU und TUM (vgl. Tabellen in Abschnitt 6.5.1.1). Die Daten dieser Benutzer werden
von IDM-Treibern automatisch und ohne lange Wartezeiten in LRZ-SIM synchronisiert. Darin enthalten sind
Attribute, die die Berechtigungen für die vom LRZ erbrachten Dienste bei den einzelnen Kennungen regeln.
6.5.2.1
CampusLMU-Anbindung
Schon seit Längerem steuert CampusLMU über sogenannte Entitlement-Attribute erweiterte Berechtigungen
sowohl in LRZ-SIM selbst (Linux-Berechtigung für die Physik, Mail-Berechtigung für die Biologie I) als auch
im MWN-ADS (Gruppenerzeugung und Mitgliedschaft in Gruppen). Mit den Entitlements sind in LRZ-SIM
außerdem Projektzuordnungen verbunden. Nachdem schon bisher bei Eintrag oder Änderung von Entitlements das Verschieben von LMU-Kennungen in das richtige Projekt automatisch geschah, konnte nun
auch bei Wegfall eines Entitlements das Zurückverschieben in die Sammelprojekte sowie die KontingentAnpassung oder der Kontingent-Entzug vollständig automatisiert werden.
Weitere Maßnahmen der Datensparsamkeit in LRZ-SIM wurden umgesetzt, so die Löschung aller Geburtsdaten von LMU-Angehörigen aus allen LRZ-Verzeichnisdiensten mit Ausnahme des Directory-Teilbaums,
auf dem der Shibboleth LMU-IdP basiert (siehe Abschnitt 6.5.4 zur DFN-AAI weiter unten).
6.5.2.2
TUMonline-Anbindung
Als Grundversorgung aller TUM-Angehörigen werden Berechtigungen für Mail/Exchange, VPN und den
Onlinespeicher von TUMonline zusammen mit der TUM-Kennung ans LRZ provisioniert. Diesen TUM-Kennungen können die jeweiligen Dienste-Administratoren bereits jetzt weitere Dienstberechtigungen wie Zugriff auf das Netzverantwortlichen-Portal, das WebDNS-Portal oder Zugriff auf das Cacti-Monitoring hinzufügen. Ziel wird es aber sein müssen, noch mehr LRZ-Dienste auf diese primäre TUM-Kennung zu bringen,
beispielsweise persönliche Homepages, primäre Linux-Cluster-Nutzung und/oder persönliche TSM-Nodes.
Die Abstimmung und Planung mit der TUM hierzu und auch zur Konsolidierung von Kennungen hat bereits
begonnen. Darüber hinaus ermöglicht die regelmäße Erstellung der Master-User-Liste und deren Versand
an die TUM u.a. die Bündelung mit den Aufgaben der TUMonline-Beauftragten.
2014 wurden zwei Einrichtungen in die TUM eingegliedert, zum einen die Hochschule für Politik und zum
anderen das, bisher an der BAdW angesiedelte, Deutsche Geodätische Forschungsinstitut (DGFI). Diese
Eingliederungen hatten insofern größere Auswirkung, als die Mitglieder zwar automatisch TUMonline-Kennungen erhielten, die bisher von Master Usern verwalteten Projekte mit Kennungen und Mailadressen zumindest für eine Übergangszeit erhalten und mit umgezogen werden mussten. Dabei stellte der Mandantenwechsel im MWN-ADS eine besondere Herausforderung dar.
6.5.3 MWN Active Directory
Als weiteren großen Infrastrukturdienst betreibt das LRZ für das MWN ein mandantenfähiges Active Directory (MWN-ADS). Das MWN-weit erreichbare ADS bildet unter anderem die Basis für zentrale Dienste wie
Exchange oder den zentralen Fileservice MWN-Speicher.
Dieses MWN Active Directory ist so angelegt, dass einzelne, große Institutionen wie LMU, TUM oder die
BAdW voneinander getrennt agieren können. Ziel ist es dabei, Synergien bei der Administration von Desktop-PCs zu erschließen und Mehrwerte im Funktionsumfang für Anwender und Administratoren nutzen zu
66
IT-Basisdienste
können. Mit dem MWN-ADS können alle Clients ab Windows 2000 verwaltet, Mac OS X und Linux-Systeme
an eine zentrale Nutzerverwaltung angebunden werden.
Jede Organisationseinheit erhält eine vordefinierte Unterstruktur (Organisational Unit, OU) im MWN-ADS.
Die Unterstruktur wird wiederum in Fakultäten und Lehrstühle weiter untergliedert. Auf diesen Ebenen können von einem sog. „Teil-Administrator“ des Kunden Computerkonten, Gruppenrichtlinien, Gruppen oder
Funktionskennungen eingetragen und verwaltet werden. Die Einrichtung dieser Organisationsstrukturen
wird stetig in Absprache mit den teilnehmenden Kunden angepasst. Damit es nicht zu Namenskonflikten
innerhalb des MWN-ADS kommt, wurde ein verbindliches Namenskonzept für Objekte im MWN-ADS entwickelt. Zur Erfüllung ihrer Aufgaben wird den Teil-Administratoren ein Set an Werkzeugen über zwei Terminalserver zur Verfügung gestellt. Die Benutzerkonten und zentralen Gruppen werden über die beiden
Metaverzeichnisse (LZRBVW, TUMonline) am LRZ gepflegt. Dabei kommen Softwarelösungen der Firma
NetIQ zum Einsatz.
Derzeit sind 9 (7) voneinander abgetrennte Mandanten im MWN-ADS eingerichtet mit rund 132.000
(115.000) Kennungen. In 2014 kamen neu, als eigenständige Mandanten, die Akademie der bildenden
Künste (AD) und die Staatliche Museen (SM) als Exchange-Nutzer hinzu.
Aus den Mandanten TUM, LMU, HMT (HS Musik und Theater), BVB (Bibliotheksverbund Bayern) und
BAdW sind rund 9.000 (6.000) Rechner ins MWN-ADS integriert. Es wurden bisher 710 (603) Teiladmins
aus 405 (361) Einrichtungen registriert und in 2014 haben sich an der Infrastruktur rund 49.000 (45.000)
verschiedene Nutzer angemeldet. Dabei wurden Dienste wie der MWN-Speicher, die Groupware Exchange
oder die Anmeldung an ins MWN-ADS integrierten Clientrechnern genutzt.
Die Provisionierung der Benutzerkonten aus den Metaverzeichnissen in das Active Directory erfolgt durch
den „Identity Manager Driver for Scripting“ von NetIQ, der Attributsänderungen an vom LRZ selbstentwickelte PowerShell Skripten auf ADS-Seite übergibt. Dadurch wird eine enorme Flexibilität beim Verarbeiten
und der Fehlerbehandlung von Ereignissen erreicht.
Auch in 2014 wurden die Skripte weiter angepasst und weiter verfeinert. Ein großes Augenmerk wurde
dabei auf die weitere Optimierung der Laufzeit einzelner Events gelegt, damit die Verarbeitung von Massenevents gerade zum Semesterwechsel beschleunigt wird. Hier kommt die Parallelisierung der einzelnen
Treiber zum Tragen. So werden nun die Events der TUM auf insgesamt 8 und die der LRZ-Benutzerverwaltung auf drei unabhängige Kanäle verteilt. So konnte die Verarbeitung der Events der TUM zum Semesterwechsel WS 14/15 auf ein Fünftel der Zeit reduziert werden.
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
Jan
Feb
Mrz
BADW
Apr
LM
Mai
Jun
TUM-PC
Jul
Aug
TUM-Rest
Sep
Okt
Nov
Dez
sonstige
Abbildung 25: Computerkonten im MWN-ADS in 2014
6.5.4 DFN-AAI/Shibboleth
Föderiertes Identity Management (FIM) auf Basis der Software Shibboleth ermöglicht es Benutzern, Webdienste, die außerhalb ihrer eigenen Hochschule oder Einrichtung angesiedelt sind, mit der lokalen Hochschulkennung zu nutzen. Den organisatorischen Rahmen für einen solchen Diensteverbund bildet die einrichtungsübergreifende Infrastruktur für Authentifizierung und Autorisierung des DFN (DFN-AAI). Wesentliche Vorteile dieser Authentifizierungsmethode sind für den Benutzer gegenüber konventioneller LDAPAnmeldung:
67
a) der bessere Schutz der persönlichen Daten, die nur bedarfsgetrieben und nur nach expliziter Genehmigung durch den Benutzer an genau den gewünschten Webdienst weitergegeben werden
(kein User-Provisioning auf Vorrat),
b) die erhöhte Sicherheit vor Phishing und Account-Missbrauch, da die Passworteingabe ausschließlich bei der Authentifizierungskomponente der Heimateinrichtung, dem sogenannten Identity Provider (IdP), stattfindet und nicht bei den vielen fremden Webdiensten (Service Provider, SPs).
6.5.4.1
Identity-Provider-Dienstbetrieb
Das LRZ betreibt in der DFN-AAI neben dem eigenen Identity Provider auch die IdPs für die LMU und die
TUM. Als Datenbasis nutzt der LMU-IdP das SIM-Import/Export-Directory, der TUM-IdP den TUM-eigenen
Authentifizierungsserver (siehe Abbildung 24 links unten).
In allen drei Identity-Providern wurde die Internationalisierung aller Webformulare und Seiten mit englischen Varianten fertiggestellt.
Einige Standard-Attribute wurden bzgl. der gelieferten Werte in Abhängigkeit des anfragenden Webdiensts
eingeschränkt. Beispielsweise werden von den Entitlements jeweils nur noch die dienstrelevanten Werte
übermittelt und der Rest unterdrückt.
Auch bei den Identity-Providern bestand – wie bei den Directory-Servern – rascher Handlungsbedarf nach
Bekanntwerden der SSL-Sicherheitslücken. In den Applikationscontainern der IdPs (Tomcat) konnte
SSLv3 wegen der Poodle-Sicherheitslücke sofort deaktiviert werden. Der Austausch der Serverzertifikate
wegen des Heartbleed-Bugs hatte bei einigen Service-Providern für Unregelmäßigkeiten gesorgt, blieb
jedoch, was die Authentifizierung betraf, ohne nennenswerte Auswirkungen auf die Benutzer. IdP-seitig
war allerdings der Umstieg auf die Java-VMs von Oracle notwendig, weil nur damit der reibungslose Abruf
der Metadaten aus den verschiedenen Föderationen weiterhin gewährleistet war.
6.5.4.2
Anpassungen für spezielle Service Provider
Betreiber von Webdiensten profitieren durch die „Shibbolethisierung“ und Beitritt in die DFN-AAI oder die
jeweilige hochschullokale Föderation von den Vorteilen der AAI-Lösung bzgl. Datenschutz, Datensicherheit
und Single Sign-on. Dafür waren, ähnlich wie in den Vorjahren, Abstimmungen und Anpassungen hinsichtlich der von den IdPs ausgelieferten Attribute erforderlich, oder auch eine Zusammenarbeit bei der Fehlersuche in der Anbindung.
Mit der LMU ist die Kooperation beim Aufbau eines zentralen Moodle-E-Learning-Systems (ELAB) hervorzuheben. Bei einigen schon länger betriebenen Webdiensten der LMU aus dem Bereich der virtuellen
Lehre, die in den Anfangszeiten der DFN-AAI eine Vorreiterrolle einnahmen, stand der Wechsel der Serverzertifikate an. Die neuen Zertifikate mussten rechtzeitig und parallel auch in der Metadatenverwaltung
der DFN-AAI publiziert werden. Insgesamt war die Nutzung des LMU-IdP etwas rückläufig, da die UniBibliothek seit Februar 2014 den Zugriff auf elektronische Zeitschriften, Medien etc. auf ein Zugangsverfahren mit Authentifizierung gegen den LMU-Verzeichnisdienst ("E-Medien-Login", EZProxy) umgestellt
hat. Grund hierfür war in erster Linie das mit Shibboleth-Zugängen verbundene Support-Aufkommen, das
die UB nicht mehr leisten konnte.
An der TUM ist eine ganze Reihe von neuen Service-Providern zu verzeichnen, die in die lokale Metadatenverwaltung aufgenommen wurden und erweiterte Attributsätze vom TUM-IdP bekommen: Dienste für
die Buchung und Zuteilung von Lehrveranstaltungen an Studierende, ein Webportal für Data-Mining-Wettbewerbe, Dienste für Vorlesungsaufzeichnungen, Server für Übungen zu Informatikvorlesungen, die OpenAccess-Managementplattform QOAM in der Uni-Bibliothek, und schließlich als externer Dienstleister
das Webshop-Portal StudiSoft der Uni Würzburg. Bei manchen SPs waren bisher nicht genutzte Attribute
aus den TUM-Verzeichnisdiensten für die Auslieferung per Shibboleth zu konfigurieren, z.B. gewisse Studiengangdetails (features of study) und organisatorische Zugehörigkeiten.
Schließlich wurden im LRZ-IdP Attributfreigaben eingebaut für das TeamDrive-System der Universität der
Bundeswehr, für die Nutzung der DFN-Webkonferenzen durch LRZ-Praktikanten, sowie auch für GéantKooperationspartner.
Die Inter-Föderation eduGAIN, ein weltweiter Zusammenschluss von nationalen AAI-Föderationen, ist mittlerweile stark gewachsen. Daher werden von DFN-Seite die gesammelten eduGAIN-Metadaten nun getrennt nach Identity- und Service-Providern bereitgestellt, um dem Größenproblem bei der Übertragung,
bei der lokalen Vorhaltung im Hauptspeicher und bei der Startup-Zeit des Shibboleth-Servlets zu begegnen.
68
IT-Basisdienste
6.6 Bibliotheksdienste
6.6.1 Arbeitsgruppe Bibliotheksdienste
Mit den Projekten „Rosetta“ zur Langzeitarchivierung und Bavarikon 2 zum Neuaufbau des Kulturportals
Bayern wurde es notwendig, eine abteilungsübergreifende Arbeitsgruppe „Bibliotheksdienste“ zu bilden.
Durch die ständige Kommunikation mit den Kooperationspartnern Bibliotheksverbund Bayern (BVB) und
Münchner Digitalisierungszentrum (MDZ) sowie Einbindung des Teams in deren größere Projekte können
Anfragen schneller bearbeitet werden und ungünstige Entscheidungen bzgl. der Nutzung der LRZ-Dienste
verhindert werden. Neben der direkten Abarbeitung von Aufgaben ist das Team auch in die Beratung und
Planung von Projektarbeitsschritten aktiv eingebunden. Diese enge Kooperation wird weiter ausgebaut um
die Antwortzeiten für Service-Requests in allen Themengebieten des Dienstleistungsumfangs zu optimieren, soweit die personellen Ressourcen es ermöglichen.
6.6.2 System- und Softwaremanagement
Durch die unterschiedlichen Voraussetzungen der Hersteller von Bibliothekssoftware ist es notwendig, Systeme unter Solaris 10, Suse Linux Enterprise und RedHat Enterprise Linux zu betreiben. Alle Hersteller
bieten Neu- und Weiterentwicklungen ihrer Bibliothekssoftware unter Linux (RHEL oder SLES), meist aber
nicht mehr für Solaris an. Daher war es wichtig System- und Softwaremanagementtools zu finden, die
RHEL und SLES unterstützen. Es wurde spacewalk (https://fedorahosted.org/spacewalk/) zum Softwareund Patchmanagement installiert. Für die Systemverwaltung und für das Konfigurationsmanagement
wurde Ansible (http://www.ansible.com) untersucht. Beide Tools sollen ab 2015 produktiv eingesetzt werden.
Tabelle 12: vom Team Bibliotheksdienste verwaltete Systeme
Betriebssystem
Solaris
SLES
RHEL + CentOS
Windows
Serversysteme
(incl. VMs)
153
173
19
20
6.6.3 Projekt Rosetta (Langzeitarchivierung)
Für das Projekt zur Langzeitarchivierung „Rosetta“, bei dem das LRZ mit dem BVB und dem MDZ kooperiert, hat Ende 2013 der Hersteller des Software Ex Libris mit der Bayerischen Staatsbibliothek einen Vertrag ausgehandelt, der die Nutzung der Software für alle bayerischen Universitätsbibliotheken zulässt. Für
3 Bibliotheken würde der Pilotbetrieb eingerichtet.
Außerdem wurde Ende 2014 zusammen mit dem Hersteller ein iterativer Prozess zur Optimierung der
Performance der Software inclusive ihrer Systemumgebung etabliert. Eine deutlich verbesserte Antwortzeit
des Web Frontends während der Ingests konnte schon erzielt werden.
6.6.4 Bibliotheksverbund Bayern (BVB)
6.6.4.1
Aufteilung Server- und Storagekomponenten auf Brandabschnitte
Die Aufteilung der Kernkomponenten für den Betrieb der Bibliothekssysteme auf zwei Brandabschnitte
konnte 2014 abgeschlossen werden. Voraussetzung dafür war die Installation eines Fibrechannel-basierten Storageclusters (Hersteller EMC, Baureihe VNX 5400), und die Migration der Daten. Der Storagecluster
von EMC besteht aus 4 Storageprozessoren mit je 16GB Cache, 22 SSDs (200GB) und 308 SAS Disks
(600GB, 15k). Die SSDs werden als FAST-Cache (Autotiering) betrieben. Die in der Abnahme gemessenen
Performancewerte konnten überzeugen, auch im Betrieb konnte eine Performancesteigerung festgestellt
werden.
Nach der Migration der Daten wurden die Solaris- und Datenbankclustersysteme auf die Räume verteilt.
Die Migration konnte weitgehend ohne Unterbrechungen durchgeführt werden.
6.6.4.2
69
Migration Multimediaserver
Die Migration des Multimediaservers (Software: Digitool von Ex Libris) für die Bibliotheken des Verbundes
von SPARC/Solaris auf RHEL wurde in Kooperation mit der Verbundzentrale des BVB und der Herstellerfirma durchgeführt.
6.6.4.3
Schulung BVB Anwendungsbetreuer
Zur Vorbereitung der anstehenden Migrationen, z.B. der Lokalsysteme, sowie zu speziellen Themen wurde
es notwendig, den Anwendungsbetreuern der Verbundzentrale des BVB spezielle Fortbildungen zu diesen
Themen anzubieten. Folgende Vorträge/Workshops wurden durchgeführt:
•
•
•
•
Grundlagen zu IPv6
Unterschiede Solaris – Linux
Solr und SolrCloud
TLS und Zertifikate
6.6.5 Münchner Digitalisierungszentrum (MDZ)
6.6.5.1
Projekt Bavarikon 2
Für den Relaunch des Kulturportals Bayern, Bavarikon 2, arbeitete das Bibliotheksteam eng mit Wissenschaftlern, Entwicklern und Projektleitern des MDZ zusammen. Die Kooperation begann zunächst mit regelmäßigen Jour Fixes und intensivierte sich über die Zeit hinweg auch mit außerordentlichen Projekttreffen
und Beratungsgesprächen am MDZ und LRZ.
Die gemeinsame Zusammenarbeit fruchtete in der Formierung einer Kommunikationsschnittstelle zwischen MDZ und LRZ, um die abteilungsübergreifenden Anforderungen am LRZ zu kanalisieren und deren
Umsetzung nach einheitlichem Standard koordinieren zu können. Für „Bavarikon 2“ konnte somit ein Netzkonzept erarbeitet werden, welches drei voneinander isolierte Umgebungen für Entwicklung, Staging und
Produktion vorsieht (siehe Abbildung 26: Bavarikon 2 - Produktion. Eines von drei Netzen).
Die Produktionsumgebung wird quasi readonly betrieben, das redundant ausgelegte Frontend ist vom
WWW über einen Loadbalancer erreichbar, um hohen Lastanforderungen gerecht zu werden. Alle Maschinen stehen in einem privaten Netz, welches nochmals über eine ASA-Firewall nach außen abgegrenzt ist.
Zusätzlichen Schutz bieten die lokal betriebenen Systemfirewalls. Die inhaltliche Redaktion geschieht in
der Staging-Umgebung, deren Topologie sich von der Produktivumgebung ableitet. Dazu befindet sich im
Staging-Bereich ein Content Management System (CMS), über das dedizierte Redakteure inhaltliche Veränderungen vornehmen können. Das CMS ist nur für einen bestimmten Personenkreis vom WWW aus
erreichbar. Die dritte Umgebung ist die Entwicklungsumgebung, die der Staging-Umgebung als Vorlage
dienen soll. Hier werden Entwicklungen, neue Softwareversionen und Systempatches getestet, bevor sie
auf das Staging und die Produktion angewendet werden.
Das in Kooperation mit dem MDZ ausgearbeitete und implementierte Konzept berücksichtigte also Verfügbarkeitskriterien, um die Funktion der Applikation auch bei hohen Anfrageaufkommen zu gewährleisten.
Des Weiteren wurden grundlegende Sicherheitsaspekte mit einkalkuliert, um Angriffe aus dem Internet zu
erschweren. Der Eintrittspunkt der weltweiten Kommunikation wurde minimal gehalten. Die Sicherheit der
Applikation wurde im Rahmen eines Penetrationstests festgestellt und verbleibende Verwundbarkeiten behoben.
Neben der architektonischen Konzeption wurde auch beschlossen, das Betriebskonzept der Bibliotheksdienste, wie es seit einigen Jahren für den Bibliotheksverbund Bayern herangereift ist, auch für Bavarikon
2 anzuwenden. Dies umfasst die generelle Reduktion von Rechten einzelner Benutzer sowie ihr zentrales
Management. Die Konfiguration und die Verwaltung der Maschinen werden von einer zentralen Instanz
gesteuert. Analoges gilt für die Verteilung von Systemsoftware und das Monitoring der Maschinen und den
darauf laufenden Diensten. Die Umsetzung des Projektes ist größtenteils abgeschlossen.
Mit dem voraussichtlichen Launch von Bavarikon 2 ist die Kooperation jedoch nicht beendet. Es ist geplant,
nach einer Reflexionsphase den Istzustand des Projektes zu erfassen und weitere Schritte zur kontinuierlichen Verbesserung zu initiieren. Dies umfasst neben weiteren Sicherheitsevaluationen auch die fortlaufende Verbesserung des Betriebskonzepts. Es ist angedacht, die Zusammenarbeit zwischen der Systemverwaltung der Bibliotheksdienste und den Administratoren des MDZ voranzutreiben, um in Zukunft Probleme gemeinsam an einer gemeinsamen Schnittstelle lösen zu können. Bavarikon 2 hat somit Vorbildfunktion und dient als Nucleus zur Restrukturierung der vielen, am LRZ gehosteten MDZ-Dienste.
70
IT-Basisdienste
Abbildung 26: Bavarikon 2 - Produktion. Eines von drei Netzen
Inhaltlich wird das Angebot unter Zuhilfenahme eines MDZ-eigenen Daten-Workflowtools und der Einbettung von streambaren Medien verbessert werden. Für die Zukunft ist geplant, die dreidimensionale Erfassung von Objekten und ihre Einspeisung in Bavarikon 2 voranzutreiben. Dazu sollen auch die Expertisen
des Visualisierungszentrums des LRZ genutzt werden.
6.6.5.2
Betriebskonzept MDZ
Mit dem sporadischen Auftreten von Sicherheitsvorfällen wurde seitens des MDZ der Wunsch nach einer
Restrukturierung und sichereren Verwaltung der MDZ-Dienste bekundet. Eine weitere Sprungfeder für die
Ausarbeitung eines neuen Konzepts sind die Entwicklungsarbeiten an einem Semantic Media Wiki, welches das MDZ in Kürze in Betrieb nehmen wird. Daraufhin wurden dem Kunden diverse Netzkonzeptionen
unterbreitet, die verschiedene Verfügbarkeits- und Sicherheitsaspekte berücksichtigen. Da es sich bei den
MDZ-Diensten um eine Mischung öffentlicher Angebote aber auch hoch performanter Backend-Dienste
handelt, wurde die Etablierung einer dreigliedrigen Netzsegmentierung beschlossen. Dies umfasst ein eigenes Netz für öffentliche Dienste, ein weiteres privates Netz für Backend-Dienste und ein drittes Netz für
Entwicklungsarbeiten (siehe Abbildung 27: Dreigliedrige Netzsegmentierung für MDZ-Dienste).
Eine eigens dafür konfigurierte virtuelle Firewall kontrolliert den Datenverkehr der drei Netze untereinander
und nach außen. Bisher wird die Firewall ausschließlich von dem Team Bibliotheksdienste des LRZ verwaltet. Die Maschinen in den Netzen verfügen ebenfalls über eine Systemfirewall. Aktuelle Entwicklungen
bei den Bibliotheksdiensten sehen vor, das Firewallmanagement der lokalen Firewalls von einer zentralen
Instanz aus zu kontrollieren.
Für das Einspielen betriebssystemkritischer Patches ist ein Baselinemanagement geplant, welches eine
konkrete inhaltliche und zeitliche Trennung zwischen Entwicklungs- und Produktinstanzen vorsieht.
71
Abbildung 27: Dreigliedrige Netzsegmentierung für MDZ-Dienste
Die Benutzerverwaltung soll den Bibliotheksdienste-Standards angegliedert werden und sieht den sicheren
Login per LRZ-SIM und ssh-Authentifizierungsschlüsseln vor, womit die Verwaltung von Benutzern und
deren Rechten an nur noch einer Stelle erfolgt.
Alle zum Betriebskonzept gehörenden Komponenten werden in einem Tikiwiki der Bibliotheksdienste dokumentiert, auf dessen Seiten, je nach Rechtevergabe, auch die Systembetreuer des MDZ zugreifen können.
72
Virtuelle Realität und Visualisierung
7 Virtuelle Realität und Visualisierung
Das Zentrum für Virtuelle Realität und Visualisierung (V2C) ist in den vollständigen Benutzerbetrieb übergegangen und wurde auch dieses Jahr für viele Forschungsprojekte und Veranstaltungen genutzt.
Abbildung 28: Das V2C mit seinen einzelnen Komponenten
7.1 Kooperationen
Mit interessierten Instituten der LMU und TUM wurde der Kontakt intensiviert und einige Projekte konnten
erfolgreich realisiert werden. Die Anwender kommen aus den Bereichen Archäologie, Kunstpädagogik,
Kunst, Zoologie, Genetik, Architektur, Maschinenbau, Anlagentechnik, Strömungsmechanik, Glaziologie,
Hydrometeorologie, Unterhaltung, Lehre, Informationsvisualisierung, Interaktion und Navigation, Big Data,
Scan Vergleich, Rekonstruktion, Paläontologie, Vernetzte Virtuelle Umgebungen, Seismologie, Geoingenieurswesen, Mensch-Maschine Interaktion sowie der Medizin.
Die Zusammenarbeit mit der University of Tokyo und der Tohoku University wurde fortgesetzt. Die erfolgreiche Zusammenarbeit im gemeinsamen Projekt der UfG, der LMU und des LRZ wurde in der Dezemberausgabe der Akademie Aktuell ausführlich beschrieben.
7.2 Forschung und Lehre
Im Bereich Virtuelle Realität und Visualisierung wurden in Zusammenarbeit mit der LMU eine Bachelorarbeit erfolgreich abgeschlossen. Die Lehrveranstaltung „Virtual Reality“ mit 60 Teilnehmern wurde im Sommersemester an der LMU abgehalten. Die besten Projekte der Lehrveranstaltung wurden an einem „Open
Lab Day“ der Öffentlichkeit vorgestellt.
Publikationen zum Thema Eingabeinterfaces zur Navigation wurden an der CHI in Toronto und auf der
öffentlichen Datenbank CoRR veröffentlicht.
73
Das Thema des Collaborative Design Platform Protocols in Zusammenarbeit mit der Architekturinformatik
der TUM wurde an der ISMAR in München und der ACM VRST in Edinburgh präsentiert.
EnergyVis, ein Werkzeug zur Darstellung von Sensordaten in VR Umgebungen mit dem Zweck der Analyse
zur Steigerung der Energieeffizienz, wurde auf der ACOMP in Saigon, Vietnam präsentiert.
Das im Februar 2013 begonnene Europäische Projekt „High Performance, Cloud and Symbolic Computing
in Big-Data Problems applied to Mathematical Modeling of Comparative Genomics“ (Mr.SymBioMath;
http://www.mrsymbiomath.eu) wurde erfolgreich fortgesetzt. Es beschäftigt sich mit der Verarbeitung großer Datenmengen innerhalb der Anwendungsbereiche der Bioinformatik und Biomedizin und ist daher interdisziplinär angelegt.
Eine Anwendung für die flexible Darstellung von Genomvergleichen wird zurzeit am LRZ entwickelt und
wird zur Visualisierung der Ergebnisse von Genomvergleichen eingesetzt. Typischerweise wird der Vergleich von zwei Genomen als Dotplot dargestellt, wobei je ein Genom auf der x- und auf der y-Achse aufgetragen wird. Für einen Abschnitt, der in beiden Genomen auftritt, wird entsprechend ein Punkt eingezeichnet. Die innovativen Aspekte dieser Anwendung beziehen sich vor allem auf den gleichzeitigen Vergleich von mehreren Genomen sowie auf die dreidimensionale Darstellung.
Hier wurden erste Forschungserbnisse an der IEEE InfoVis in Paris vorgestellt.
74
IT-Server-Infrastruktur
8 IT-Server-Infrastruktur
8.1 Linux-Server
8.1.1 Virtuelle Server
Im Jahr 2014 gab es eine Ausschreibung zur Erneuerung der Virtualisierungs-Infrastruktur auf Basis von
Blade-Systemen. Inklusive Nachbeschaffung sind 94 Blade-Server mit insgesamt 1.880 Kernen, 24 TByte
RAM und 675 TByte Hintergrundspeicher im Einsatz.
Die zwischenzeitlich über 1.200 unter Windows und Linux betriebenen virtuellen Server wurden unterbrechungsfrei auf die neue Hardware migriert.
Ein Teilbereich des VMware-Clusters wird für speicherintensive HPC-Anwendungen auf Blade-Servern mit
bis zu 512 GByte RAM genutzt.
Abbildung 29: Virtuelle Serverinstanzen am LRZ
8.1.2 Analyse von Log- und Diagnosedaten
Die im LRZ eingesetzte Analyseplattform „Splunk“ wurde in 2014 breitflächig auf alle zentralen Serversysteme verteilt. Die proaktive Erkennung von Trends und Fehlern ist somit sichergestellt.
8.1.3 Monitoring
Neben den vorhandenen Monitoring-Tools wird die Überwachungssoftware OMD zum Mittel erster Wahl
für die nahtlose Erfassung sämtlicher systemkritischer Prozesse.
8.1.4 Managed Hosting für hochschulstart.de
Auch dieses Jahr war geprägt vom reibungslosen Wirkbetrieb des „Dialogorientierten Serviceverfahrens“
für die „Stiftung Hochschulzulassung“. Das LRZ betreibt auf Basis von Managed Hosting die Plattform zur
deutschlandweiten Studienplatzvergabe.
75
8.2 Windows
Am LRZ werden derzeit rund 160 physische oder virtuelle Windows Server betrieben. Der Anteil der virtuellen Systeme liegt bei rund 90%. Es hat sich in den vergangenen Jahren wiederholt gezeigt, dass es unter
Umständen nicht sinnvoll ist, bestimmte Systeme zu virtualisieren. So werden die Mailbox-Server für die
Exchange-Infrastruktur mit physischer Hardware betrieben, um den Storage direkt anbinden zu können.
Aus Performancegründen werden noch ein SQL-Cluster und alle Domain Controller des MWN-Active Directory mit physischer Hardware betrieben, da die Leistungsfähigkeit der virtuellen Maschinen zu gering
ist. Auch verhindern bestimmte Anwendungen wie z.B. für das Gebäudemanagement am LRZ oder Überwachungskomponenten, die möglichst unabhängig von weiterer Infrastruktur betrieben werden müssen,
eine Virtualisierung.
Die momentan unterstützten Betriebssystemversionen am LRZ reichen von Windows Server 2008 bis zur
aktuellen Version Windows Server 2012 R2. Windows Server ist dabei das Basisbetriebssystem für verschiedene höherwertige Dienste am LRZ wie Active Directory, Exchange oder Terminalserver.
Installation, Pflege und Reporting der Systeme erfolgten über den zentralen Microsoft System Center Configuration Manager 2012 R2 (SCCM) am LRZ, der auch für die Clientsysteme Verwendung findet. Für Monitoring und Alerting findet der Microsoft System Center Operation Manager 2012 R2 (SCOM) von Microsoft
Verwendung, der mit seinen vorgefertigten Management Packs gezielt nicht nur das Betriebssystem, sondern auch die auf den Servern betriebenen Dienste wie Active Directory, Exchange oder MS SQL überwacht. Unterstützt wird das Monitoring der Hardware bei den physischen Servern durch die DELL Openmanage Suite, wodurch Hardwareprobleme direkt an den SCOM gemeldet werden.
76
Hochleistungssysteme und SuperMUC
9 Hochleistungssysteme und SuperMUC
9.1 Höchstleistungsrechner SuperMUC
9.1.1 SuperMUC Phase 2
Mit der Inbetriebnahme von Phase 2 des SuperMUC kommen zur jetzigen Peak-Performance von 3,2
Petaflops weitere 3,6 Petaflops an Rechenleistung hinzu (siehe Tabelle 13), die von insgesamt 86.016
Cores in 6.144 Intel Haswell-Prozessoren E5-2697 v3 erbracht werden. Das Kommunikationsnetz von
Phase 2 basiert auf Mellanox FDR14- und ConnectIB-InfiniBand-Technologie. Der bisherige Hauptspeicher
von 288 Terabyte wird um weitere knapp 200 Terabyte erweitert. Außerdem werden weitere 7,5 Petabyte
SAN/DAS User Storage zur Verfügung gestellt.
Tabelle 13: SuperMUC-Installationsphasen
System Part
Architecture
Processor Type
No. of Cores
Peak
TFlops
Memory
TBytes
el.
Power
kW
(avg.)
147,456
8,200
3,185.0
78.0
340.0
2,100
86,016
3,578.3
196.6
1,000
241,672
6,841.3
536.6
3,100
SuperMUC-Installationsphasen:
SuperMUC Phase 1 Infiniband Multicluster FDR10
Intel Sandy Bridge
Intel Westmere-EX
SuperMUC Phase 2 Infiniband Multic(2Q2015)
luster FDR14
Intel Haswell
Subtotal
Auch die Phase 2 des SuperMUC wird mit bis zu 45°C warmem Wasser gekühlt werden. Der Stromverbrauch konnte für Phase 2 noch einmal gegenüber dem der Phase 1 halbiert werden. Damit bleibt SuperMUC einer der energieffizientesten Supercomputer der Welt.
Bis Ende Dezember 2014 wurden fast alle Hardware-Komponenten der Phase 2 des Systems angeliefert
und mit dem Aufbau und der Integration begonnen. Da die Management-Infrastruktur bereits läuft, sind
viele notwendige Vorarbeiten zur Systeminstallation bereits durchgeführt worden. Erste Tests der neuen
I/O Infrastruktur sowie von einigen Compute-Knoten wurden durch IBM/Lenovo ebenfalls schon durchgeführt. Abbildung 30 zeigt einen Blick auf das neu installierte SuperMUC Phase 2 – System am LRZ.
Abbildung 30: Blick auf das neu installierte SuperMUC Phase 2-System
(Foto: Andreas Heddergott)
9.1.2 Das neue Intel Xeon Phi System SuperMIC
Abbildung 31: Racks des SuperMIC
77
78
In Zusammenarbeit mit IBM wurde 2014 das neue Intel Xeon Phi-basierte System SuperMIC mit einer Peak
Performance von 75 TFlop/s am LRZ in Betrieb genommen. SuperMIC besteht aus einem iDataPlex Rack
mit 32 Knoten. Jeder Knoten enthält zwei Ivy-Bridge Host Prozessoren E5-2650 mit jeweils 8 Cores @ 2.6
GHz und zwei Intel Xeon Phi Coprozessoren 5110P mit jeweils 64 Cores @ 1.1 GHz basierend auf Intels
neuer „Many Integrated Core“ (MIC) Architektur. In der folgenden Abbildung ist die Anbindung des Intel Phi
Systems an die restliche SuperMUC Infrastruktur dargestellt. Schwierig gestaltete sich die Bereitstellung
der NAS Home-Filesysteme auf den Coprozessoren selbst. Die auftretenden Probleme konnten aber mit
Hilfe der IBM-Betriebsunterstützung gelöst werden. Eine Anbindung an das parallele GPFS Filesystem ist
in der zweiten Hälfte 2015 geplant.
Abbildung 32: Netzwerk-Topologie des Intel Xeon Phi Systems
Einer der Hauptvorteile dieser neuen Architektur ist die Möglichkeit, die Coprozessoren mit den StandardProgrammiersprachen C, C++ und Fortran programmieren zu können. Auch die Parallelisierung kann mit
Standard-Parallelisierungstechniken wie MPI und OpenMP erfolgen. So müssen nicht – wie bei der
GPGPU-Programmierung – komplizierte Sprachen wie CUDA oder OpenCL erlernt werden, um Programme auf Intel MIC portieren zu können.
Interessierte Benutzer können über das LRZ Service-Desk Portal Zugang auf SuperMIC beantragen; Voraussetzung hierfür ist ein SuperMUC Account, der aber ggf. immer über ein Test-Projekt generiert werden
kann.
9.1.3 Das neue Remote-Visualisierungs-System für SuperMUC Benutzer
In Zusammenarbeit mit IBM wurde 2014 ein neues Remote-Visualisierungs-System in Betrieb genommen.
Für SuperMUC Benutzer stehen nun 7 dedizierte Server zur Verfügung (Dual-Socket Xeon E5-2690, Sandy
Bridge). Jeder Server ist mit 128 GByte RAM und einer NVIDIA K20X GPU ausgestattet. Über das ModulSystem ist der komplette Software-Stack des SuperMUC auf den Visualisierungs-Servern verfügbar. Das
System wird über eine eigene SLURM-Instanz verwaltet, die jeweils einen Server für einen Benutzer dediziert reserviert.
79
Aktuell sind folgende Softwarepakete für Remote Visualisierung vorhanden: Amira, Avizo, Blender, Maestro, Ensight, Paraview, PyMol, R, Vapor, Visit, VMD.
Zusätzlich wurde eine Browser-Applikation erstellt, die ohne Installation sofort funktioniert und es erlaubt,
das Remote-Visualisierungs-System des LRZ besonders unkompliziert (1-click) zu nutzen:
https://rvs.lrz.de/
9.1.4 Betrieb des Höchstleistungsrechners SuperMUC
Ein Schwerpunkt der Aktivitäten der Abteilung Hochleistungssysteme bestand in der weiteren Optimierung
des Betriebs des Höchstleistungsrechners SuperMUC und in der Aufnahme des Betriebs der mit Intel
Many-Integrated-Cores bestückten Partition (SuperMIC). Insgesamt ist nun ein stabiler und sehr produktiver Betrieb des SuperMUC erreicht worden und es konnten so herausragende Ergebnisse für die Wissenschaft erzielt werden. Das System ist sehr gut ausgelastet. Es gibt in allen Jobklassen immer wartende
Jobs. Um für einige Großprojekte den benötigten Durchsatz zu erreichen, mussten für diese Projekte temporär sogar dedizierte Ressourcen bereitgestellt werden. Für die verbleibenden, durch die Vorlaufphase
beim Starten paralleler Programme bedingten Leerstände wurden Konzepte entwickelt, die die zukünftige
Nutzung auch dieser Ressourcen durch kleine, ggf. auch vorzeitig beendbare Jobs zulassen.
Aus Gründen der Risiken für die Systemstabilität des Phase 1 Systems wurde entschieden, das Xeon Phi
System nicht in die Infiniband-Fabric des SuperMUC zu integrieren. Stattdessen wurde die Topologie des
SuperMIC-Verbindungsnetzwerkes im Laufe des August 2014 mittels zusätzlicher Mellanox-Switche auf
einen isoliert betriebenen Fat Tree umgearbeitet. Darüber hinaus wurde – in intensiver Zusammenarbeit
mit IBM sowie mit Unterstützung durch Intel – der gesamte Software-Stack aktualisiert, mit zahlreichen
Fehlerbehebungen und systemseitigen Verbesserungen.
Einen weiteren Schwerpunkt bildete im zweiten Halbjahr die Vorbereitung der Installation, Inbetriebnahme
und Abnahme der zweiten Phase von SuperMUC. Hierzu wurden die notwendigen Abnahmeprozeduren
mit IBM verhandelt und das Betriebskonzept erstellt. Bis Ende Dezember wurden fast alle Hardware-Komponenten der Phase 2 des Systems angeliefert und mit dem Aufbau und der Integration begonnen. Da die
Management-Infrastruktur bereits läuft, sind viele notwendige Vorarbeiten zur Systeminstallation bereits
durchgeführt worden. Erste Tests der neuen I/O Infrastruktur sowie von einigen Compute-Knoten wurden
durch IBM/Lenovo ebenfalls schon durchgeführt. Darüber hinaus wurden auf Haswell-EP-basierten Testknoten erste Analysen des Verhaltens der Architektur sowie des Energieverbrauchs von Applikationen
durchgeführt. Nach wie vor sieht der Zeitplan den regulären Nutzerbetrieb auf dem Phase 2 System frühestens im zweiten Quartal 2015.
An Problemen traten im Berichtszeitraum Out-of-Memory Situationen bei Mellanox-Infiniband-Treibern auf,
die aber kaum Auswirkungen auf Benutzerbetrieb hatten, da eine Hochverfügbarkeitslösung für diese Komponenten besteht. Das Problem konnte Anfang 2015 durch einen Upgrade endgültig behoben werden.
Ende 2014 kam es zu zwei längeren Unterbrechungen, verursacht durch einen Fehler bei der gebäudeseitigen Kühlungsinfrastruktur, bzw. durch einen Defekt an der dynamischen unterbrechungsfreien Stromversorgung. Diese Vorfälle zeigen, dass weiterhin an der Erhöhung der Zuverlässigkeit der LRZ-Rechenzentrumsinfrastruktur gearbeitet werden muss. Weiterhin wurde eine erhöhte Ausfallrate von Boards nach
Stromabschaltungen beobachtet. Hierzu wird eine intensive Untersuchung durch den Hersteller durchgeführt.
9.1.5 Auslastung
Abbildung 33 zeigt die Rechenzeitabgabe des SuperMUC im Vergleich zur maximal möglichen Abgabe
(ohne Berücksichtigung von Wartungen). Das System ist nun ständig voll ausgelastet. Leerstände von
Prozessoren gibt es praktisch nur durch Jobs, die auf freie werdende Knoten warten. Insgesamt wurden
im Jahr 2014 etwa 1.1 Mrd. Core-Stunden an Rechenzeit abgegeben. Gegenüber dem Jahr 2013 konnte
damit eine 10%ige Steigerung erreicht werden, was insbesondere darauf zurückzuführen ist, dass im Jahr
2013 umfangreiche Infiniband- Kabeltauschaktionen durchgeführt werden mussten.
In Abbildung 34 ist die Entwicklung der prozentualen Auslastung sowohl für die Fat als auch für die Thin
Nodes dargestellt. Der angestrebte Auslastungswert von 85% wurde 2014 noch nicht ganz erreicht.
80
Abbildung 33: Rechenzeitabgabe (in Core-Stunden).
Bis 3. Quartal 2012 nur Migrationssystem (Fat-Nodes), ab 4. Quartal 2013 Thin und Fat-Nodes
Abbildung 34: Prozentuale Auslastung
(Verhältnis der tatsächlichen zur maximal möglichen Rechenzeitabgabe)
81
9.1.6 Rechenzeit nach Fachgebieten
Eine Aufschlüsselung der Rechenzeitabgabe nach Fachgebieten ist in Tabelle 14 angegeben und wird in
Abbildung 35 dargestellt.
Tabelle 14: Verteilung der Rechenzeit nach Fachgebiet
Fachgebiet
Computational Fluid Dynamics
Astrophysics/Cosmology
Biophysics/Biology/Bioinformatics
Physics - others
Chemistry
Geophysics
Physics - High Energy Physics
Physics - Solid State
Engineering - others
Support/Benchmarking
Informatics/Computer Sciences
Engineering - Electrical Engineering
Meteorology/Climatology/Oceanography
Medicine
Crystallography
Mathematics
Engineering - Structural Mechanics
Anteil an Rechenzeit
31.15%
29.67%
10.67%
8.93%
5.77%
3.12%
2.63%
2.33%
2.18%
1.31%
0.91%
0.44%
0.33%
0.32%
0.17%
0.03%
0.03%
Abbildung 35: Verteilung der Rechenzeit nach Fachgebieten
82
Etwa jeweils 30% der Rechenzeit von SuperMUC werden von Programmen aus dem Bereich der Fluiddynamik und der Astrophysik benutzt. Die Rechenzeitnutzung durch Applikationen aus dem Bereich Lebensund Biowissenschaften ist in den letzten Jahren stetig gestiegen und konnte sich mit ca. 10% als drittstärkste Nutzungsgruppe etablieren. Weitere wichtige Benutzergruppen kommen aus der Physik (9%),
Chemie (6%), Geowissenschaften (3%) und der Hochenergiephysik (3%).
Der zeitliche Verlauf der Entwicklung der Nutzung durch unterschiedliche Fachgebiete ist in der folgenden
Abbildung wiedergegeben. Bemerkenswert sind die stärkere Nutzung durch die Fluiddynamik und der
Rückgang der Nutzung durch die Hochenergiephysik, insbesondere QCD.
Abbildung 36: Zeitliche Entwicklung der Nutzung von SuperMUC durch Fachgebiete
9.1.7 Jobgröße
Abbildung 37 zeigt die zeitliche Entwicklung der Nutzung des SuperMUC in Abhängigkeit von der Jobgröße
(Anzahl verwendeter Rechenkerne) dargestellt. Mehr als zwei Drittel der Rechenzeit wird an Jobs abgegeben, welche mehr als 1.024 Rechenkerne verwenden. Aus Abbildung 37 geht zudem hervor, dass mehr
als die Hälfte aller Jobs mehr als 2.048 Rechenkerne verwenden. Im Normalbetrieb werden derzeit nur
Jobs mit bis zu 32.768 Rechenkernen auf dem SuperMUC Phase 1 - System ausgeführt. Anwendungen
mit höheren Rechenkernanforderungen werden nur in dedizierten Blockbetriebszeiten oder nach Wartungen auf dem System verarbeitet. Die im Normalbetrieb von einer Anwendung maximal nutzbare Anzahl
von Rechenkernen soll aber nach Inbetriebnahme der Phase 2 deutlich erhöht werden.
83
Abbildung 37: Zeitliche Entwicklung SuperMUC-Nutzung in Abhängigkeit von der Jobgröße
9.1.8 Datentransfer
Durch die Intensivierung der Kollaboration zwischen den deutschen und europäischen Rechenzentren im
Rahmen von GCS und PRACE steigt auch die Anforderung, große Datenmengen zwischen den europäischen Rechenzentren und Wissenschaftsinstitutionen, aber auch weltweit zu transferieren. Daher steigt
die Nachfrage nach einer Software, die die vorhandene Bandbreite der vorhandenen Hochgeschwindigkeitsnetzwerke bestmöglich ausnutzt. Die besten Übertragungsraten liefert momentan das Datentransfertool GridFTP der Grid-Middleware Globus. Im Jahr 2014 wurden ca. 460 TByte per GridFTP von und
zum SuperMUC übertragen. Der Großteil der Daten, 79%, wurde zu den LRZ-Rechnern hochgeladen, nur
21% wurden heruntergeladen. Das Kommandozeilentool globus-url-copy wurde für 72% der Daten verwendet, 13% der Daten wurden mit dem Cloud-basierten point & click Dienst Globus Transfer übertragen.
Festzuhalten ist die gegenüber 2013 deutliche Zunahme der Nutzung der Kommandozeilenversion, welche
sehr leicht skriptbar ist.
Abbildung 38: Ca. 460 TByte wurden 2014 per GridFTP von und zum SuperMUC übertragen
84
9.2
Linux-Cluster
9.2.1 Betrieb
Da die Cluster-Systeme hardwareseitig keine Konfigurationsänderungen erfuhren, beschränkten sich die
Änderungen im Wesentlichen auf Pflegemaßnahmen (Tausch defekter Komponenten).
Größeren Umfang hatten die Änderungen an den betriebenen Software-Komponenten: Alle Systeme wurden im Laufe des Jahres auf das Service Pack 3 von SLES11 angehoben; bei den UV und ICE Systemen
wurde hierbei der Support von SGI zur Unterstützung herangezogen. Die Warteschlangen-Software
SLURM wurde auf eine aktuellere Version verbessert, die deutlich mehr Funktionalität sowohl auf Nutzerseite (z. B. Unterstützung von Array-Jobs) als auch auf der administrativen Seite (z. B. stabilisierte Schlummerfunktion für nicht genutzte Knoten) bietet. Die HPC-Software (Compiler, MPI, Bibliotheken und Tools)
wurde den üblichen Fehlerbehebungs- und Versions-Updates unterzogen.
9.2.2 Nutzung des Linux-Clusters
In den Jahren 2013 und 2014 wurde das Linux Cluster von folgenden Benutzern und Projekten für ihre
Simulationen eingesetzt:
Tabelle 15: Anzahl Nutzer und Projekte
Jahr
Benutzer
Projekte
2013
2014
2013 und 2014 zusammen
553
448
759
145
132
176
Die aus diesen Zahlen abzulesende stärkere Fluktuation bei den Benutzern gegenüber der Anzahl Projekte
lässt sich auf die Nutzung des Clusters durch Studierende im Rahmen ihrer Ausbildung an den Lehrstühlen
zurückführen.
Die Rechenzeitabgabe in Core-Stunden und Auslastung, d.h. Belegung von Rechenknoten der einzelnen
Clustersegmente durch Benutzerjobs, die nominale Verfügbarkeit der Clustersegmente, die Auslastung
sowohl bezogen auf die kalendarisch maximal mögliche Nutzung als auch unter Berücksichtigung der Wartungs- und Ausfallszeiten sind in Tabelle 16 für die Jahre 2013 und 2014 angegeben 1.
Tabelle 16: Auslastung und Rechenzeitabgabe in den Jahren 2013 und 2014
Cluster Segment
ICE
MPP
SERIAL
UV
Gesamt
Anzahl Jobs [Tausend]
(Mittelwert pro Jahr)
Abgegebene Rechenzeit [Mio Core-h]
(Mittelwert pro Jahr)
Anteil an der Gesamtrechenzeit
29.7
69.3
469.0
568.1
1136.2
3.8
20.7
6.3
14.6
45.6
8%
46%
14%
32%
100%
Verfügbarkeit des Segmentes
98%
98%
98%
97%
98%
Auslastung (bezogen auf kalendarisch maximal
mögliche Nutzung)
Auslastung (excl. Wartungs- und Ausfallszeiten)
80%
81%
81%
75%
79%
82%
83%
82%
77%
81%
Die Auslastung der Clustersysteme entspricht den üblicherweise für solche Systeme erwarteten Werten.
Die etwas schlechtere Auslastung des UV–Segmentes ist darauf zurückzuführen, dass hier überwiegend
größere Jobs gerechnet werden und die resultierenden Leerstände nicht durch Backfill kompensiert werden
konnten.
1
Weitere Statistiken zur Nutzung des Linux-Clusters: http://www.lrz.de/services/compute/statistik-linux/
85
Die nach Hochschulen und ggf. Fachbereichen aufgeschlüsselte Nutzung des Linux-Clusters am LRZ ist
in der folgenden Tabelle dargestellt. Schwerpunkte sind dabei in den Bereichen Geowissenschaften, Physik, Chemie, Biowissenschaften und Ingenieurwissenschaften zu erkennen.
Tabelle 17: Verteilung der Rechenzeit nach Institutionen in den Jahren 2013 und 2014
Institution
Fakultät oder Fachbereich
Bayerische Akademie der Wissenschaften
Kooperationsprojekte des LRZ
Bayerische Hochschulen und Fachhochschulen soweit nicht gesondert erfasst
Anteil an
Nutzung
0.7%
0.3%
0.4%
18.3%
Georg-Simon-Ohm-Hochschule Nürnberg
Katholische Universität Eichstätt
Universität Augsburg
Universität Bamberg
Universität Bayreuth
Universität Erlangen
Universität Regensburg
Universität Würzburg
Hochschule München
0.9%
Hochschule München
33.6%
Department Chemie Bereich Anorganische Chemie
Department Chemie Bereich Physikalische Chemie
Department für Geographie,LMU
Department Pharmazie
Fakultät für Biologie
Fakultät für Geowissenschaften
Fakultät für Mathematik, Informatik und Statistik
Fakultät für Physik
Genzentrum
Institut für Statistik
Kinderklinik und Kinderpoliklinik im
Dr. von Haunerschen Kinderspital
Klinikum der Universität München
Lehrstuhl für Experimentalphysik - Laserphysik
Medizinische Fakultät
Sektion Physik
Öffentlich-Rechtliche und Gemeinnützige Körperschaften
Hochschulnahe Einrichtungen
Department Chemie
Department für Biowissenschaftliche Grundlagen
Department für Ernährungs- und Lebensmittelwissenschaften
Forschungsneutronenquelle Heinz Maier-Leibnitz (FRM II)
Department für Pflanzenwissenschaften
Fakultät für Informatik
Fakultät für Physik
Forschungsdepartment Ingenieurwissenschaften für
Lebensmittel und biogene Rohstoffe
Institut für Astronomische und Physikalische Geodäsie,
Photogrammetrie, Kartographie
Anteil an
Nutzung
0.2%
0.9%
2.1%
0.1%
3.7%
0.4%
9.5%
1.4%
0.9%
0.3%
3.0%
0.1%
1.7%
1.1%
10.3%
0.1%
2.4%
1.3%
0.3%
0.1%
0.1%
0.1%
3.1%
9.6%
0.5%
0.5%
46.0%
10.9%
3.8%
2.4%
3.4%
0.1%
0.5%
0.3%
0.2%
0.7%
86
Institut für Energietechnik
Institut für Luft- und Raumfahrt
Institut für Maschinen- und Fahrzeugtechnik
Institut für Methodische Grundlagen
Institut für System- und Schaltungstechnik
Institut für Verfahrenstechnik
Institut für Werkstoffe und Verarbeitung
Physik-Department Experimentalphysik
Physik Department Theoretische Physik
TUM School of Management
Zentrum Mathematik
Gesamtergebnis (100% = 45.6 Mio Core-h/Jahr)
6.8%
13.5%
0.6%
0.1%
0.6%
0.3%
0.1%
0.6%
0.1%
0.1%
1.0%
100%
100.0%
Die Bedienqualität am Linux-Cluster lässt sich aus Abbildung 39 entnehmen. Hier ist der kumulative Anteil
an Jobs dargestellt, die nach einer bestimmten Anzahl von Stunden zur Ausführung kommen. In den parallelen Jobklassen kommen zwar etwa 50% aller Jobs nach 4 Stunden zur Ausführung, aber am MPPSegment müssen 35% länger als 24 Stunden auf die Ausführung warten. Deutlich schlechter als für die
parallelen Jobs sieht es für die seriellen Jobs aus. Hier kommen nur 20% innerhalb der ersten Stunde zur
Ausführung, 40% müssen länger als einen Tag warten und 20% müssen sogar länger als drei Tage warten.
Die Rechenkapazitäten am Linux-Cluster sollen deshalb im Jahr 2015 erneuert und deutlich ausgebaut
werden, damit sich die Bedienqualität sowohl für parallele als auch serielle Jobs verbessert (siehe Kap.
9.2.3).
Abbildung 39: Kumulativer Anteil von Jobs in Abhängigkeit von der Wartezeit
9.2.3 Antrag zur Ersetzung veralteter Komponenten des Linux-Clusters
Einen Schwerpunkt im Berichtszeitraum bildete der Antrag auf Ersetzung technologisch veralteter Segmente des Linux-Clusters, mit dem auch eine Erhöhung der Energieeffizienz durch Warmwasserkühlung
87
sowie der Sekundärnutzung der Abwärme durch Bereitstellung von Kühlinfrastruktur auf Basis von Adsorptionskühlung erreicht werden soll. Der erste Teil des Antrages (landesfinanziertes Großgerät nach Art. 143c
GG) wurde bereits genehmigt. Die Installation des landesfinanzierten HPC-Clusters auf Basis von SuperMUC Phase 2 – Technologie wurde noch im Dezember 2014 begonnen. Für die Phase 2 (Forschungsgroßgerät nach Art. 91b GG) wurden von den Gutachtern weitere Nutzungsnachweise eingefordert. Hierzu
hat das LRZ im Herbst eine Benutzerumfrage durchgeführt. Die Mehrheit der Befragten betont, dass die
Nutzung des Linux-Clusters einen unverzichtbaren Bestandteil des Arbeitsablaufes ihrer Forschungsaktivitäten darstellt.
Aus der Umfrage wird auch ersichtlich, dass in Zukunft in vielen wissenschaftlichen Applikationen große
Datenmengen generiert werden. Durch die hohe Parallelisierung der Anwendungen wird I/O (Input/Ouput)
immer mehr zum Flaschenhals. Die Anbindung an ein paralleles Dateisystem (z.B. Lustre, GPFS) wird es
erlauben, auch die Ein- und Ausgabezeiten von Anwendungen zu analysieren und zu optimieren. Außerdem müssen diese Daten meist aufbereitet und visualisiert werden. Hierzu steht eine Anbindung des Clusters an Remote-Visualisierungssysteme bereit.
Das Linux-Cluster bietet mit seiner Größe und Hardware für diese Aufgaben eine optimale Plattform. Dies
gilt vor allem für die relativ neuen Benutzergruppen aus dem Bereich der Bio- und Lebenswissenschaften.
Im Verlauf des zweiten Halbjahres 2014 wurde speziell auf die Biologie im Forschungszentrum Martinsried
zugegangen, um die dortigen Anforderungen an Rechenleistung (HPC und Cloud), Speicherkapazität und
Netzanbindung kennenzulernen und besser unterstützen zu können.
9.3
Applikations- und Benutzerunterstützung im Bereich HPC
9.3.1 Supportanfragen
Zum ersten Mal ist ein deutlicher Rückgang der Anzahl von Supportanfragen im Bereich HPC zu verzeichnen – obwohl die Anzahl der Benutzer und die Anzahl der eingesetzten Hardwaresysteme und Softwarekomponenten weiter ansteigen. In den Jahren zuvor hat das Wachstum zu einer hohen Arbeitsbelastung
vor allen in den Gruppen Applikationsunterstützung und HPC-Systeme geführt. Die Gründe für diesen
Rückgang sind sicherlich vielfältig, wesentlich dürften jedoch folgende Prunkte sein:
•
•
•
•
Weitgehend etablierter Routinebetrieb am SuperMUC und am Linux-Cluster
Gute Stabilität der eingesetzten Hard- und Softwarekomponenten
Umfangreiche Web-Dokumentation des LRZ, Kurse und Schulungen
Einheitliche Betriebssystem- und Programmierumgebung
1400
1166
1200
1000
838
800
600
574
625
2008
2009
1225
1076
934
400
200
0
2010
2011
2012
2013
2014
Abbildung 40: Entwicklung der Anzahl von Supportanfragen im Bereich HPC
88
9.3.2 Benutzerverwaltung für die Hochleistungssysteme
Neben den klassischen Arbeiten der Benutzerverwaltung wie Organisation der Begutachtung der Rechenzeitanträge, Verwaltung der Benutzeraccounts und Rechenzeitabrechnung kamen im Berichtsjahr durch
die stark gestiegene Anzahl von Anträgen noch umfangreiche technische Begutachtungsaufgaben für die
Rechenzeitvergaben über die Calls von PRACE, GAUSS und KONWIHR hinzu.
9.3.3 Software für HPC Systeme
Das umfangreiche Software-Portfolio des LRZ wird laufend gepflegt und aktualisiert. Insbesondere die Bereiche Materialwissenschaften, Chemie und Lebenswissenschaften stellen hohe Anforderungen, weil hier
viele Anwender die Applikationen nicht selber entwickeln, sondern auf fertig bereitgestellte Programme
angewiesen sind. Speziell im Bereich der Lebenswissenschaften wurden weitere Anstrengungen unternommen, Bioinformatik- und Workflow-Tools sowohl auf den Hochleistungsrechnern als auch auf der LRZ
Test-Cloud zur Verfügung zu stellen.
Insbesondere im Bereich der Quantenchemie erfolgten Aktualisierungen, Erweiterungen und neue Releases von Wien2K, Turbomole, Quantum Espresso, CPMD, CP2K, GROMACS, GAUSSIAN, sowie zusätzliche Pakete wie GAMESS, VASP und Schrodinger. Im Bereich der CFD (Computational Fluid Dynamics)
sind neue Versionen von Ansys, OpenFoam, CFX und Fluent erschienen, mit Verbesserungen im Bereich
der parallelen Verarbeitung.
9.3.4 Kurse und Ausbildung
Der hohe Stand des Aus- und Weiterbildungsangebots mit den etablierten Kursen zu Programmiersprachen und Programmentwicklung, Parallelisierung und Optimierung, Fluid-Dynamik sowie Life-Sciences und
Visualisierung wurde auch in diesem Jahr weiter ausgebaut. Eine Reihe von Kursen wurde im Rahmen des
PRACE Advanced Training Centre (PATC) Programms angeboten, teilweise auch in Zusammenarbeit mit
den Kollegen des Regionalen RechenZentrums Erlangen (RRZE).
9.3.4.1
Intel MIC & GPU Programming Workshop
Als PATC Kurs wurde am LRZ vom 28.-30. April 2014 ein Intel MIC & GPU Programming Workshop mit
Schwergewicht auf der MIC-Programmierung veranstaltet. Den Kursteilnehmern wurden von LRZ-, RRZEund Intel-Dozenten verschiedene Programmiermodelle (CUDA, OpenCL, OpenACC, Python, Intel Offload,
MKL, MPI, Intrinsics etc.) und Optimierungstechniken vorgestellt. In Hands-On Sessions auf dem LRZGPU-Cluster und erstmals auch auf dem neuen SuperMIC-Cluster am LRZ konnten die Teilnehmer das
vermittelte Wissen selbst testen.
9.4
Application Labs
In diesem Jahr hat das LRZ vier Applications Labs gegründet:
• Astro- und Plasmaphysik
• Lebenswissenschaften
• Geowissenschaften
• Energie und Umwelt
Ziel ist es, eine stärkere Zusammenarbeit mit und besseren High Level Support für Wissenschaftlicher in
diesen für das LRZ strategischen HPC-Anwendungsfeldern zu etablieren. Die Application Labs zielen darauf ab, die Kooperation und Kommunikation zwischen dem LRZ und den Wissenschaftlern aus den verschiedenen Anwendungsgebieten zu verbessern. Die bessere Verzahnung von Anwendungsgebieten und
Rechenzentren gewinnt zunehmend an Bedeutung, da die jeweiligen Wissenschaftsdisziplinen sehr unterschiedliche Hardwareanforderungen haben.
9.4.1 AstroLab (πCS Astro)
Als erste größere Aktivität des Astrolabs ist hierbei die weitreichende Zusammenarbeit mit PD Dr. Dolag
(LMU Sternwarte) und seiner Gruppe zu nennen, welche sich in den letzten Jahren entwickelt hat. Aus
dieser ergab sich die konkrete Zusammenarbeit bei folgenden Projekten: SuperCAST, Magneticum, das
Pilot-Projekt Magneticum-Daten, ein IPCC-Projekt zur Gadget Portierung / Optimierung auf Intel-Xeon-Phi
89
und ITN-Exasim. Es konnte ein Doktorand für ein Projekt zu Skalierungsoptimierung von GADGET gewonnen werden. Dieses findet im Rahmen der Zusammenarbeit des LRZ mit dem Excellence Cluster Universe
statt. LRZ Mitarbeiter aus dem Astrolab-Team waren an der Vorbereitung und Durchführung des vom
Excellence Cluster Universe organisierten GPGPU Workshop für die Astrophysiker (14./15. April 2014)
beteiligt.
Des Weiteren wurde eine Zusammenarbeit mit den Astrophysikern der Arbeitsgruppe von Prof. Mohr (LMU
Sternwarte) begonnen, die sich mit den Themen Optimierung einer Datenbank-Anwendung für astrophysikalische Datenauswertung mit Efficient Job Scheduling, sowie Memory Optimised Job Chaining befasst.
Im Rahmen des ersten SuperMUC Review Workshops wurde ein Technical User Forum Meeting mit wissenschaftlichen Nutzern aus dem Gebiet der Astrophysik veranstaltet, welcher sehr gut besucht war.
Im November fand ein erstes Treffen in Vorbereitung einer zukünftigen Zusammenarbeit mit Lehrstuhl von
Prof. Sonnendrücker (TUM Mathematik/IPP) erfolgreich statt. Die Arbeitsgruppe von Prof. Bader (TUM
Informatik) hat unter Beteiligung des LRZ-Astrolabs im Rahmen der EU-Horizon2020-Initiative einen Antrag
für das Projekt ExaHyPE gestellt. In ersten Hälfte des Dezembers 2014 wird das LRZ Astrolab den ersten
High Level Support Call veröffentlichen, bei dem Wissenschaftler Unterstützung des LRZ bei zukünftigen
Projekten beantragen können.
9.4.2 BioLab (πCS Bio)
Bei den Anforderungen aus dem Bereich der Lebenswissenschaften ist der deutlich höhere Hauptspeicherbedarf pro Core bzw. Nodes sowie eine exponentiell steigende Datenmenge zu nennen. Um sich auf diese
Bedürfnisse einzustellen zu können, ist eine engere Zusammenarbeit mit den Wissenschaftlern der entsprechenden Disziplinen unumgänglich. Beispielsweise werden für die neuen Sequenzierungsmethoden
in der Bioinformatik sehr rasch immer neuere Applikationen entwickelt, während andere Methoden bereits
wieder aufgegeben werden. Zudem werden viele Applikationen, die sich mit einer speziellen Art von Analysen befassen, zu sogenannten 'Toolboxes' zusammengefasst und von den Entwicklern als fertige virtuelle
Images zur Verfügung gestellt. In diesem Umfeld erweist sich häufig der Einsatz von virtuellen Maschinen
als besonders hilfreich, die diese Images laden können und somit die Applikationen ohne Portierungsaufwand umgehend verwenden können. In diesem Zusammenhang wurden auf der LRZ-Cloud z.B. mehrere
Pilotprojekte mit der Toolbox QIIME (Quantitative Insights Into Microbial Ecology) durchgeführt, die Analysemethoden für Gensequenzierungsdaten zur Verfügung stellt. Die Nutzer von QIIME kamen dabei vom
Klinikum der Universiät München sowie dem Pettenkofer Institut.
Im Rahmen der Software-Initiative von KONWIHR werden in diesem und dem kommenden Jahr drei Projekte aus dem Bereich Lebenswissenschaften gefördert. Die Software-Initiative zielt darauf ab, in enger
Zusammenarbeit zwischen Forschungsgruppen und Rechenzentren, die effiziente Nutzung von HPC-Ressourcen durch die Anwendungswissenschaftler zu verbessern. Zudem sollen die Rechenressourcen auch
für Forschergruppen ohne fundierte HPC-Kenntnisse zugänglicher und leichter nutzbar werden. Die Software-Initiative ergänzt daher die Tätigkeiten der Application Labs am Leibniz-Rechenzentrum.
Die teilnehmenden drei Projekte stammen in diesem Jahr von Forschergruppen der Ludwig-MaximiliansUniversität sowie der Technischen Universität München. Das erste Projekt in der diesjährigen KONWIHRInitiative wird von der Gruppe um Leibniz-Preisträgerin Prof. Dr. v. Mutius vom Haunerschen Kinderhospital
durchgeführt, welches Teil des Universitätsklinikums der LMU ist. Das Projekt beschäftigt sich mit der Analyse des Mikrobioms bei Asthmapatienten im Kindesalter. Das zweite Projekt ist ebenfalls Im Bereich Genomanalyse anzusiedeln und wird von der Gruppe von Professor Rost der Fakultät für Mathematik und
Informatik an der TUM bearbeitet. Es behandelt die Analyse des Effekts von Sequenzvariationen auf die
Proteinbildung. Im letzten Projekt, das von PD Gerald Mathias der Fakultät für Physik an der LMU eingebracht wurde, wird eine Software weiterentwickelt, welche das Verhalten von Proteinen in ihrer Lösungsmittelumgebung simuliert
9.4.3 GeoLab (πCS Geo)
Mit dem Application Lab der Geowissenschaften πCS Geo sind in 2014 mehrere Projekte assoziiert. So
wurden innerhalb des EU-geförderte VERCE-Projektes (Seismologie) Fortschritte in der Entwicklung der
VERCE-Plattform für eine benutzerfreundliche Nutzbarkeit von HPC-Ressourcen für Seismologen erzielt.
Innerhalb des DEEP-ER EU-Projektes (Exascale) wurde die HPC-Applikation SeisSol, maßgeblich in der
LMU/Geophysik und TUM/Informatik entwickelt, mit der Unterstützung des LRZ weiter verbessert und auf
die Nutzung auf dem DEEP-ER Exascale-Prototyp vorbereitet. Mit Unterstützung des LRZ Extreme Scaling
Workshop auf SuperMUC konnte eine rekordverdächtige Rechenleistung von 1,42 PFlops/s erreicht werden, mit der die TUM/Informatik den PRACE-Award 2014 gewann und als Finalist dem Gorden Bell Award
90
greifbar nahe kam. Ein erstes Open-Source Release von SeisSol wurde im August 2014 veröffentlicht. Im
Bereich der Hydrometeorologie ist das Drihm-Projekt IT-seitig durch das LRZ unterstützt worden. Des Weiteren wird im Rahmen des Alpenobservatoriums/VAO-II seit Projektstart im Dezember 2014 das LRZ Alpen-Datenanalysezentrum (Alpen-DAZ) weiter gefördert. Für den Bereich der Klimaforschung konnte der
inzwischen erfolgreiche Projektantrag KlimEx gestellt werden mit Projektstart April 2015. Außerdem wurde
mit dem Antrag EnCompAS ein Antrag für ein Exzellenszentrum für Umweltwissenschaftliche Berechnungssoftware im Rahmen der Horizon 2020 Ausschreibung der EU vorbereitet, welcher inzwischen fristgerecht eingereicht worden ist. Der ebenfalls eingereichte EU Projektantrag Polde ist leider inzwischen
abgelehnt worden. Weitere Vorarbeiten für Projektanträge sind geleistet worden.
Das Potential einer direkten Zusammenarbeit eines geowissenschaftlichen Fachbereichs mit dem LRZ ist
meist groß, aber oftmals nicht bekannt. Um dieses Potential zu vermitteln, wurden im Jahr 2014 mehrere
Informationsveranstaltungen durchgeführt. Hauptzielgruppe dieser Werbeinitiative sind lokal ansässige geowissenschaftliche Arbeitsgruppen mit dem Ziel, sie für Zusammenarbeiten zu gewinnen und/oder existierende Kooperationen auszubauen. Seitens des LRZ wurden dabei LRZ-Infrastruktur, LRZ-Dienste und Projekt-Highlights präsentiert, während die Gäste einen Kurzabriss aktueller Forschungsarbeiten, Prozesse
und eingesetzte Software-Tools präsentierten. Daraus konnten individuelle Anforderungen an die IT-Infrastruktur und IT-Dienste abgeleitet und Ansätze für zukünftige Kooperationen innerhalb des πCS Geo aufgezeigt werden. Fachlich und methodisch gesehen sind die Geowissenschaften insgesamt ein weites Feld.
Zunehmend unerlässlich ist eine interdisziplinäre Arbeitsweise, um gegenwärtigen und kommende Forschungszielen gerecht zu werden. Erwartungsgemäß ist das in den Arbeitsgruppen vorhandene IT-KnowHow, die verwendeten Software-Tools, Arbeitsprozesse und Ressourcen sehr heterogen. Es zeigt sich,
dass es in dem einen Bereich bereits um die Optimierung und Integration existierender Tools und Workflows geht, während in anderen Bereichen die Spezifikation der Anforderungen und grundlegende Nutzung
der Ressourcen bereits eine Herausforderung ist. Unabhängig davon ermöglicht eine effiziente Erschließung der LRZ-IT-Infrastruktur oftmals ganz neue Forschungsperspektiven (und Herausforderungen).
9.4.4 Energie und Umwelt
Aufgrund der hohen gesellschaftlichen Relevanz, aber auch durch die zunehmende Bedeutung dieses Bereichs in der Wissenschaft, wurden in 2014 einige Anstrengungen unternommen, das Thema „Umwelt und
Energie“ am LRZ in den Vordergrund zu rücken. Zu diesem Zweck wurden Wissenschaftler aus den entsprechenden Bereichen an das LRZ eingeladen, um ihnen das Dienstleistungsangebot zu präsentieren
und um weitergehenden Kooperationsmöglichkeiten zu diskutieren. Aus diesen Veranstaltungen resultierten mehrere Forschungsanträge bei unterschiedlichen Fördergebern. So wurde beim Bay. Umweltministerum neben dem VAO-Antrag (s.Abschnitt 2.4.15) eine Skizze für eine Untersuchung von Extremwetterereignissen aufgrund des Klimawandels (KlimEx) unter Federführung der LMU (Prof. Ludwig) eingereicht. Daneben beteiligte sich das LRZ an zwei Anträgen im europäischen Forschungsrahmenprogramm
Horizon 2020. Ebenfalls unter Federführung der LMU (Prof. Dingwell) wurde das Projekt GIGANTIS zu ITUnterstütung der europäischen Solid Earth Community EPOS beantragt, unter Leitung der BOKU Wien
(Prof. Wenzel) das Projekt POLDE, das die Gebäudesicherheit nach Erdbeben im Fokus hat. Weitere Anträge, die in 2015 eingereicht werden sollen, befanden sich bereits in Vorbereitung.
Außerdem beteiligte sich das LRZ an einem Workshop der von der TUM ins Leben gerufenen internationalen Expertengruppe zur Bewahrung des Erdsystems (ISEP), präsentierte Forschungsergebnisse auf der
General Assembly der European Geoscience Union, nahm teil am „3rd Annual Forum of the EU Strategy
for the Danube Region“ sowie an einer Veranstaltung der BayFOR zum Thema „Energie und Umwelt“, um
weitere Kontakte in diesem Bereich zu knüpfen.
In dem sehr weit gefassten Bereich „Energie“ wurden 10 Lehrstühle kontaktiert, um auszuloten, ob die
Services des LRZ für die jeweiligen Forschungsvorhaben hilfreich sein könnten. Bei zwei Lehrstühlen ergaben sich Anknüpfungspunkte, woraufhin die Zusammenarbeit durch detailliertere gegenseitige Vorstellungen vertieft wurde.
•
•
Im Juli 2014 stellte die Arbeitsgruppe von Prof. Jacobsen im Rahmen eines Research Days ihre
Arbeiten dem LRZ vor. Daraufhin entwickelte sich mit dem Lehrstuhl Prof. Hans-Arno Jacobsen,
TUM Informatics 13, eine aktive Zusammenarbeit in den Bereichen Cloud Computing und verteilte
Datenbanken sowie Nutzung des Linux Clusters.
Der „Geothermal Energy Group“ von Prof. Einsiedl, vertreten durch Dr. Kai Zosseder, eröffneten
die Rechenmöglichkeiten am LRZ den Zugang zu neuen Fragestellungen. Dazu wurden einige
Forschungsanträge gemeinsam erarbeitet, die jedoch noch auf eine Genehmigung der Fördergeber warten.
91
10 Datenhaltung
10.1 Überblick Datenhaltung
In gewisser Hinsicht begann das Jahr mit einem Schlussstrich: Nach 23 Jahren Betrieb wurden im Januar
die letzten AFS-Fileserver abgeschaltet. AFS wurde am LRZ über viele Jahre als zentrales, verteilt genutztes Filesystem eingesetzt. Schon seit einigen Jahren hat ein neuer Dienst, der MWN-Speicher, die wesentlich Funktionen von AFS ersetzt. Der MWN-Speicher wird von einem deutlich breiteren Kundenkreis genutzt, nicht nur am LRZ intern und der BADW, sondern auch an großen Teilen der TUM und zunehmend
auch an der LMU.
Im Laufe des Jahres wurde einiges an neuer Hardware installiert und in Betrieb genommen. Die gesamte
virtuelle Speicherinfrastruktur wurde durch neu beschaffte, modernere und leistungsstärkere Systeme ersetzt. Der Bestand an Bandlaufwerken im Archiv- und Backupsystem wurde um 16 LTO6-Laufwerke auf
insgesamt 142 Laufwerke erweitert.
Der Gesamtumfang der in den Bandbibliotheken des LRZ gespeicherten Daten wuchs im Jahr 2014 von
35 auf 42 PetaByte (PiB) an. Die Daten stammen vorwiegend von Sicherungssystemen zweiter Ordnung
sowie von der Archivierung großer Datenmengen. Der Einsatz von Bändern als Datenträger ist bei solch
großen Datenmengen gestern wie heute unverzichtbar.
Die Benutzerbetreuung wurde deutlich intensiviert. Verschiedene Workshops wurden zum Thema Archiv
und Backup am LRZ und an Kundenstandorten abgehalten, Großkunden wurden individuell betreut. Besonderes Augenmerk wurde auf die Unterstützung der digitalen Geisteswissenschaften gelegt. Ein neues
Web-Portal für die Nutzer der Archiv- und Backupsystems wurde Mitte des Jahres freigegeben.
Ebenfalls seit Mitte des Jahres wurden Chancen und Risiken für ein neues Dienstangebot geprüft. Durch
den neuen Dienst soll der vielfache Wunsch nach einem Sync&Share-Angebot ähnlich Dropbox erfüllt werden. Verschiedene Produkte wurden eingehend untersucht. Inzwischen läuft ein Prototyp im internen Probebetrieb. Noch in der ersten Jahreshälfte 2015 soll der Dienst für einen erweiterten Nutzerkreis freigegeben werden.
10.2 Archiv- und Backupsystem
10.2.1 Konfiguration
Das Archiv- und Backupsystem des LRZ besteht aus drei großen Systemen mit Bandrobotern, nämlich
•
•
•
dem Hochleistungssystem HABS, das Anfang 2006 mit damals sehr leistungsstarken Bandlaufwerken installiert und seitdem viermal (Ende 2007, 2010, Mitte 2012 und zuletzt Ende 2013) erweitert wurde,
einem System mit LTO-Bandlaufwerken in mehreren Bibliotheken (LABS), das 2010 neu installiert
wurde und 2014 um 16 LTO6-Laufwerke aufgestockt wurde.
und einem Desaster Recovery System (DRABS), das zusammen mit der HABS Erweiterung in
2012 beschafft wurde, und das eine zweite Kopie der Archivdaten vorhält.
Das letztgenannte System ist, um die Ausfallsicherheit zu erhöhen, räumlich getrennt am Rechenzentrum
Garching der Max-Plack-Gesellschaft (RZG) installiert. Ebenfalls aus Gründen der Ausfallsicherheit befinden sich die Komponenten der drei Systeme in getrennten Speichernetzen (SAN Fabrics). An die SAN
Fabrics sind die Storageserver, alle Bandlaufwerke der Libraries und alle Systeme mit hohem Datenverkehr, insbesondere die NAS-Filerköpfe und die Backupserver angeschlossen. Die SAN Fabrics sind Grundlage für einen effizienten Transport von großen Datenmengen. Dadurch wird die Last am LAN reduziert
und eine dynamische Zuordnung der Speicherkomponenten zu den Verbrauchern ermöglicht.
Die wesentlichen Komponenten des Systems sind:
•
•
•
•
•
•
21 Rechner (vorwiegend Intel Nehalem EP und EX), 388 Cores, 3.952 Gigabyte RAM
6 Fibre Channel Switches (8 Gbit/16 Gbit) und 2 Fibre Channel Direktoren (8/16 Gbit)
1 Fibre Channel Router (16 Gbit)
56 10GE LAN Ports mit 100 Gbit/s Uplink zum LRZ-Backbone
18 Storage Server mit insgesamt 2.700 TB (brutto) an Hintergrundspeicher, verteilt auf 2.424 Disks
und 38 SSDs mit 70 Gigabyte/s theoretischem Gesamtdurchsatz
5 Tape Libraries mit insgesamt 61.500 Slots
92
Datenhaltung
•
142 Bandlaufwerke (LTO-4, LTO-5, LTO-6, T10K) mit 26,5 GByte/s theoretischem Gesamtdurchsatz
Archive and Backup System, Dec 2014
IBM
SUN
Brocade
DELL
Brocade 6510
Brocade 6510
Library IBM TS3500
7 tape devices IBM LTO5
19,137 slots
1 TSM Server
TSM
DRABS –
Desaster Recovery Archive
and Backup System (RZG)
10 GBit Ethernet
2-8 TSM Servers
TSM
TSM
8 machines
IBM X3850x5
IBM X3550 M3
2-8 TSM Servers
TSM
TSM
Library SUN SL8500
26 tape devices SUN T10K-B
10,000 slots
IBM StorWize
V7000
10 TB SSD
3 TSM Servers
TSM
12 machines
3 TSM Servers
SUNFire X4270
TSM
Disk Cache + DB
Disk Cache
IBM DS3500
1927 TB
DB
SAN
Brocade
DCX
8510-4
Brocade
DCX
8510-4
Disk Cache + DB
Brocade 5300
Brocade 5300
DELL PowerVault
MD36XXf
280 TB
Library IBM TS3500
17,333 slots
HABS –
High Performance Archive and Backup System
SAN
SUN 6780
486 TB
Brocade 5300
Brocade 5300
Library SUN SL8500
10,000 slots
Library IBM TS3500 L52
5,039 slots
LABS –
LTO Archive and Backup System
Abbildung 41: Überblick Archiv- und Backupsysteme
Softwareseitig wird die gesamte Architektur mit dem Tivoli Storage Manager von IBM betrieben. Auf den
21 Rechnern des Systems laufen jeweils mehrere Instanzen des Tivoli Storage Manager, insgesamt waren
Ende 2014 60 TSM-Server in Betrieb. Die Gesamtanzahl der aktiven TSM-Server ist damit nach einer
Reihe vorangegangener Stilllegungen etwas gesunken (vormals 66 Server). Die Reduzierung wurde möglich, da die bei den TSM-servern ab Version 6 eingesetzte DB2-Datenbank deutlich leistungsfähiger ist als
die zuvor genutzte TSM-DB-Implementierung.
Die Abbildungen auf den folgenden Seiten zeigen die drei Teilkonfigurationen des HABS, LABS bzw.
DRABS im Detail.
93
High Performance Archive and Backup System 2014
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
capacity:
29.150 TB, 10.000 T10K + 4600 LTO-5 + 4900 LTO-6
53.000 TB, 10.000 T10K cartridges + 17.300 LTO-6 cartriges
26 x T10K-B + 15 x LTO-5 + 10 x LTO-6 drives
10 TB SSD, 117 TB SAS, 2090 TB NL-SAS
Linux Compute
Cluster
Munich Scientific
Network
Router MWN
10 Gbit
SuperMUC Network
Switches
HP E6600-24XG Switch
24 x 10 GbE Ports
4 x 10 Gbit Ethernet HPC special
Pentium 4
24 x 10 GbE Ports
11 x 10 Gbit Ethernet
1 x 10 Gbit Ethernet HPC special
4 x IBM X3850 X5
Pentium
4
S1Server
OPTERON
Worker
S127x 2 coreSn
Sn
XEON
X7550
7
4 x 8 Core
10 Gbit
1 x IBM X3550 M3
3 x IBM X3850 X5
4 x Intel Xeon X7550 2.0 GHz
256-512 GB Memory
8 x FC 8 Gbit
4 x 10 GbE Trunk
SLES 11 SP3
TSM Server 6.3
OPTERON
Worker
Server
OPTERON
2 x 2 core
XEON
X7550
2x2
core
4 x 10 Core
4 x Intel Xeon E7-4860 2.27 GHz
512 GB Memory
8 x FC 8 Gbit
4 x 10 GbE Trunk
SLES 11 SP3
TSM Server 6.3
Mgmt. Server
XEON E5606
1 x 4 core
2 x Intel Xeon E5606
2.13 GHz
16 GB Memory
4 x FC 8 Gbit
2 x 1 GbE
SLES 11 SP3
TSM Server 6.3
72 x 8 Gbit FC
National
Supercomputer
SuperMUC
4 x 8 Gbit FC
Storage Area Network
FC-Direktor
48 Port 8Gb + 64 Port 16Gb
FC-Direktor
48 Port 8Gb + 64 Port 16Gb
26 x 4 Gbit FC
104 x 8 Gbit FC
25 x 8 Gbit FC
Dell MD3620f
SAS 39 TB
Dell MD3620f
SAS 39 TB
Dell MD3620f
SAS 39 TB
Dell MD3660f
NL-SAS
163 TB
IBM DS3500
NS-SAS
212 TB
IBM DS3500
NS-SAS
212 TB
IBM DS3500
NS-SAS
212 TB
IBM DS3500
NS-SAS
212 TB
IBM DS3500
NS-SAS
229 TB
IBM DS3500
NS-SAS
229 TB
IBM DS3500
NS-SAS
229 TB
IBM DS3500
NS-SAS
196 TB
IBM DS3500
NS-SAS
196 TB
IBM V7000
SSD 5TB
IBM V7000
SSD 5TB
IBM TS3500 tape library
15 LTO-5 + 10 LTO-6 FC tape drives
Max library capacity:
Cur. library capacity:
43.000 TB uncompressed
STK SL8500 tape library
26 FC tape drives Titanium B
Abbildung 42: Hochleistungs-Archiv- und Backupsystem Ende 2014
1310 disks
total cap.:
2217 TB
94
Datenhaltung
LTO Archive and Backup System 2014
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
devices:
21.616 TB, 5.397 LTO-4 + 6811 LTO-5 + 2833 LTO-6 cartridges
41.250 TB, 16.500 LTO-6 cartridges
26 x LTO4 + 24 LTO5 + 26 LTO6 drives
222 TB FC-AL, 262 TB SATA
Router MWN
10 Gbit
24 x 10 GbE Ports
24 x 10 GbE Ports
Munich Scientific
Network
12 x Sun Fire X4270
Pentium 4
Pentium 4
Pentium 4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
SnX4270 Sn
Sun
Fire
S1
Sn
Sn
Sn
9 Worker / 3 Mgmt.
7
2 XEON x 4 Core
2 x INTEL X5560 2.8 GHz
72/16 GB Memory
4 x FC 8 Gbit
2 x 10 GbE (Failover)
SLES 11 SP3
TSM Server 6.3
56 x 8 Gbit FC
8 GBit FC-Switch 80 Port
26 x 4 Gbit FC
34 x 8 Gbit FC
48 x 8 Gbit FC
5.000 slots total
capacity: 7.500 TB
IBM TS 3500 tape library
10 x LTO-4 + 8 x LTO-5
10.000 slots total
capacity: 15.000 TB
SUN SL8500 tape library
16 x LTO-4 + 16 x LTO-5 + 26 x LTO-6
SUN 6780
FC-AL 65 TB
SATA 87 TB
1152 disks, total capacity: 484 TB
SUN 6780
FC-AL 65 TB
SATA 87 TB
Abbildung 43: LTO-Archiv- und Backupsystem Ende 2014
SUN 6780
FC-AL 61 TB
SATA 87 TB
95
Desaster Recovery Archive and Backup System 2014
Cur. tape capacity:
Max. tape capacity:
Tape devices:
25.750 TB,
6.000 LTO-5 + 6700 LTO-6 cartridges
47.800 TB, 19.137 LTO-6 cartriges
7 x LTO-5 + 8 x LTO-6 drives
Munich Scientific Network
Router MWN
1 Gbit
HP 1GE Switch
48 x 1 GbE Ports
2 x 1 Gbit Ethernet
1 x IBM X3650 M4
1 x Intel E5-2630 v2 2.6 GHz
32 GB Memory
2 x FC 8 Gbit
2 x 1 GbE Trunk
Worker Server
XEON E5-2630 v2
1 x 6 Core
SLES 11 SP3
TSM Server 6.3
16 x 8 Gbit FC
FC-Switch
24 Port 16Gb
FC-Switch
24 Port 16Gb
15 x 8 Gbit FC
IBM TS3500 tape library
7 LTO-5 + 8 LTO-6 FC tape drives
Abbildung 44: Desaster Recovery-Archiv- und Backupsystem Ende 2014
96
Datenhaltung
10.2.2 Schwerpunkte in den Aktivitäten
10.2.2.1 Neue Bandlaufwerke für LABS
Die Bandlaufwerke der Archiv- und Backupsysteme werden nicht nur für die erste Speicherung der eingehenden Daten auf Kassetten genutzt. Im Rahmen der Qualitätssicherung und der Konsolidierung des Datenbestands werden die Daten auf den Kassetten regelmäßig umkopiert. Außerdem werden die Laufwerke
natürlich benötigt, um die Daten auf den Kassetten zu lesen, wenn entsprechende Anfragen eingehen. An
einer der beiden Bandbibliotheken traten hier lange Wartezeiten auf. Um die Bandbreite zu erhöhen, wurden für diese Library weitere 16 LTO6-Laufwerke beschafft und Ende 2014 in die Library eingebaut.
10.2.2.2 DATWeb Release 3
DATWeb ist eine Eigenentwicklung des LRZ. Das System bietet ein Management-Portal für lokale und
zentrale TSM-Administratoren. Es ermöglicht unter anderem, sich ein Gesamtbild über den aktuellen Datenbestand zu machen und Accounting-Daten abzurufen.
Mit Release 3 wurde 2014 ein in weiten Teilen neu geschriebenes System in Betrieb genommen, das die
veraltete Version 2 ablöste. Das neue Release ist modular aufgebaut und stützt sich auf eine eigene Datenbank.
10.2.2.3 Umstrukturierung der Systemkonfiguration in RZG und LRZ
In 2013 musste das Desaster Recovery Konzept von einem sogenannten Server-to-Server Backup auf ein
LAN-less Verfahren umgestellt werden, bei dem die Server im LRZ direkt über das Speichernetzwerk die
Daten in die am Rechenzentrum der Max Planck-Gesellschaft (RZG) stehende Bandbibliothek kopieren.
Durch diese Umstellung wurden Ende 2014 die bisher am RZG benötigten Server und Speicherressourcen
frei. Für eine Weiternutzung im LRZ Backup- und Archivsystem wurde diese Systeme ans LRZ umgezogen
und in die am LRZ vorhandene Konfiguration integriert.
10.2.2.4 Transfer von 2 PB in RZG-eigene Library
Das RZG betreibt seit 2013 am LRZ eine eigene Library mit zugehöriger TSM-Serverkonfiguration. Da der
Platz in den LRZ eigenen Libraries anderweitig gebraucht wurde, wurden die dort noch vorhandenen Daten
des RZG auf die RZG-eigene Library im Archivraum DAR2 (siehe Abschnitt 10.5) umgezogen. Im Vorfeld
des eigentlichen Umzugs wurden mittels TSM Export/Import ca. 500 TB über das hausinterne Netz transferiert. Beim finalen Transport der Daten vom DAR0 in den DAR2 wurde eine „Transferleistung“ von 34
TBit/s ganz ohne Netzwerk erreicht. Die 1.259 Kassetten wurden aus der Library im DAR0 exportiert, per
Transportwägelchen in den DAR2 verbracht und dort in die RZG-Library importiert. Die importierten Kassetten verbleiben im Besitz des RZG, das LRZ erhält im Gegenzug neue Kassetten mit gleichem Label
vom RZG. Eine Vereinbarung zum Austausch von Datenträgern wurde vom RZG unterzeichnet.
10.2.3 Statistik
Tabelle 18: Statistik für 2014
Ende 2014 waren in den
5
Libraries des Archiv- und Backupsystems
42
Petabyte, verteilt auf
19
Milliarden Dateien gespeichert. Täglich wurden auf die Systeme durchschnittlich
100
9.400
450
Terabyte neu geschrieben. Die Daten stammen von rund
Rechnern im MWN aus über
Einrichtungen der Münchner Hochschulen.
Ende 2014 befanden sich knapp 50.000 Kassetten in den Fächern der fünf Libraries. Die Gesamtanzahl
der Kassetten ist allerdings nur bedingt als Indikator für das Aufnahmevermögen tauglich, da die Kapazitäten der Kassetten je nach Technologie stark variieren.
97
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. 2014 wurden 1.229 Nodes neu
registriert und 827 alte Nodes inklusive ihrer gespeicherten Daten gelöscht. Durch das explizite Löschen
von Nodes sowie durch automatische Löschprozesse nicht mehr benötigter Daten wird dafür gesorgt, dass
das Archiv- und Backupsystem nicht zum Datengrab wird.
Um die Datenflut soweit wie möglich zu begrenzen, ist es notwendig, den Kunden des Archiv- und Backupsystems den Umfang ihrer abgelegten Daten immer wieder bewusst zu machen und sie zum sinnvollen Umgang mit den vom LRZ zur Verfügung gestellten – für sie vorläufig noch kostenlosen – Ressourcen
anzuhalten. Ein eigens für diesen Zweck bereitgestelltes Webportal (DATWeb) erlaubt es den Kunden, sich
direkt und 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 EMail informiert. Integriert sind Werkzeuge, die der betrieblichen Überwachung und Analyse der Systeme
dienen. Nutzer mit besonders auffälligem Datenprofil werden direkt angesprochen.
Abbildung 45: Datenverkehr (TB pro Monat)
Abbildung 46: Datenumfang (TB pro Monat)
98
Datenhaltung
Alle Kontaktdaten werden zusätzlich regelmäßig auf ihre Aktualität überprüft. Entsprechend den Benutzungsrichtlinien werden Daten, zu denen sich keine Ansprechpartner mehr ermitteln lassen, nach Ablauf
einer festgelegten Frist gelöscht.
Den Zuwachs von Speicherbelegung und Dateneingang im Laufe des Jahres 2014 zeigen Abbildung 45
und Abbildung 46.
Der Archiv-Anteil am Datenbestand ist relativ statisch, d.h. es gibt nur wenige Änderungen an den Dateien
im Archiv. Archivdaten werden in der Regel einmal ins Archiv übertragen und dort sehr lange aufbewahrt,
im Fall der Langzeitarchivierung für Jahrzehnte.
Datensicherungen werden in relativ kurzen Abständen regelmäßig durchgeführt. Backup-Daten werden
daher häufig neu ins System geschrieben. Veraltete Backup-Daten werden automatisch aus dem Bestand
gelöscht. Durch diese Dynamik erklärt sich die im Vergleich zur Archivierung deutlich höhere Dateneingangsrate bei geringerer Steigerung des Datenumfangs.
Abbildung 47: Speicherbelegung seit 1995
Die Entwicklung seit der Installation des ersten unabhängigen Archiv- und Backupsystems im Jahr 1995
zeigt Abbildung 47. Das halblogarithmische Diagramm zeigt das kontinuierliche Wachstum des Datenbestands über die Jahre hinweg.
10.2.4 Plattform für digitale Langzeitarchivierung
10.2.4.1 Kooperation BSB-LRZ
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, inzwischen auf ein gedrucktes Pendant ganz verzichtet. Während die Digitalisierung für die Nutzer
den Zugang und den Umgang mit der Information beschleunigt und insgesamt erleichtert, entstehen aus
organisatorischer, rechtlicher und technischer Sicht neue Herausforderungen. Die Objekte sollen nicht nur
verwaltet und gespeichert, sondern auch langfristig zugänglich gemacht werden. Diese Aufgabe wird erschwert durch den raschen technologischen Wandel im Bereich der Hard- und Software und der Datenträger.
Seit 2004 besteht eine Kooperation zwischen der Bayerischen Staatsbibliothek (BSB) und dem LeibnizRechenzentrum, die inzwischen durch drei DFG-geförderte Projekte (BABS, BABS2 und vd16digital), die
BSB-Google-Partnerschaft und die Einführung des Managementsystems zur Langzeitarchivierung Rosetta
der Firma Exlibris ausgeweitet wurde. Dabei tritt das LRZ für die BSB als Dienstleister für Langzeitarchivierung (LZA), Bereitstellung von Online-Speicher, Attended Housing von Clusterknoten und Hosting von
virtuellen Servern auf. Die langfristige Speicherung der Daten übernimmt bei allen Projekten ein NAS-System und das Archiv- und Backupsystem des LRZ mit dem Softwarepaket Tivoli Storage Manager (TSM).
TSM verfügt über alle wesentlichen Funktionalitäten, die für Langzeitarchivsysteme Voraussetzung sind.
99
Das Gesamtsystem deckt damit alle wichtigen Bereiche eines für die langfristige Nutzung angelegten Archivs ab und folgt dem allgemeinen Referenzmodell Open Archival Information Systems (OAIS).
10.2.4.2 Datenwachstum
Abbildung 48 und Abbildung 49 zeigen die Entwicklung der Anzahl der Archivobjekte und des Datenvolumens des Langzeitarchivs von Januar 2006 bis Januar 2015. Der starke Anstieg der Dateianzahl ab März
2009 ist durch den Produktivbeginn der Archivierung der Google-Digitalisate (siehe Projekt Google) zu
erklären. In Abbildung 49 ist dieser Anstieg weniger auffällig, da die Größe der einzelnen Google-Digitalisate im Vergleich zu den übrigen Digitalisaten eher gering ist. Bisher wurden mehr als 1,27 Milliarden Objekte mit einem Datenvolumen von mehr als 580 TB am LRZ archiviert. Der Datenzuwachs im Jahr 2014
betrug ca. 100 Mio. Dateien mit einem Volumen von ca. 61 TB. Die aus Sicherheitsgründen erstellte Zweitkopie verdoppelt in der Praxis die Objektanzahl und das Datenvolumen.
Abbildung 48: Objektanzahl im LRZ-Archiv (Zweitkopie nicht berücksichtigt)
Abbildung 49: Datenvolumen im LRZ-Archiv (Zweitkopie nicht berücksichtigt)
100
Datenhaltung
Die gespeicherten Daten werden aufbereitet, archiviert und für eine Webpräsenz bereitgestellt. Dies geschieht auf über 100 Servern, die zum überwiegenden Teil auf der virtuellen Serverplattform des LRZ betrieben werden. Beispiele für solche Systeme sind unter anderem das Kulturportal Bayern bavarikon, die
Verkündungsplattform Bayern, der Web Server der Bayerischen Landesbibliothek oder Server, die die Volltextindizierung der Digitalisate steuern.
10.2.4.3 Zentrum für digitale Geisteswissenschaften
Im Juli 2013 unterzeichneten die BSB und die BADW einen Kooperationsvertrag über die Gründung eines
neuen Zentrums für digitale Geisteswissenschaften. Auch in den Geistes- und Kulturwissenschaften werden computerbasierte Verfahren und Werkzeuge immer wichtiger, etwa bei digitalen Editionen oder der
quantitativen Text- und Datenanalyse. Die BSB und die BADW bündeln in dem neuen Zentrum für digitale
Geisteswissenschaften ihr Know-how in diesem Bereich und errichten kostensparende, hoch effiziente
Strukturen. Das zukunftsweisende Konzept des neuen Zentrums soll Synergien freisetzen und durch die
Zusammenarbeit mit weiteren Partnern ausgebaut werden. Insbesondere kann das LRZ als IT Service
Provider für beide Einrichtungen koordinierend tätig werden.
10.2.4.4 Projekt Google
Im Rahmen einer 2007 entstandenen Public Private Partnership digitalisiert Google über eine 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 ist in
diesem Projekt als Dienstleister für die Langzeitarchivierung der Digitalisate, das Housing von Clusterknoten für die Formatmigration als Vorbereitung für die Web-Bereitstellung, das Hosting des Speichersystems
und das Hosting virtueller Server für Archivierung und Web-Bereitstellung zuständig.
Konkret stellt das LRZ als interne und externe Schnittstelle virtuelle Server bereit, die sich um Download,
Verarbeitung, Archivierung und Bereitstellung der Daten im Internet kümmern. Die Originaldateien, die die
BSB von Google erhält, werden im Archiv- und Backupsystem des LRZ abgelegt. Die Dateien, die im Internet angeboten werden, werden am LRZ auf einem NAS-System gespeichert. Die Umwandlung aller
originalen Bilddateien („Master“) in jeweils zwei Bilddateien mit niedrigerer Auflösung geschieht am LRZ
auf dem Linux-Cluster. In Abbildung 50 sind die Infrastruktur sowie der Workflow schematisch dargestellt.
Linux-Cluster, 34 Quadcore CPUs, slurm
Abbildung 50: Workflow im Google Projekt
101
Bis Ende 2014 wurden rund eine Million Bücher heruntergeladen und verarbeitet. Der Bestand an Archivdaten im Google-Projekt ist 2014 um 10 TB auf 193 TB angewachsen. Die Anzahl an archivierten Objekten
ist von einer Milliarde auf über 1,16 Milliarden Dateien gestiegen. Der von Zeit zu Zeit stagnierende Datenzuwachs wird dadurch verursacht, dass keine neuen Digitalisate in das Archiv eingepflegt, sondern nur
eine Vielzahl an Objekten im Archiv durch überarbeitete und verbesserte Versionen (z.B. Bildqualität und
OCR) ausgetauscht werden.
Abbildung 51: Archivierte Daten in TByte
Seit dem Jahr 2012 steht ein Teil der digitalisierten Bücher auch in Farbe zur Verfügung. Für diese Exemplare verdoppelt sich der Speicherbedarf. Es ist notwendig, diese Bücher erneut von Google zu holen und
in den Langzeitarchivierungsprozess einzupflegen.
10.3 Datenbanken
Beim Betrieb der Hochleistungsrechner (früher SGI, jetzt SuperMIG und SuperMUC) und des VMwareClusters fallen große Mengen Leistungs- und Abrechnungsdaten an, die intern ausgewertet und teilweise
auch den Nutzern zur Verfügung gestellt werden. Die zur Auswertung allein nur für diese beiden Bereiche
bereitgestellte Datenbankinfrastruktur umfasst derzeit sechs eigene Datenbankserver für HPC und einen
für das VMware-Cluster. Die Arbeiten daran beinhalten den Aufbau sowie die laufende Pflege dieser Datenbanksysteme sowie den hausinternen Support bei Fragen und Problemen mit den darauf laufenden
Anwendungen.
10.4 Onlinespeicher
10.4.1 Konfiguration und Entwicklung im Überblick
Die NAS-Systeme am LRZ haben sich als Speicherplattform aufgrund ihrer Stabilität, Ausfallsicherheit und
hohen Datensicherheit durch die Spiegelung auf ein Replikationssystem seit vielen Jahren bewährt und als
strategische Plattform etabliert. Die rapide wachsenden Datenmengen erfordern eine gute Skalierbarkeit
der eingesetzten Systeme. Abbildung 52 zeigt die Entwicklung der am LRZ betriebenen NAS-Infrastruktur
seit ihrer Einführung im Jahr 2005.
102
Datenhaltung
Abbildung 52: Links: Entwicklung Datenvolumen und Anzahl Festplatten
Rechts: Entwicklung der Anzahl an Filerköpfen
In der linken Abbildung ist in den Jahren 2011 und 2013 ein sehr deutlicher Zuwachs zu erkennen. Diese
Steigerung wurde durch die Inbetriebnahme des Speichersystems der Home-Verzeichnisse des SuperMUC durch die Beschaffungsphasen 1 und 2 bedingt. Die NAS-Datenkapazität stieg dabei in Phase 1 von
2.000 TB auf über 9.000 TB und in Phase 2 auf über ca. 15.000 TB an. Die Anzahl der Festplatten wuchs
in Phase 1 um den Faktor 2 auf 6.000 und in Phase 2 auf ca. 9.000 an. Im Jahr 2005 betrug das Bruttospeichervolumen der gesamten NAS-Infrastruktur überschaubare 54 TB auf etwa 350 Festplatten. Die Anzahl an Filerköpfen stieg im Zeitraum von 2005 bis 2012 von 5 auf 42 Filerköpfe an (Steigerungsfaktor:
10,5). Durch Konsolidierungsmaßnahmen konnte die Anzahl wieder auf 34 reduziert werden.
Abbildung 53 zeigt die Konfiguration der Speicherinfrastruktur aller Primärspeichersysteme inklusive der
Replikations- und Backupsysteme. Zwischen Primär- und Replikationsspeichersystemen werden die Daten
in der Regel asynchron gespiegelt. Im VMware-Umfeld, wo die Verfügbarkeit eine besonders große Rolle
spielt, erfolgt eine zusätzliche Spiegelung zwischen den auf unterschiedliche Brandabschnitte aufgeteilten
Produktivsystemen. Zur weiteren Erhöhung der Datensicherheit werden die Daten von den meisten Replikationssystemen zusätzlich über NDMP (Network Data Management Protocol) bzw. der SnapDiff-Methode
von TSM auf Magnetbänder gesichert. Die Primär- und Replikationssysteme befinden sich in getrennten
Brandabschnitten des Rechnergebäudes.
Abbildung 53: Primärsysteme, Replikation und Backup
103
Ein Cluster von Filerköpfen (supernasNN rechts in Abbildung 53) liefert den Speicher für die Homeverzeichnisse der Nutzer des Höchstleistungsrechners SuperMUC. Das Cluster besteht aus 14 Storage-Controllern (FAS 6820) der Firma NetApp und verfügt in der zweiten Ausbaustufe, die 2013/2014 umgesetzt
wurde, über ein Speichervolumen von 5.000 TB Brutto. Das zugehörige Replikationssystem (nasrepNN)
verfügt über 6 Storage Controller (FAS 6820), denen eine Kapazität von 4.224 TB Brutto zur Verfügung
steht.
10.4.2 Hochverfügbarer Speicher für virtuelle Server
Um die notwendige hohe Verfügbarkeit bei der Speicherversorgung der VMware-Infrastruktur zu erreichen,
wurden die Daten synchron gespiegelt und zusätzlich repliziert. Das hierfür eingesetzte Speichersystem
nas3170a/b erreichte die Grenzen seiner Leistungsfähigkeit, was sich durch hohe Latenzen und DiensteBeeinträchtigung bemerkbar macht. Aus diesem Grund wurde im Frühjahr 2013 ein Antrag auf Modernisierung der virtuellen Server- und Speicherinfrastruktur eingereicht, der im Herbst bewilligt wurde. Die Geräte wurden im Dezember 2013 beschafft und installiert. Eine Inbetriebnahme erfolgte im Februar 2014.
Um eine möglichst hohe Dienstgüte und Dienstverfügbarkeit zu erreichen, wurde das System auf drei unterschiedliche Brandabschnitte im Rechnergebäude (NSR0, DAR0 u. DAR1) verteilt. Abbildung 54 zeigt
die neue NAS-Infrastruktur bestehend aus vier Filerköpfen (nasVM01 bis nasVM04; linke Seite) und dem
bereits vorhandenen Replikationssystem (nasrep01 bis narep06; rechte Seite). Die Konfiguration lehnt sich
an die bewährte Konfiguration des Vorgängersystems an und steigert zugleich die Flexibilität und Leistungsfähigkeit des geplanten Gesamtsystems. Dies wird durch die Verwendung der neuen Betriebssystemgeneration Ontap Cluster Mode erreicht. Ontap Cluster Mode ermöglicht einen globalen Namensraum
und erweiterte Skalierbarkeit über mehrere Hardwareeinheiten, d.h. mehrere Filerköpfe hinweg. Dadurch
wird die bisherige Limitierung auf einen Filerkopf beim VMware-Speicher weitgehend aufgehoben.
Abbildung 54: Hochverfügbares NAS-System für VMware
Die aktiven Datastores (Formen mit durchgehender Linie in den blauen „Speicher-Tonnen“ in Abbildung
54), welche an VMware angebunden sind, werden auf die Festplatten der vier Speichersysteme lastoptimiert verteilt. Die Daten der betriebskritischen VMs werden zwischen den beiden Produktivsystemen asynchron jede Stunde gespiegelt (Formen mit gestrichelten Linie in den grünen „Speicher-Tonnen“) und zusätzlich auf ein weiteres System (Formen mit gestrichelter Linie in der orangenen „Speicher-Tonne“) alle
zwei bis vier Stunden repliziert. Durch diese gegenseitige Spiegelung ist es bei Ausfall eines kompletten
Brandabschnitts möglich, die VMware-Infrastruktur in kurzer Zeit wieder herzustellen. Die VMs, welche ihre
104
Datenhaltung
Daten aktiv im ausgefallenen Raum gespeichert hatten, können aus dem asynchronen Spiegel wieder hergestellt werden. Der maximale Datenverlust beträgt eine Stunde (oder kürzer, falls das Spiegelintervall
kleiner gewählt wurde). Im Herbst 2014 wurde das neue Speichersystem an die 2014 neu beschaffte
VMware-Umgebung ohne Unterbrechung im Nutzerbetrieb umgehängt.
Im Rahmen des Hostings für das dialogorientierte Serviceverfahren der Stiftung für Hochschulzulassung
ist eine analog aufgebaute Konfiguration (zwei NetApp FAS 3170, 74 TB) mit synchroner Spiegelung in
Betrieb.
10.4.3 MWN Storage Cloud
Das LRZ stellt Speicherkapazitäten für alle Studierenden und Mitarbeiter der Hochschulen bereit und verwendet dazu seit Mitte 2008 eine einfach zu bedienende, sichere und zentral administrierte Speicherlösung. 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 Projektspeicherplatz ermöglicht eine neue Art der Kooperation zwischen verschiedenen Einheiten, die bisher
wegen der dezentralen Strukturen nicht möglich war. Eine weitere Aufgabe des Angebots ist die Versorgung anderer hochschulweiter Dienste mit sicherem, hochverfügbarem Speicherplatz. Die sogenannte
MWN Storage Cloud (auch MWN-Speicher) wird – vor allem von Seiten der TU München - sehr gut angenommen, was die stetig steigende Anzahl der eindeutigen Benutzerkennungen (ohne Funktions- und lokale
Benutzerkennungen) mit simultanen Zugriffen zeigt (siehe Abbildung 55). Die simultanen Zugriffe haben
sich innerhalb der letzten vier Jahre (2011 bis 2014) von 1.100 auf 4.000 vervierfacht. Deutlich zu erkennen
sind in den Diagrammen die betriebsschwachen Zeiten an den Wochenenden und zwischen Weihnachten
und Neujahr.
Abbildung 55: Durchschnittliche Anzahl simultan zugreifender Kennungen
Abbildung 56: Nutzung der MWN Storage Cloud für TUM Projekte
105
Hauptnutzer der MWN Storage Cloud war auch 2014 die TU München. Hier hat sich die Speicherbelegung
allein im Jahr 2014 von 168 TB auf 318 TB nahezu verdoppelt. Abbildung 56 zeigt die zunehmende Nutzung
des Projektspeichers durch Lehrstühle und Arbeitsgruppen an der TUM von den zögerlichen Anfängen bis
zur intensiven Nutzung heute.
Aber auch die LMU nutzt zunehmend diesen Speicher, wenn auch noch nicht in dem Maße wie die TUM.
Die organisationsübergreifende Bereitstellung von Speicherplatz ist eine Herausforderung, die weit über
die Grenzen des Münchner Wissenschaftsnetzes hinausgeht.
10.4.4 Sync+Share Lösung für die Münchner Universitäten
Die veränderte Arbeitsweise wissenschaftlicher Mitarbeiter und Studenten und die zunehmende Verwendung von Smartphones und Tablets (aber auch Notebooks) führen zu veränderten Anforderungen, die die
MWN Storage Cloud nicht alle erfüllen kann. Der Wunsch nach zusätzlicher Funktionalität (wie z.B. das
Synchronisieren von Datenbeständen über verschiedene Geräte hinweg, Offline Arbeiten, Datenaustausch
mit externen Kollegen) ist vielfach zu hören. Für den organisationsinternen Datenaustausch bzw. den gemeinsamen Online-Zugriff auf Daten (shared folder) ist die MWN Storage Cloud gut geeignet. Für den
Austausch mit Externen, also Personen, die keine Kennung im lokalen Verzeichnisdienst haben und auch
nicht bekommen können, gibt es aktuell nur unzureichende Lösungen. Dies führt dazu, dass Dienste wie
Dropbox, OneDrive und/oder iCloud verwendet werden, obwohl diese Dienste nicht dem deutschen Datenschutzrecht unterliegen.
Aus diesem Grund hat sich das LRZ entschlossen, einen eigenen, sicheren Sync+Share-Dienst anzubieten. Im Sommer 2014 wurden als erster Schritt diverse Sync&Share-Produkte, wie z.B. PowerFolder, OwnCloud, Filr und TeamDrive evaluiert. Anfang November fiel die Entscheidung für PowerFolder. Bereits 4
Wochen später ging eine Pilot-Installation in Betrieb, die von 120 Personen aktiv genutzt wurde, etwa für
die erfolgreiche Vorbereitung eines EU-Projektantrags mit über 30 externen beteiligten Wissenschaftlern.
Für 2015 ist geplant, nach einer anfänglichen Phase im Friendly User Modus im Laufe des Sommers den
Regelbetrieb für die TUM und der LMU auf einem entsprechend skalierbaren System aufzunehmen. Mit
dem neuen Dienst LRZ Sync+Share können dann Daten und Dokumente bequem, sicher und zuverlässig
gespeichert und gleichzeitig auf mehreren Geräten (Desktop, Laptop, Tablet, Smart Phone) auf dem gleichen Stand und weltweit im Zugriff gehalten werden. Die Daten können auch mit anderen Personen weltweit geteilt und ausgetauscht werden. Durch LRZ Sync+Share wird organisationsübergreifendes, interdisziplinäres und kooperatives Arbeiten stark vereinfacht werden.
10.5 Daten- und Archivräume
Im Rechnergebäude des LRZ steht für die Geräte des Archiv- und Backupbereichs nahezu ein gesamtes
Stockwerk des Altbaus mit 560 m2 Nutzfläche zur Verfügung, der sogenannte DAR0 (Daten- und ArchivRaum). Der Raum würde, wie alle anderen Brandabschnitte in diesem Stockwerk auch, im Brandfall mit
Argon geflutet werden, d.h. Daten und Geräte würden keinen Schaden nehmen. Die sicherheitstechnischen
und klimatischen Randbedingungen sind im Prinzip gut geeignet für die langfristige, sichere Aufbewahrung
großer Datenmengen.
Abbildung 57: Daten- und Archivraum DAR0
106
Datenhaltung
Die Dimensionierung erlaubte bisher eine optimale Aufstellung der Geräte. Den meisten Raum nehmen
fünf Bandbibliotheken ein. Neben den Bandbibliotheken wird der Raum allerdings zunehmend für die Aufstellung der umfangreichen NAS-Plattenbasis (Replikatsysteme) genutzt. Anders als leistungsstarke Server haben Platten eine relativ geringe Leistungsaufnahme. Die durch die Platten verursachte Wärmeentwicklung und die damit einhergehende Veränderung der klimatischen Verhältnisse im Archivraum werden
als vertretbar erachtet. Wie an vielen anderen Stellen auch, musste hier ein vernünftiger Kompromiss zwischen Kosten und Nutzen gefunden werden.
Mit einer durchschnittlichen Leistungsaufnahme von unter 70 KW ist der Raum DAR0 ein Aushängeschild
für Green IT. Der geringe Energiebedarf ist darauf zurückzuführen, dass in dem Raum primär Bandbibliotheken und Plattensysteme stehen, deren Stromverbrauch verglichen mit den energiehungrigen Prozessoren der Serverracks in den anderen Räumen sehr gering ist.
DAR = DAR0 + DAR1 + DAR2
Diese Gleichung steht für die substantielle Erweiterung des Daten- und Archivraums im Zuge der Erweiterung des Rechnergebäudes. Während der „alte“, 2006 in Betrieb genommene DAR0 und der neue DAR2
primär für die Archiv- und Backupsysteme vorgesehen sind, wird der sogenannte DAR1 neben hochverfügbaren Plattenspeichern auch hochverfügbare Server beherbergen. In diesem Raum wurden über 50
Geräteschränke zur Trennung von kalter und warmer Luft speziell „eingehaust“. Die Trennung der Luftströme erhöht die Energieeffizienz der Klimatisierung erheblich. Hochverfügbarkeit geht oft einher mit
Hochsicherheit. Künftig soll daher der DAR1 als getrennte Sicherheitszone mit eigener Schließberechtigung betrieben werden.
Abbildung 58: Brandabschnitte im Rechnerwürfel
Durch die Gebäudeerweiterung wurde auch die Anzahl der Brandabschnitte insgesamt erhöht. Dadurch ist
es möglich, die Komponenten vieler wichtiger Dienste redundant aufzustellen, was vorher nicht immer
möglich war. Hochverfügbare Datenspeicher konnten so auf die Räume verteilt werden, dass der Dienst,
für den sie benötigt werden, bei Abschaltung kompletter Brandabschnitte nicht beeinträchtigt wird. Bei der
Aufstellungsplanung wurden dabei noch weitere Faktoren berücksichtigt, wie eine redundante Einbindung
in die Klimainfrastruktur oder eine unterbrechungsfreie Stromversorgung (grüne Bereiche in Abbildung 58).
107
11 Münchner Wissenschaftsnetz – Internetzugang
Das Münchner Wissenschaftsnetz (MWN) verbindet vor allem Standorte der Ludwig-Maximilians-Universität München (LMU), der Technischen Universität München (TUM), der Bayerischen Akademie der Wissenschaften (BAdW), der Hochschule München (HM) und der Hochschule Weihenstephan-Triesdorf miteinander. Es wird aber auch von anderen wissenschaftlichen Einrichtungen (u. a. Max-Planck-Gesellschaft,
Fraunhofer-Gesellschaft, Kunst-Hochschulen, Museen) mit genutzt. Das Münchner Wissenschaftsnetz bildet die Grundlage für die Kommunikation und Kooperation innerhalb und zwischen den angeschlossenen
Institutionen sowie mit Kooperationspartnern in Deutschland, Europa und auch international.
Die besonders hervorzuhebenden Aktionen und Ereignisse im Jahr 2014 waren:
•
Planung einer neuen WDM-Infrastruktur im Backbone (vgl. Abschnitt 11.1.2)
•
Weiterentwicklung des Redundanzkonzeptes am Campus Garching und Aufbau eines zweiten
Routers (vgl. Abschnitt 11.2.3)
•
Ausweitung von eduroam über die Campus Bereiche hinaus durch Unterstützung von eduroam im
City-Netz der Stadt München (vgl. Abschnitt 11.11.3)
•
Erheblicher Ausbau des WLAN und Erweiterung um zwei weitere Controller (vgl. Abschnitt 11.11)
•
Neuentwicklung des Portals für Netzverantwortliche NESSI (Network Self Service Interface) (vgl.
Abschnitt 11.8.4)
•
Inbetriebnahme des neuen Security Incident and Event Management auf der Basis von QRadar
(vgl. Abschnitt 5.5.2)
11.1 Struktur und Betrieb des Münchner Wissenschaftsnetzes
(MWN)
Die Standorte der angeschlossenen Institutionen sind insbesondere über die gesamte Münchner Region
(i. W. Münchner Stadtgebiet, Garching, Großhadern/Martinsried und Weihenstephan) verteilt, es gibt aber
auch weitere Standorte in Bayern. Abbildung 59 gibt einen Überblick über die räumliche Ausdehnung des
MWN. Die Lage von Standorten, die außerhalb des Münchner Stadtgebietes liegen, ist in der Abbildung
nicht maßstabsgetreu dargestellt, sondern lediglich schematisch (Himmelsrichtung) angedeutet.
Derzeit sind an das MWN mehr als 440 als Unterbezirke bezeichnete Gebäudegruppen angebunden und
es werden bis zu 180.000 Geräte über das MWN versorgt, wobei während des Semesters die Anzahl der
mobilen Geräte überwiegt. Die Größe der zu versorgenden Areale ist sehr unterschiedlich; sie reicht von
einem einzelnen Gebäude bis zu einem gesamten „Campusbereich“ (z.B. Garching, Weihenstephan) mit
mehr als 30 Gebäuden und mehr als 12.500 angeschlossenen Endgeräten. Derzeit sind 52 Studentenwohnheime mit insgesamt knapp 12.500 Wohnheimplätzen am MWN angeschlossen.
Abbildung 60 zeigt die Ausdehnung und Größe des MWN auf einer Karte. Die Nadeln repräsentieren dabei
die Unterbezirke. Sind mehere Unterbezirke an einem Ort, so werden diese in einem Kreis zusammengefasst und die Zahl gibt an, wie viele Unterbezirke zusammengefasst wurden.
Das LRZ ist für das gesamte Backbone-Netz und einen Großteil der angeschlossenen Institutsnetze zuständig. Eine Ausnahme bilden die internen Netze der Medizinischen Fakultäten der Münchner Universitäten (u. a. Rechts der Isar (TUM), Großhadern und Innenstadt-Kliniken (LMU)) sowie der Informatik der
TUM. Sie werden von den jeweiligen Rechenzentren der Fakultäten selbst betrieben und betreut. Das LRZ
ist jedoch für die Anbindung dieser Netze an das MWN zuständig.
Das MWN ist mehrstufig realisiert:
• Das Backbone-Netz verbindet mittels Routern die einzelnen (Hochschul-)Standorte (Areale) und Gebäude innerhalb der Areale.
• Innerhalb eines Gebäudes dient das Gebäudenetz mittels Switches zur Verbindung der einzelnen Rechner und der Bildung von Institutsnetzen.
• Eine Sonderstellung nimmt das Rechenzentrumsnetz ein, das die zentralen Rechner im Rechnerwürfel
des LRZ miteinander verbindet.
108
Münchner Wissenschaftsnetz – Internetzugang
Abbildung 59: Räumliche Ausdehnung des Münchner Wissenschaftsnetzes
(nicht maßstabsgerecht)
Etwas genauer lässt sich diese Realisierung wie folgt beschreiben:
•
Die Router werden über das Backbone-Netz miteinander verbunden und bilden den inneren Kern
des MWN. Die Verbindungsstrecken des Backbone-Netzes sind je nach Nutzungsgrad verschieden ausgeführt. Im Normalfall sind die Strecken Glasfaserverbindungen, die langfristig von der
Deutschen Telekom und M-net angemietet sind. Auf den Glasfaserstrecken wird mit 10 Gbit/s übertragen. Die Verbindung der Strecken übernehmen neun 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 25 Mbit/s) von M-net oder der Telekom oder über
109
WLAN-Verbindungen auf Basis von IEEE 802.11a, g oder n (bis zu 150 Mbit/s) angebunden. Das
Backbone-Netz wird genauer im folgenden Abschnitt beschrieben.
Abbildung 60: MWN Unterbezirke und Ausdehnung
•
Die Switches eines Gebäudes oder einer Gebäudegruppe werden mittels Glasfaser noch zum
größ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 1 Gbit/s) oder zu einem sehr geringen Teil noch über Koaxial-Kabel (10 Mbit/s) realisiert.
Server-Rechner werden in der Regel mit 1 Gbit/s zum Teil auch mit 10 Gbit/s angeschlossen. Die
Gebäudenetze werden in Abschnitt 11.1.3 erläutert.
•
Die zentralen Rechner im LRZ (der Höchstleistungsrechner SuperMUC, die Linux-Cluster, die Server des Backup- und Archivsystems und die zahlreichen Server-Systeme) sind untereinander mit
mehrfach 10 Gbit/s mittels Switches verbunden. Diese Netzstruktur der zentralen Rechner ist über
einen Router (mehrfach 10 Gbit/s) mit dem MWN-Backbone verbunden. Die Struktur des Rechenzentrumsnetzes beschreibt Abschnitt 11.1.4.
•
Im MWN wird ausschließlich das Protokoll IP benutzt.
Abbildung 59 und Abbildung 60 zeigen die für das Backbone-Netz verwendeten Strecken, deren Übertragungsgeschwindigkeiten und Endpunkte. Hieraus lässt sich die Ausdehnung des Netzes ablesen. Die Areale des MWN werden zu Dokumentationszwecken auch mit Kürzeln aus ein oder zwei Zeichen (Unterbezirke) benannt (eine Liste der in der Abbildung verwendeten Unterbezirke findet sich im MWN-Netzkonzept
(s. https://www.lrz.de/services/netz/mwn-netzkonzept/mwn-netzkonzept.pdf).
110
Abbildung 61: Standorte und Verbindungen im MWN (Teil 1)
Abbildung 62: Standorte und Verbindungen im MWN (Teil 2)
111
112
11.1.1 Struktur des Backbone Netzes
Während Abbildung 61 und Abbildung 62 die topologische Struktur, die Standorte und deren Verbindungen
zeigt, stellt Abbildung 63 die technische Struktur des Kernnetzes dar. Den Kern des Backbones bilden
Cisco Nexus 7010 Switch/Router, die untereinander mit 10 GBit/s verbunden sind. Die Anbindung der
Standorte erfolgt über LWL (Lichtwellenleiter). Das LRZ selbst ist über einen virtuellen Router (bestehend
aus zwei Cisco Nexus 7010) an das Backbone angebunden. Die meisten Telekom-Glasfasern enden im
zentralen Netzraum des TUM-Stammgeländes. Die M-net Glasfasern enden im zentralen Netzraum des
LMU-Stammgeländes.
Abbildung 63: Struktur des Kernnetzes
Das Router-Backbone bildet mehrere Zyklen, die der Redundanz dienen. Alle Router haben eine mindestens doppelte Anbindung an das Backbone. Im Jahr 2014 wurde begonnen, den zentralen Netzknoten am
Campus Garching (im Maschinenwesen) auf zwei Standorte aufzuteilen. Dazu wurde ein zweiter Router
in Katalysezentrum installiert der mit dem Router im Maschinenwesen ein virtuelles System (vPC) bildet.
Die Router im Backbone koordinieren sich über Punkt-zu-Punkt Verbindungen mittels OSPF (Open Shortest Path First). Der Verkehr fließt von der Quelle zum Ziel über die Leitungen mit der kleinsten „Hop“Anzahl (Weg, der über die wenigsten Router führt).
Ausnahmen zu dieser generellen Regel bilden der über „Policy-Based-Routing“ geführte Verkehr, der in
einem eigenen VLAN (Virtual LAN) fließt, und spezielle VLANs, die über das gesamte MWN gezogen wurden. Dies ist nötig, um die besonderen Anforderungen von MWN-Mitnutzern (MPG-Institute, Staatsbibliothek, etc.) zu erfüllen.
Einige Institutionen (LMU-Medizin, TUM-Informatik) haben doppelte Anbindungen an das MWN. Mittels
BGP (Border-Gateway-Protocol) wird hier die redundante Wegeführung realisiert.
Ebenfalls über BGP sind die Anbindungen ins Internet ausgeführt. Dabei dient die M-Net Anbindung nur
als „Notfall“ Backup. Normalerweise werden die Daten über die beiden 10GBit/s Bündel zu den DFN SuperCores in Erlangen und Frankfurt geleitet.
11.1.2
113
Planung von WDM-Systemen im MWN-Backbone
Das Max-Planck-Institut für Neurobiologie in Martinsried kam 2013 mit der Bitte auf das LRZ zu, zu prüfen
ob und wie man eine 100 Gbit/s-Verbindung von Martinsried nach Garching zum RZG (Rechenzentrum
Garching der Max-Planck-Gesellschaften) realisieren könnte. In Martinsried werden mehrere hochauflösende Rasterlektronenmikroskope aufgebaut. Alle Bilddaten dieser Geräte werden ans RZG übertragen,
dort gespeichert, und auf dem dortigen Hochleistungsrechner werden aus den Daten dreidimensionale
Bilder berechnet. Um die Datenmengen in angemessener Zeit übertragen zu können, sind Verbindungen
mit 100 Gbit/s erforderlich. Da es in Martinsried keine nennenswerte Datenhaltung mehr geben wird, ist
eine ausfallsichere Verbindung zwingend notwendig, um den Betrieb in Martinsried auch aufrecht erhalten
zu können, falls eine Verbindung längere Zeit ausfallen sollte.
Da im MWN nur einzelne, angemietete Glasfasern zur Verfügung stehen und diese die beschränkende
Ressource darstellen, war der Gedanke naheliegend, diese mittels eines DWDM-Systems (DWDM =
Dense Wavelength Division Multiplex) gleichzeitig für das MWN-Backbone und für die MPG Anwendungen
zu nutzen.
In Zusammenarbeit von MPG und LRZ wurde überlegt, wie man redundant über mehrere Wege solch ein
System ins MWN einbringen könnte. Danach wurde eine erste technische Auswahl durchgeführt, sowie ein
Anforderungskatalog erstellt. Auf dieser Basis wurde eine EU-weite Ausschreibung (Teilnehmerwettbewerb) vorbereitet und durchgeführt. Diese Ausschreibung wurde von T-Systems mit Produkten des Herstellers ADVA gewonnen und die Geräte wurde zum Jahreswechsel 2014 / 2015 beschafft.
Aus Kostengründen wurde erst einmal darauf verzichtet, die 100 GE Strecke komplett redundant zu realisieren. Vielmehr sollte die redundante Strecke, in der Startkonfiguration, ein Fallback auf 10 GE gewährleisten. Im Zuge der DWDM Einführung sollten auch im MWN-Backbone die Strecken zwischen Garching
und der Innenstadt München auf 2 x 10 GE aufgerüstet werden. Da keine durchgehenden Glasfasern von
Martinsried nach Garching vorhanden sind, werden die DWDM-Strecken in Teilabschnitte aufgeteilt:
Rechter-Ast: Martinsried-Neurobiologie (MN) – Großhadern (I), Großhadern (I) – LMU-Stammgelände (G),
LMU-Stammgelände (G) – Garching-Maschinenwesen (MW), Garching-Maschinenwesen (MW) – RZG
Linker-Ast: Martinsried-Biochemie (MB) – Großhadern (I), Großhadern(I) – TUM-Stammgelände (B),
TUM-Stammgelände (B) – Garching-Katalysezentrum (KaTUM), Garching-Katalysezentrum (KaTUM) –
RZG
Eine schematische Darstellung der Wegeführung mit den notwendigen Komponenten kann der Abbildung
64 entnommen werden.
Der Einbau der WDMs bedeutet einen grundlegenden und kritischen Umbau des gesamten Backbones
und wird deshalb im Rahmen eines Major Changes im ersten Quartal 2015 durchgeführt werden.
114
Abbildung 64: Grundlegende Struktur der DWDM-Infrastruktur zwischen Martinsried und Garching
11.1.3 Struktur der Gebäudenetze im MWN
In den Gebäuden, die durch das MWN miteinander verbunden werden, existiert grundsätzlich eine strukturierte Verkabelung, bestehend aus Kupferkabeln (Twisted Pair (TP) der Kategorie 5/6/7) oder MultimodeLichtwellenleiter-Kabeln (50/125 µm). In einigen Bereichen ist allerdings nur eine alte Vier-Draht-Verkabelung verfügbar, die keine Verbindungen mit Gigabit-Ethernet gestattet und beim Betrieb mit modernen Switches Probleme bereitet. Inzwischen wurden Mittel zur Ersetzung durch eine 8-Draht-Verkabelung nach
Kategorie 6a genehmigt und bereits einzelne Gebäudeteile saniert. Bis die alte Verkabelung vollständig
ersetzt ist, wird es allerdings noch einige Jahre dauern. Zu einem sehr geringen Anteil ist in einigen Gebäuden auch noch Ethernet-Koax-Kabel (Yellow Cable) vorhanden.
Als aktive Komponenten zur Verbindung mit den Endgeräten werden (Layer-2-) Switches eingesetzt. Derzeit sind in den Gebäude- und Etagenverteilern vor allem Geräte der Serien HP 4200 und HP 5400 im
Einsatz. Hierbei handelt es sich um modulare Switches, in die maximal 8 (HP 4200) bzw. 12 (HP 5400)
Linecards eingebaut werden können. Damit ergibt sich eine maximale Anzahl von 192 Gigabit-Ports beim
115
HP 4200 und 288 beim HP 5400. Beim HP 5400 können außerdem bis zu 96 10GE-Ports in einem Chassis
zur Verfügung gestellt werden. Linecards mit höheren Geschwindigkeiten (40 Gbit/s oder 100 Gbit/s) sind
derzeit noch nicht verfügbar. In Gebäuden mit nur sehr wenigen Anschlüssen kommen auch Switches mit
fester Portanzahl (stackable Switches) zum Einsatz. Switches dieser Bauform kommen ebenfalls in Serverräumen zum Einsatz.
2014 wurden 19 HP 4100 mit ca. 1.500 Ports ersetzt.
Zum Jahresende 2014 wurden vom LRZ insgesamt 1.469 Switches betrieben. Einen Vergleich zu den
Vorjahren zeigt Tabelle 19:
Die Verteilung nach Switch-Typen ist in Abschnitt 16.10.2 zu finden.
Tabelle 19: Anzahl der im MWN eingesetzten Switches
Ende 2014 Ende 2013 Ende 2012 Ende 2011 Ende 2010 Ende 2009
Anzahl Switches
davon HP-Switches
1.469
1.406
1.310
1.247
1.126
990
1.468
1.405
1.309
1.246
1.125
989
1
1
1
1
1
1
92.868
89.616
81.090
77.562
67.040
60.363
7.689
7.384
7.687
7.599
6.842
6.493
davon Cisco-Switches
Anzahl TP-Ports
Anzahl Glasfaser-Ports
Die Verteilung nach Switch-Typen ist Abschnitt 0 zu finden.
Switchports
120.000
100.000
80.000
60.000
40.000
20.000
0
2007
2008
2009
2010
2011
2012
2013
2014
Abbildung 65: Entwicklung bei der Anzahl der Switchports
11.1.4 Struktur des Rechenzentrumsnetzes (LRZ-Netz)
Ein wichtiger Punkt für eine möglichst nahtlose und störungsfreie Diensterbringung durch das LRZ sind
geeignete Redundanzmechanismen, die sich natürlich auch im zugrundeliegenden Netz widerspiegeln
müssen.
116
Abbildung 66 stellt die Struktur des Kernnetzes im Rechnergebäude des LRZ dar. Das Grundprinzip hierbei
ist, dass jede kritische Komponente und jede Verbindung mindestens doppelt vorhanden ist. Über geeignete Mechanismen ist dafür zu sorgen, dass bei Ausfall einer Komponente oder einer Verbindung der Datenverkehr vollautomatisch über redundante Wege und Komponenten abgewickelt werden kann. Um auch
gegen Infrastrukturprobleme oder größere Schäden wie z.B. Brände gewappnet zu sein, sind alle Komponenten konsequent auf zwei verschiedene Brandabschnitte in zwei Gebäudeteilen verteilt. In Abbildung 66
sind alle Komponenten (bis auf die SuperMUC Switches) links von der Mitte im NSR 0 im Altbau des Rechnerwürfels, die Komponenten rechts von der Mitte im DAR I im Erweiterungsbau untergebracht.
Abbildung 66: Struktur des LRZ-Netzes
Das Zentrum des Rechenzentrums-Netzes bilden eine Reihe von Switches (HP) mit einer Bandbreite von
2x10 GBit/s (2x10 GE) und ein vPC (Virtual-Port-Channel)-Paar von Cisco Switches. Das vPC Protokoll ist
eine Virtualisierungstechnologie, die Layer 2 Geräte, wie Switches oder Endgeräte (Server, o.ä.), ein Cisco
Nexus Paar wie ein Gerät (Switch) auf Layer 2 Ebene erscheinen lassen. vPC gehört zur Familie der Multichassis EtherChannel (MCEC) Technologien. Die am LRZ eingesetzten vPC Geräte sind Cisco Nexus
7010. Die Chassis des vPC Paars (cvr1-1wr, cvr1-2wr) sind räumlich getrennt, in zwei verschiedenen
Brandabschnitten des Rechnergebäudes untergebracht, genauso wie die zentralen HP-Switches und die
Firewalls. Das vPC Paar wirkt für den Nutzer wie ein einzelnes Gerät. So können z.B. Verbindungen (sog.
Port-Channels) geschaltet werden, die auch beim vollständigen Ausfall eines der beiden Chassis weiterhin
funktionieren. Die Layer 3 (Routing)-Redundanz wird mittels des Hot-Standby-Routing-Protocols (HSRP)
realisiert. Die Verbindung zum MWN erfolgt von jedem der Nexus-Geräte aus, separat aber redundant,
über Routing-Protokolle.
Die Anbindung der Systeme und Dienste erfolgt über den Verbund von Zentralswitches. Das vPC NexusPaar und die zentralen HP Switches sind mehrfach redundant miteinander verbunden (siehe Abbildung
66). Die dadurch entstehenden Schleifen werden durch den Einsatz des Spanning-Tree-Protokols (STP)
verhindert. STP schaltet beim Ausfall einer Verbindung automatisch im Bereich von Millisekunden auf eine
andere Leitung um. Die verschiedenen physischen, aber auch die virtualisierten Server sind dann auch
117
wieder jeweils redundant über zwei verschiedene Zentralswitches und über zwei auch räumlich getrennte
Verbindungen am Netz angeschlossen.
Der SuperMUC und das SuperNAS sind über zwei dedizierte Cisco Nexus 7010 redundant angebunden
(siehe Abbildung 66). Eines dieser Geräte übernimmt auch die Verbindung des SuperMUC-Systems an
den europäischen PRACE-Verbund. Das Linux-Cluster wird über einen Cisco Nexus 7018 Switch versorgt.
Für diese Systeme ist derzeit keine netztechnische Redundanz erforderlich bzw. wäre in der Realisierung
zu teuer.
11.2 Anschluss ans MWN und wesentliche Änderungen im Netz
In einem Netz mit so vielen Standorten wie dem MWN ergeben sich naturgemäß sehr viele Änderungen in
der Netzstruktur. Dies wird verursacht durch Änderungen in der Nutzung von Standorten, neuen Strandorten, der Aufgabe von Standorten sowie Sanierungen an Gebäuden und Netzen. Diese Veränderungen
werden in den nächsten Abschnitten erläutert. Daneben gibt es aber auch struktuelle Änderungen, um die
Redundanz und damit die Stabilität und Ausfallsicherheit des Netzes zu erhöhen oder neue Kundengruppen ans Münchner Wissenschaftsnetz anzubinden. Im Berichtsjahr wurden einige staatliche Museen, auch
außerhalb des Großraums München, neu ans MWN angebunden (vgl. Abschnitt 11.2.1.1), außerdem
wurde die Redundanz am Campus Garching verbessert (vgl. Abschnitt 11.2.3).
11.2.1 Wesentliche Netzänderungen im Jahr 2014
Im Jahr 2014 gab es folgende, in chronologischer Reihenfolge aufgeführte, wesentliche Netzveränderungen:
Tabelle 20: Wesentliche Netzänderungen 2014
Abschlußdatum
Netzänderung
20.01.14
Neuanschluss und Netzinbetriebnahme des Infraschall-Labors im Messbunker in Garching
06.02.14
Wiederinbetriebnahme des Versuchsgut Grünschwaige für die Hochschule Weihenstephan-Triesdorf
11.02.14
Erhöhung der Bandbreite des Klinikums Großhadern auf 10 Gbit/s
20.02.14
Neuanschluss Lazarettstr. 67; TUM Munich School of Engineering (MSE)
21.02.14
Wiederanschluss des „Schachthauses“ am Botanischen Garten nach Renovierung
06.03.14
Erhöhung der Bandbreite der Pinakotheken auf 1 Gbit/s
14.03.14
Neuanschluss des Studentenwohnheims Haidpark
17.03.14
Rückbau Datennetz Lothstraße 17 wegen Umbau
19.03.14
Neuanschluss des Munich Institute for Astro- and Particle Physics (MIAP) auf dem Gelände es IPP in Garching
16.04.14
Neuanschluss der forstwissenschaftlichen Versuchsstation im Kranzberger Forst mittels
LTE
29.04.14
Erhöhung der Bandbreite der Limnologischen Station der TUM in Iffeldorf auf 100 Mbit/s
09.05.14
Neuanschluss des Neubaus „Gartenhaus“ der juristischen Fakultät der LMU in der Veterinärstraße
26.05.14
Redundante Anbindung der Hochschule München ans MWN
03.06.14
Garching, Parkring, Business Campus, TUM: Ersetzung der 1 Gbit/s Strecke durch eine
dark-fibre-Strecke
25.06.14
Erhöhung der Bandbreite für die Backup-Internet Verbindung über M-net auf 10 Gbit/s
118
Abschlußdatum
Netzänderung
01.07.14
Neuanschluss des Neubaus Brau- und Getränketechnologie der Hochschule Weihenstephan-Triesdorf (HSWT)
09.07.14
Neuanschluss des Gebäudes E (Neubau) der HSWT in Triesdorf
22.07.14
Neuanschluss des Neuen Museums Nürnberg ans MWN
24.07.14
Neuanschluß der Anmietung der TUM Schleißheimer Str. 90A in Garching
29.07.14
Erhöhung der Anbindung von Oberschleißheim (Veterinärmedizin der LMU) auf 10 Gbit/s
04.08.14
Neuanschluss des Max-Planck-Instituts für Psychatrie in der Kraepelinstraße mit 10 Gbit/s
29.08.14
Neuanschluss des Bayerischen Armeemuseums in Ingolstadt
01.09.14
Wiederanschluss des Lehrstuhls E14, TUM Physik-Department
21.10.14
Erhöhung der Bandbreite des IMETUM in Garching auf 10 Gbit/s
24.10.14
Erhöhung der Bandbreite in der Augustenstr. 46 (TUM Verwaltung) auf 1 Gbit/s
27.10.14
Neuanschluss des Neubaus Internationales Getränkewissenschaftliches Zentrum in Weihenstephan (iGZW)
31.10.14
Erhöhung der Bandbreite für den Campus der Tierklinik in Schwabing auf 10 Gbit/s
03.11.14
Neuanschluss der DKFA (Deutschkurse für Ausländer) nach Umzug in die Agnesstraße
05.11.14
Neuanschluss des Innvoations- und Gründerzentrums Biotechnologie (IZB) in Martinsried
06.11.14
Neuanschluss des Deutschen Zentrums für Neurodegenerative Erkrankungen (DZNE) im
Klinikum Großhadern
11.11.14
Erhöhung der Bandbreite für die Botanik der LMU, Menzingerstraße auf 10 Gbit/s
27.11.14
Erhöhung der Bandbreite für das Gebäude der Tierwissenschaften (Geb. 4317) in Freising-Weihenstephan auf 10 Gbit/s
28.11.14
Erhöhung der Bandbreite für das Gebäude der LMU in der Seestraße auf 10 Mbit/s per
Fibre-DSL
02.12.14
Erhöhung der Bandbreite des Theresianums (Geb. 0506) am Stammgeländer der TUM
auf 10 Gbit/s
11.2.1.1 Museen: IT-Beirat der staatlichen Museen
Im Jahr 2012 wurde ein IT-Beirat der staatlichen Museen eingesetzt, um die IT-Infrastruktur zu optimieren
und die Rezentralisierung von IT-Diensten zu ermöglichen. Basis für eine solche Zentralisierung von Museums-IT-Diensten ist eine angemessene Netzanbindung. Da viele Museen in München bereits am MWN
angeschlossen sind und die zentrale IT ebenfalls in München angesiedelt ist, war relativ schnell klar, dass
das MWN für diese Zwecke mitgenutzt werden soll. Im Jahr 2014 wurden deshalb das Bayerische Armeemuseum in Ingolstadt, das Neue Museum Nürnberg sowie das Deutsche Theatermuseum in München neu
ans MWN angebunden.
11.2.2
Netzausbau (Verkabelung); Netzinvestitionsprogramm
Mit dem Netzinvestitionsprogramm in Bayern (NIP) wurde zwar eine flächendeckende Vernetzung erreicht,
diese ist jedoch an der TUM in München und Garching noch zu einem sehr geringen Teil in Koax ausgeführt. Bis Ende 2008 sollte diese Koax-Verkabelung durch eine strukturierte Verkabelung (Kupfer oder
Glasfaser) ersetzt werden. Das Ziel wurde aber nicht erreicht, da einige Gebäude noch auf eine endgültige
Generalsanierung warten bzw. es unklar ist, welche spätere Nutzung dort vorgesehen ist.
119
11.2.2.1 TU München
Derzeit gibt es noch Koax in Bau 0503, 0106 (N6) und zum Teil in Gebäude 5402 (CH2 in Garching); hier
soll aber Koax im Rahmen anderer Maßnahmen ersetzt werden.
Für das Gebäude 0503 auf dem TUM Stammgelände steht die große Baumaßnahme der kompletten
Gebäudesanierung ab 2015 an. Im Rahmen dieser Sanierungsmaßnahme wird auch die Datenverkabelung
erneuert und die Koaxverkabelung komplett zurückgebaut. Aktuell befindet sich das Projekt in der Ausschreibungsphase.
Mit einer strukturierten Verkabelung der Kategorie 6A wurden folgende TUM-Gebäude im Jahr 2014
ertüchtigt:
Garching
Ottobrunn
Straubing
Neubau Entrepreneurship-Center
Neubau Algentechnikum auf dem Ludwig Bölkow-Campus
Wissenschaftszentrum Straubing - Neuverkabelung ehemaliges VHS-Gebäude
11.2.2.2 LMU
Im Bereich der LMU München sind alle Gebäude mit einer strukturierten Verkabelung versehen. Es gibt
jedoch teilweise Defizite in der Verwendung der installierten Medien (nur vier-drahtiger Anschluss (Cablesharing) oder Installation von Kategorie 5 - Kabeln bzw. Anschlusskomponenten). Dies betrifft noch 24
Gebäude (NIP V–2.Bauabschnitt). Die Kosten für die Sanierung dieser Gebäude in Höhe von ca. 10 Mio. €
wurden vom Landtag zum großen Teil bereits freigegeben.
Diese Gebäude werden ab 2015 im Rahmen des 2. Bauabschnittes der NIP V-Maßnahme mit einer
Verkabelung der Kategorie 6A modernisiert.
11.2.2.3 Weihenstephan (TU München)
Auf dem Campus Weihenstephan der TU München sind alle Gebäude mit einer strukturierten Verkabelung
versehen, entweder Kupfer (Kategorie 6-Kabel) oder Glasfaser (Multimode).
11.2.2.4 LWL-Netze auf den Campus-Geländen
Auf den Campusgeländen TUM-Stamm/Nordgelände, LMU-Stammgelände, TUM-Garching, TUM-Weihenstephan und LMU Großhadern/Martinsried sind privat verlegte Glasfaserstrecken installiert, die teilweise schon über 15 Jahre existieren. Hier muss in den nächsten Jahren dringend nachgerüstet werden,
da bei einem Teil der Strecken die heute benötigten Glasfasertypen (OM4, Singlemode) nicht vorhanden
sind, diese aber aufgrund der gestiegenen Übertragungsraten notwendig werden. Einige Gebäude sind
sogar nur mit Multimode Glasfasern erschlossen. Damit ist eine Anbindung mit mehr als 1 Gbit/s praktisch
nicht möglich.
11.2.3
Redundante LWL-Verkabelung und zweiter zentraler
Netzknoten auf dem Campus Garching
Im Jahr 2013 wurde in enger Kooperation von TUM und LRZ ein Konzept zum Ausbau der LWL-Infrastruktur am Campus Garching zur Erhöhung der Redundanz erstellt. Von der TUM wurden erhebliche finanzielle
Mittel aufgewendet, um die privat verlegte LWL-Infrastruktur am Campus Garching nach diesem Konzept
auszubauen.
Die wesentliche Anforderung für diese Nachrüstung war die redundante Anbindung der Areale der Informatik, der Physik, der Chemie sowie des Maschinenwesens unter Einbeziehung des LRZ. Eine redundante
LWL-Anbindung mit zwei Strecken erfordert eine unabhängige Wegeführung für die entsprechenden Faserpaare. Dies lässt sich im Normalfall nicht ohne massive Tiefbauarbeiten realisieren. In Garching konnte
jedoch der bestehende Hochschulkanal für diesen Zweck verwendet werden. Dieser Versorgungskanal ist
zweizügig. Es gibt einen sogenannten warmen sowie einen kalten Kanal, die baulich so voneinander getrennt sind, dass weder ein Brand von einem Kanal auf den anderen übergreifen kann, noch „normale“
Erdarbeiten beide Kanäle so beinträchtigen können, dass beide LWL-Strecken beschädigt werden.
Diese Maßnahme war die Voraussetzung, um auch das Konzept für den zentralen Netzknoten in Garching,
der sich im Maschinenwesen befindet, zu überarbeiten und auch hier ein ausfallsicheres Setup vergleichbar
120
dem im Rechnerwürfel des LRZ aufzubauen (vgl. Abschnitt 11.1.4). Es wurde ein redundanter Kernnetzknoten im neu errichteten Katalysezentrum bei der Chemie eingerichtet. An dem Standort erfolgte 2014
der Aufbau eines zweiten Routers (Cisco Nexus 7010) für den Campus Garching. Damit gibt es einen
zweiten, räumlich getrennten zentralen Netzknoten am Campus Garching. Die Router im Maschinenwesen
und im Katalysezentrum sind mittels vPC (virtual Port-Channel) verbunden. Damit ist es möglich, von den
Gebäudeswitches redundante Anbindungen zum MWN Backbone aufzubauen.
Derzeit laufen beide gemieteten Glasfasern aus der Innenstadt noch am Knoten im Maschinenwesen auf,
d.h. falls es dort z.B. zu einem Brand kommen würde, und beide Fasern beschädigt würden, wäre keine
Verbindung in die Innenstadt mehr möglich. Aus diesem Grund ist es für 2015 geplant, den Endpunkt der
LWL aus dem Stammgelände der TU nach Garching vom Maschinenwesen in das Katalysezentrum umzuverlegen.
11.2.4
Anbindung Studentenwohnheime
Das LRZ ermöglicht Wohnheimen eine feste Anbindung über Standleitung, DSL-Technik oder Funk an das
MWN und damit an das Internet. Die Kosten der Anbindung hat der Heimträger zu übernehmen, für die
Netznutzung werden aber keine Gebühren erhoben. Für kommerzielle Heime, ohne öffentliche Förderung,
ist der Zugang ins Internet über das MWN nur über eine VPN-Verbindung möglich.
Zum Jahresende 2014 sind 12.468 Wohnheimplätze in 52 Heimen an das MWN angeschlossen, davon 34
über eine Glasfaserleitung (LWL) mit 100 Mbit/s bis zu 2 Gbit/s, 2 über FibreDSL mit 10 Mbit/s, 9 über
Funkstrecken, 2 über DSL, eines über Mikrowellenfunk, eines über 100 MBit/s Laserlink sowie 2 über einen
VPN-Tunnel. In 2 Heimen wird nur das WLAN vom LRZ betrieben.
Die nachfolgende Tabelle zeigt die Wohnheime, die Ende 2014 am MWN angeschlossen sind.
Tabelle 21: Die Ende 2014 an das MWN angeschlossenen Wohnheime
Name
Adresse
Träger
Plätze
Anschluss
Studentenstadt Freimann
Christoph-ProbstStraße 10
Studentenwerk
2.440
LWL zu MPI Freimann
Studentenviertel auf
dem Oberwiesenfeld
Helene-MayerRing 9
Studentenwerk
1.853
LWL zu ZHS
Kreittmayrstraße
Kreittmayrstraße
14
Studentenwerk
45
LWL zu TUM
Adelheidstraße (mit
Deutschkurse für Ausländer)
Adelheidstraße 13
Studentenwerk
374
LWL zu TUM
John-Mott-Haus
Theo-Prosel-Weg
16
CVJM München
e.V.
67
Funk zu Winzererstr.
Oberschleißheim
Oberschleißheim
Am Schäferanger
9-15
Studentenwerk
171
LWL zu Rinderklinik
Ökumenisches Studentenheim
Steinickeweg 4
Verein evangelischer Studentenwohnheime
78
Funk zu TUM-Uhrenturm
Hugo-Maser-Haus
Arcisstr. 31
Verein evangelischer Studentenwohnheime
72
Name
Adresse
121
Träger
Plätze
Anschluss
St. Albertus Magnus
Haus
Avenariusstraße
15 (Pasing)
St. Albertus Magnus-Stiftung (Kath.)
108
SDSL M-net
Wohnheimsiedlung
Maßmannplatz
Heß-Straße 77
Wohnheimsiedlung
Maßmannplatz e.V.
124
Funk zu HM Dachauerstraße
Jakob Balde Haus
Theresienstraße
100
Studienseminar
Neuburg-Donau
110
LWL zu TUM
Internationales Haus
Adelheidstraße 17 Studentenwerk
93
über Adelheidstr. 13
angeschlossen
Stettenkaserne
Schwere Reiter
Str. 35
Studentenwerk
242
M-net LWL
Heidemannstraße
Paul-HindemithAllee 4
Studentenwerk
310
M-net LWL
Felsennelkenanger
Felsennelkenanger 7-21
Studentenwerk
531
M-net LWL
Heiglhofstraße
Heiglhofstraße
64/66
Studentenwerk
415
Telekom LWL
Sauerbruchstraße
Sauerbruchstraße
Studentenwerk
259
M-net LWL
Garching I
Garching, Jochbergweg 1-7
Studentenwerk
110
Telekom LWL
Garching II
Garching, Enzianstraße 1, 3
Studentenwerk
114
LWL zu TU-Heizkraftwerk
Dominohaus
Garching, Unterer
Strassäcker 21
Dominobau
82
LWL zu TU-Heizkraftwerk
Türkenstraße
Türkenstraße 58
Studentenwerk
97
LWL zu Theresienstraße
Intern mit Funk vernetzt
Weihenstephan II
Giggenhauser Str.
25, 85354 Freising
Studentenwerk
226
LWL über Weihenstephan IV
Lange Point (Weihenstephan III)
Lange Point 1-35,
85354 Freising
Studentenwerk
384
LWL zu HSWT
Heizhaus
Weihenstephan IV
Giggenhauser Str.
Studentenwerk
27-33
237
LWL zur Telefonzentrale
122
Name
Adresse
Träger
Plätze
Anschluss
Vöttinger Straße (Weihenstephan I)
Vöttinger Straße
49, 85354 Freising
Studentenwerk
113
LWL zu alter DVS
Stiftung Maximilianeum
Max-Planck-Str. 1
Stiftung Maximilianeum
26
Funk zu KH Rechts
der Isar
Studentenheim "Paulinum"
Rambergstraße 6,
80799 München
Studentenwohnheim Paulinum e.V.
(Kath.)
58
Albertia, Ottonia, Erwinia
Gabelsbergerstr.
24
Stud.-Verbindungen
Albertia, Ottonia, Erwinia
25
Funk zu Richard
Wagner Str. 18
Wohnheim Richard
Wagner-Str. 16
Richard-WagnerStr. 16
Ingeborg van-Calker
Stiftung
33
LWL zu Richard
Wagner-Str. 18
Hochschulhaus Garching
Enzianstr. 5
Evangelische Studentenwohnheime
95
LWL zu Wohnheim
Garching II
Spanisches Kolleg
Dachauerstraße
145
Katholische Kirche
35
Funk 802.11a zur
HM
Chiemgaustraße
Traunsteiner
Straße 1-13
Studentenwerk
436
Telekom-LWL zu
TUM
Am Anger I
Unterer Anger 2
Orden der Armen
Schulschwestern
50
M-net FibreDSL
Am Anger II
Unterer Anger 17
Orden der Armen
Schulschwestern
85
M-net FibreDSL
Wohnheim Stiftsbogen
Schröfelhofstraße
4
Studentenwerk
588
LWL zu Campus
Großhadern
Priesterseminar St. Johannes der Täufer
Georgenstraße 14
Katholisches Ordinariat
28
Funk zu Georgenstr. 11
Johannes-Hanselmann-Haus
Kaulbachstr. 25
Ev. Waisenhausverein
117
LWL zu Staatsbibliothek
Marie-Antonie-Haus
Kaulbachstr. 49
Studentenwerk
96
LWL zu Ludwigstr.
28
Studentenwohnanlage
Biederstein
Biedersteiner Str.
24-30a
Studentenwerk
168
LWL zu Amalienstr.
17
Sophie-Barat-Haus
Franz-Josef-Str. 4
106
LWL zu Ordinariat
Name
Adresse
Johann-Michael-Sailer-Haus
Preysingstr. 93a
Heinrich-Groh-Str.
123
Träger
Plätze
Anschluss
26
LWL zu Ordinariat
Heinrich-Groh-Str.
Studentenwerk
17
59
LML zu 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 Mikrowellenfunk
Oskar von Miller Forum
Oskar von Miller
Ring 25
Oskar von Miller Forum
80
LWL zu Amalienstr.
17
Herzogliches Georgianum
Prof. Huber Platz
1
Erzdiözese München-Freising
45
ADSL, intern WLAN
Rosenheim I
Marienberger Str.
36-38
Rosenheim
Studentenwerk
113
über Tunnel und
Secomat
Rosenheim II
Westendorfer Str.
47a-m
Rosenheim
Studentenwerk
342
über Tunnel und
Secomat
Frauendorfer Haus
Notburgastr. 1923
Studentenwerk
137
LWL zu Amalienstr.
17
Lothstraße
Lothstr. 62
Studentenwerk
62
LWL zu Dachauer
Str. 98b
Studentenwohnheim
Freimann
Josef-Wirth-Weg
21
Grammer Immobilien
449
LWL zu Amalienstr.
17
Haidpark
Admirabogen 3749
Münchner Arbeiterwohlfahrt
204
Nur WLAN vom
LRZ
Summe insgesamt
12.468
52 Wohnheime
11.3 DNS und Sicherheit im DNS
Der Domain Name Service (DNS) im Internet dient dazu, lesbare Namen anstelle von IP-Adressen verwenden zu können. Im weltweiten Verbund dienen die Domain-Nameserver zur Auflösung (Resolving) der
Domainnamen, d.h. sie liefern für einen Verbindungsaufbau die IP-Adresse zum verwendeten Domainnamen. Die Namen sind hierarchisch strukturiert, wobei die einzelnen Stufen durch Punkte getrennt geschrieben werden. Die höchste Ebene (Top Level Domain) steht dabei ganz rechts und bezeichnet häufig das
Land (z.B. "de" für Deutschland). Die zweite Stufe steht dann für die Organisation bzw. Firma (z.B. lrz.de).
Im Bereich des MWN bietet das LRZ die Möglichkeit, über seine Nameserver den DNS-Dienst für Einrichtungen im MWN zu erbringen. Daneben betreiben einige Fakultäten und Institute für ihre Bereiche auch
eigene Nameserver. Ziel ist aber die weitgehende Zentralisierung des Dienstes über die hochverfügbaren
124
und gut gepflegten Server des LRZ. Der DNS-Dienst wird mandantenfähig angeboten. Über eine Webschnittstelle (Webdns) können Netzverantwortliche die Ihnen zugewiesenen Namensräume selbstständig
verwalten.
Der Webdns-Dienst wird inzwischen von 345 Nutzern zur Pflege der DNS-Einträge verwendet. Die Anzahl
der über Webdns verwalteten DNS-Zonen stieg von 2.467 auf 2.566.
Die Registrierung von Second-Level-Domains erfolgt jetzt über den Reseller InternetX, da dieser gegenüber der früher in Anspruch genommenen Firma Dopoly bessere Verwaltungsmöglichkeiten erlaubt und
außerdem noch günstigere Preise bietet. Es wurden 92 neue Domains unter verschiedenen Toplevel-Domains (z.B. de, org, eu, bayern [neu]) für Institute und Organisationen registriert, 32 wurden von anderen
Providern transferiert.
Die folgenden Bilder zeigen die Frequenz der Anfragen für den authoritativen und den Resolving-Dienst in
Anfragen pro Sekunde (qps, queries per second).
Abbildung 67: Statistik für alle DNS-Server (Autoritativ)
Abbildung 68: Statistik für alle DNS-Resolver
Die folgende Tabelle zeigt eine Übersicht über die wichtigsten Domains im MWN. Die reale Anzahl der
Zonen und Einträge ist um einiges höher, kann aber nicht exakt ermittelt werden, da viele Instituts-Server
keine Auflistungs-Abfragen beantworten. Dies ist auch der Grund, warum einige Zahlen gegenüber 2013
kleiner ausfallen.
Die Spalte A-Records bezeichnet die IPv4 Einträge, AAAA-Records die für IPv6 und MX-Records beinhaltet
die Mail-Server.
125
Tabelle 22: Übersicht über die wichtigsten Domains im MWN
Zone
Zonen
Sub-Domains
A-Records
AAAARecords
Aliase
MX-Records
Mail-Do- WWWmains Records
uni-muenchen.de
369
2.157
9.843
2.932
3.867
3.532
1.619
1.284
lmu.de
113
1.316
4.376
957
2.483
3.062
1.422
1416
tu-muenchen.de
266
1.954
19.632
1.471
1.733
7.564
7.167
259
tum.de
424
5.992
17.923
3.061
4.330
2.282
1.867
1.463
49
78
2.991
0
230
538
225
30
fh-weihenstephan.de
2
28
45
0
27
2
2
5
hswt.de
0
40
143
0
72
3
3
8
badw-muenchen.de
23
64
45
0
33
92
44
48
badw.de
23
73
2
0
128
86
43
29
lrz-muenchen.de
17
127
303
21
166
23
12
2
lrz.de
97
655
30.536
3.397
1.966
46
23
12
mhn.de
61
1.050
1.610
82
1.230
282
106
126
mwn.de
47
207
206.908
177
310
39
19
68
Gesamt
1.491
11.959
294.357
12.098
16.575
17.551
12.552
4.750
fh-muenchen.de
Insgesamt sind 634 Second-Level-Domains auf den Nameservern des LRZ konfiguriert.
11.3.1
DNS-Amplification-Attacks und offene Resolver
Eine sogenannte DNS-Reflection-Attack bzw. DNS-Amplification-Attack (Reflection-Attack mit Verstärkung) dient dazu, das Angriffsziel durch enormes IP-Verkehrsaufkommen zu überlasten. Der Angreifer verschickt dazu DNS-Anfragen (viele, bevorzugt klein und verteilt) mit gefälschter Absenderadresse (der Adresse des Angriffsziels) an einen oder mehrere offene Resolver, d.h. an DNS-Server, die rekursive Anfragen aus dem Internet beantworten. Der Resolver antwortet auf die Anfragen an die gefälschte Absenderadresse (das Angriffsziel) und speichert die Daten in seinem Cache. Diese (möglichst großen) Einträge
können auf autoritativen Servern des Angreifers oder auf kompromittierten autoritativen Servern liegen, es
können aber auch beliebige „normale“ Einträge (z.B. DNSKEY) sein, die der Angreifer vorher ausfindig
gemacht hat. Sowohl große DNS-Records als auch viele Anfragen von einer Adresse (z.B. durch NAT)
können legitim sein. Der Angreifer kann den Effekt noch dadurch verstärken, dass er von vielen Rechnern
(einem sog. Botnet) aus die Anfragen mit der gefälschten Absenderadresse startet. Abbildung 69 stellt das
Prinzip des Angriffs dar. Selbst wenn Heuristiken zur Angriffserkennung greifen, kann der Angreifer den
Angriff verfeinern (mehr unterschiedliche Records, mehr offene Resolver etc.).
Solange IP-Spoofing nicht verhindert wird, gibt es keine grundsätzliche Lösung für das Problem. Die Wirkung von Gegenmaßnahmen beschränkt sich darauf, den Angriff abzuschwächen oder den Aufwand für
den Angreifer zu erhöhen. Offene Resolver sind ein essentieller Bestandteil des Angriffs, gleichzeitig gibt
es fast nie gute Gründe für den Betrieb eines offenen Resolvers, verständlicherweise sind offene Resolver
daher nicht gern gesehen.
Durch Scans nach offenen Resolvern in 2013 und der Aufforderung an die zuständigen Netzverantwortlichen, die Konfiguration zu bereinigen, konnte die Anzahl stark verringert werden. Seit Februar 2014 werden
keine eigenen Scans mehr durchgeführt, da dies zentral durch den DFN durchgeführt wird. Es werden
allerdings nur noch sehr wenige offene Resolver gefunden. Die Netzverantwortlichen werden dann aufgefordert, ihre Konfiguration zu bereinigen.
126
Abbildung 69: Funktionsweise der DNS Amplification Attack
11.3.2
DNSSEC
Im Jahr 2014 wurden große Schritte zur kryptographischen Absicherung der DNS-Inhalte durch den Standard DNSSEC vollzogen. Nachdem in den Jahren davor nur einzelne Testdomains mit den neuen Fähigkeiten ausgestattet waren, wurde im Jahr 2014 ein sogenannter DNSSEC-Signing-Proxy in Betrieb genommen. Dieser ist in der Lage, auf WebDNS verwaltete Zonen transparent mit DNSSEC-Signaturen auszustatten. Die sichere Delegation wurde unter anderem für die Domains lrz.de, tum.de und lmu.de erfolgreich
durchgeführt. Damit nimmt das LRZ im Bereich der Hochschuldomains einen Spitzenplatz bei der DNSSEC-Abdeckung ein.
Alle Resolver, die das LRZ betreibt, validieren seit Anfang 2014 DNSSEC, d.h. wenn ein Nutzer aus dem
MWN einen Namen in einer DNSSEC signierten Zone abfragt, so überprüfen die LRZ-Resolver die digitalen
Signaturen. Ein Spoofing von DNS Einträgen kann damit wirkungsvoll verhindert werden.
Durch DNSSEC werden weitere Schritte zur Absicherung ermöglicht. Beispielsweise wurden Ende 2014
die Zertifikatsinformationen der eingehenden Mailserver (postrelay/mailrelay) in der Zone lrz.de mit dem
Standard TLSA/DANE veröffentlicht. Dadurch können DANE-fähige Absender eine verifizierte TLS-Verbindung mit den LRZ-Servern aufbauen und Man-in-the-Middle-Angriffe verhindern.
Es ist bereits jetzt ein hohes Interesse seitens der Universitäten an der sicheren Delegation ihrer DNSInhalte festzustellen. Im Jahr 2015 werden daher auch weitere Subdomains signiert werden. Dazu sind
weitere Schritte bei der Automatisierung geplant, um den Arbeitsaufwand möglichst gering zu halten und
Fehler durch manuelle Arbeitsschritte zu vermeiden.
11.4 DHCP
Seit ca. 10 Jahren betreibt das LRZ einen DHCP-Dienst, der von allen Münchner Hochschulen für die
automatische IP-Konfiguration von institutseigenen Rechnern genutzt werden kann. Außerdem wird dieser
Dienst für einige zentrale Anwendungen verwendet, wie z.B. für die WLAN-Zugänge im MWN oder die
Netzanschlüsse in Hörsälen und Seminarräumen. Insgesamt wird der DHCP-Dienst von 238 Instituten genutzt und verwaltet dabei 1.003 Subnetze mit über 176.000 IP-Adressen. Falls gewünscht, tragen die
DHCP-Server die Namen der Clients auch automatisch in die zugeordnete Zone auf den zuständigen DNSServern ein (Dynamic DNS).
Der DHCP-Dienst läuft auf denselben Servern wie DNS (Standorte: LMU-Stammgelände, TU-Stammgelände, LRZ Garching und Weihenstephan). Jeden größeren Router-Standort bedient ein eigenes FailoverPaar, wobei die Paare je auf 2 DNS-Server verteilt sind. Die Server sind räumlich getrennt und über mehrere Routen erreichbar, sollte also einer der Server oder eine Route zum Server ausfallen, übernimmt ein
127
anderer Server bzw. eine andere Route. Die Konfiguration der Server wird zentral in einem SubversionRepository verwaltet und automatisch auf Fehler überprüft. Das Monitoring erkennt nicht nur Ausfälle eines
Servers, sondern auch einen Synchronisationsausfall der Failover-Peers und Netze ohne verfügbare IPAdressen.
Abbildung 70: DHCP-Infrastrkutur auf den DNS-Servern
Durch Übermitteln einer CSV-Datei kann ein Bereich von Adressen statisch definiert werden.
Der DHCPv6-Dienst wird ebenfalls auf den DNS-Servern betrieben. Da das LRZ den DHCPv6-Dienst stateless betreibt, kann der Dienst über Anycast erreicht werden. Fällt einer der Server aus, schwenkt die
Anycast-Route automatisch zu einem anderen Server, der DHCP-Dienst ist also mehrfach redundant.
11.5 Radius
Über Radiuszonen können einzelne Institutionen für ihre Beschäftigten bzw. Studierenden die Berechtigung für den Wählzugang und andere Netzdienste, wie VPN, Eduroam oder Authentifizierung am Netzrand
selbst verwalten. RADIUS steht für „Remote Authentication Dial-In User Service“. Ein Schema der physischen Struktur des RADIUS-Dienstes zeigt Abbildung 71.
Die Funktionsweise ist folgende:
Nutzer verbinden sich zu einem RAS (Remote Access Server), das kann ein VPN-Server, ein EinwahlServer, ein WLAN-Access-Point, ein Access-Switch, etc. sein. Diese RAS-Geräte schicken die Authentifizierungs-Anfragen an den RADIUS-Proxy-Dienst weiter, der über eine virtuelle IP-Adresse an unseren
SLBs (Server-Load-Balancer) erreichbar ist. Der RADIUS-Proxy seinerseits wählt anhand der Zonenbezeichnung (siehe weiter unten) den Authentifizierungs-Service aus, der die eigentliche Benutzerauthentifizierung durchführt. Das kann ein weiterer RADIUS-Server, eine lokale User-Datei, ein LDAP-Server oder
ähnliches sein. War die Authentifizierung erfolgreich, wird eine entsprechende Freigabe an den RAS geschickt, andernfalls wird die Zugangsanfrage abgelehnt.
Die von uns eingesetzte RADIUS Software (FreeRADIUS) unterscheidet zwischen Autorisierung und Authentifizierung. So hat nicht jeder Nutzer, der authentifiziert wird, auch automatisch Zugang zu allen RAS
Geräten.
128
Abbildung 71: RADIUS-Struktur im MWN
Zum Jahresende 2014 waren 49 Radiuszonen konfiguriert. Eine Auflistung der Radiuszonen findet sich im
Jahresbericht 2012.
11.6 Switch-Infrastruktur / Switch-Erneuerung
Das LRZ setzt seit Mitte 2001 Switches vom Typ HP 4100 ein. Zum 01.01.2014 waren hiervon noch 154
Geräte im Einsatz. Dieser Switch-Typ entspricht aber schon seit einigen Jahren nicht mehr dem aktuellen
Stand der Technik:
●
Die Kapazität der Backplane ist auf 4,5 Gbit/s pro Slot begrenzt. Daher gibt es für diesen SwitchTyp keine Module mit 10GE-Ports.
● Es fehlen wichtige Funktionalitäten moderner Switches, wie z.B. die automatische Erkennung von
Schleifen im Netz.
Außerdem wird die Software dieses Switch-Typs bereits seit einigen Jahren nicht mehr weiterentwickelt.
Darüber hinaus wird dieser Switch nicht mehr von der Firma HP angeboten, d.h. der Nachkauf von Komponenten zur Erweiterung von Switches ist nicht mehr möglich. Daher wurde bereits im Jahr 2011 damit
begonnen, diese Switches durch eine aktuelle Gerätegeneration (HP 5400) zu ersetzen. 2014 wurde diese
Ersetzung fortgesetzt und es wurden dabei weitere 19 Switches ausgetauscht.
11.7 Telefonie
Die Telefonie im LRZ umfasst einerseits den Betrieb der Voice-over-IP Anlage als auch die Mobilkommunikation und den Zugang von Rechnern mittels UMTS ins MWN. Daneben war das vergangene Jahr gekennzeichnet durch die Vorbereitung der bayernweiten Ausschreibung für Telefondienste und Planungen
um die Mobilfunkversorgung im LRZ zu verbessern.
11.7.1
VoIP-Anlage und Betrieb
Die seit dem Umzug des LRZ nach Garching installierte VoIP-Telekommunikations-Anlage auf Basis der
offenen Software Asterisk unter Linux arbeitet weiterhin zufriedenstellend.
129
Die Übertragung der Sprachdaten zwischen Telefonen im LRZ und der TK Anlage erfolgen verschlüsselt.
Ausgenommen sind aktuell noch die Telefone im Exzellenz-Cluster der TUM und die der LRZ-Telearbeiter.
Für einige Telearbeiter wurde die Verschlüsselung testweise aktiviert und funktioniert wie gewünscht. Es
ist geplant, die Übertragung der Sprachdaten für alle an der TK Anlage angeschlossenen Geräte zu aktivieren.
Im April wurde 40 Telefone für das zum Exzellenz-Cluster gehörende MIAPP angebunden.
Insgesamt wurden durch die VoIP-Telefonanlage im Jahr 2014 ca. 150.000 (ab April 2013 ca. 155.000)
Gespräche mit einer durchschnittlichen Länge von 3:20 (2013 2:24) Minuten oder insgesamt ca. 505.000
(2014 hochgerechnet 495.000) Gesprächsminuten vermittelt.
Dies entspricht einer Gesprächsvolumenzunahme von ca. 10.000 Gesprächsminuten im Vergleich zum
Jahr 2013, wobei die durchschnittliche Dauer der Gespräche erheblich gestiegen ist.
Es konnten ca. 351 (2013 ca. 342) Gesprächsminuten direkt über SIP zu externen Teilnehmern abgewickelt
werden. Der Wert hat sich im Vergleich zum Vorjahreswert etwas reduziert. Zu den über SIP erreichbaren
Zielen gehören die Universitäten Eichstätt, Würzburg, Ulm und Wien.
Weitere Informationen zur VoIP-Telefonanlage, wie z.B. Aufbau und Vermittlungsstatistik, können den Jahresberichten ab 2006 entnommen werden.
11.7.2
Zugang über UMTS
Der UMTS-Zugangspunkt wird weiterhin vom LRZ übernommen, wodurch die Nutzer der Verträge aus
BayKOM weiterhin den Weg ins Internet mit MWN-IP-Adressen nutzen können. Der Zugang ist auch mit
LTE möglich.
11.7.3
Verbesserung der Mobilfunkversorgung in den
LRZ-Gebäuden
Um die Erreichbarkeit von Personen in den Gebäuden des LRZ insbesondere im Rechnergebäude zu erhöhen sollte eine Versorgung des Bereiches mit GSM geprüft und umgesetzt werden.
Aus diesem Grund wurde im Keller des Bestandsgebäudes des Rechnerwürfels prototypisch eine FemtoZelle von Vodafone installiert. Eine Ausweitung der GSM Versorgung auf diesem Weg ist allerdings nicht
möglich, da auf Grund der festgelegten Frequenzen nur max. 4 Femto-Zellen betrieben werden können.
Nach der Prüfung wurde beschlossen, eine Umsetzung für die drei großen Mobilfunkanbieter umzusetzen.
Die Umsetzung muss im Rahmen einer Baumaßnahme ausgeführt werden, die hoffentlich bis Ende 2015
abgeschlossen ist.
11.7.4
Ausschreibung BayKOM
Der Freistaat Bayern wird seine Kommunikationsdienste im Rahmen von BayKOM 2017 neu ausschreiben.
Dazu wurden 2014 verschiedene ressortübergreifende Fachgruppen gebildet, um die entsprechenden
Leistungsverzeichnisse zu erarbeiten. Das LRZ wurde gebeten, stellvertretend für das Wissenschaftsministerium, bzw. die bayerischen Universitäten und Hochschulen an der Fachgruppe Telefonie (Festnetz
und Mobilfunk) mitzuarbeiten.
11.8 Unterstützung von Infrastrukturdiensten
Um Netzdienste anbieten zu können, bedarf es einer Menge von Infrastrukturdiensten, mit denen der Nutzer nur selten direkt in Kontakt kommt. In diesem Abschnitt werden diese Basisdienste wie Server Load
Balancer, IPv6, Wellenlängen- und IP-Multiplexsysteme sowie NESSI vorgestellt.
11.8.1 Server Load Balancer (SLB)
Die Dienste am SLB erfreuen sich weiterhin großer Beliebtheit. Das Wachstum der letzten Jahre hat etwas
nachgelassen, die Anzahl der verarbeiteten Verbindungen blieb gleich (ca. 60.000).
In der Tabelle ist die Anzahl der konfigurierten Server angegeben, die Anzahl der aktiven Server ist deutlich
kleiner. Bei den Pools handelt es sich um Zusammenfassungen von Rechnern zu einer Gruppe. Da die
Rechner auf verschiedenen Ports mehrere Dienste anbieten können, weicht diese Zahl deutlich von der
Anzahl der konfigurierten Nodes (insgesamt 179 (Vorjahr: 149)) ab.
130
Tabelle 23: Nutzung der Server Load Balancer (SLB)
2011
2012
2013
2014
Virtuelle Server
280
212
240
244
Gruppen (Pools)
177
182
175
147
Pool Members
492
292
365
384
Durch den Abbau von Testsystemen ist die Anzahl der Pools gesunken. Die Anzahl der Anfragen intern
und extern ist jedoch deutlich gestiegen. So wurden u.a. umfangreiche Tests mit dem PowerFolder-Dienst
durchgeführt, ebenso umfangreiche Konfigurationen für die BSB. Insgesamt wurden 6 neue Serverangebote für externe Kunden eingerichtet und 2 Serverangebote abgebaut. Die Dienstgüteanforderungen vieler
Dienste steigen und damit auch die Notwendigkeit für Loadbalancing-Dienste.
Abbildung 72: Durchsatz innerhalb von 7 Tagen am SLB 1
Im Jahr 2014 ergaben sich keine nennenswerten Betriebsunterbrechungen (<5 min), jedoch mussten einige sicherheitsrelevante Fehler behoben werden. Dies bedingte auch eine Notfall-Wartung mit SoftwareUpdate. Dabei wurden u.a. die verwendbaren SSL-Ciphers angepasst.
Es wurden Vorbereitungen getroffen, um die Software auf das nächste Major-Release (Version 11) zu
aktualisieren. Da sich gundlegende Schnittstellen ändern, ist dies ein sehr aufwändiger Prozess und bedarf
umfangreicher Vorarbeiten und einer sehr genauen Planung. Deshalb wurde auch ein Testsystem aufgesetzt, um künftige Updates sowie Weiterentwicklungen von Anwendungen besser planen, testen und umsetzen zu können.
11.8.2
IPv6
Im Jahr 2014 verlief der Betrieb von IPv6 im MWN unauffällig. Die Endsystemanzahl mit nativem IPv6
(kumulativ über eine Woche) erhöhte sich durch organisches Wachstum erneut deutlich von 59.000 auf
90.600.
131
Tabelle 24: Anzahl der IPv6-Endgeräte 2010 - 2014
Anzahl der IPv6-Endgeräte
(aus Nyx-Datenbank)
2010
2011
2012
2013
2014
4.800
16.500
25.100
59.000
90.600
Die geplante Ausstattung der Managementnetze mit IPv6 wurde begonnen. Erste Experimente zum Einsatz
von IPv6 in einem MPLS Layer3-VPN für die Max-Planck-Gesellschaft wurden erfolgreich durchgeführt und
die Generalverwaltung angebunden.
11.8.3 Wellenlängenmultiplexer
Das LRZ setzt seit 1997 Wellenlängenmultiplexer (Wavelength-Division-Multiplexer, WDM) auf den angemieteten Glasfaserleitungen der lokalen Provider (Telekom und M-net) ein. Hierdurch lassen sich auf Leitungsebene getrennte Strukturen aufbauen. WDM-Systeme werden derzeit im MWN dazu verwendet, um
die verfügbaren Glasfaserleitungen parallel zum Produktionsnetz für folgende Dienste zu nutzen:
•
•
Kopplung von Nebenstellenanlagen (TK-Kopplung)
Realisierung von standortübergreifenden Intranets (z.B. Max-Planck-Gesellchaft, Universitätsverwaltung)
• Realisierung von Testnetzen parallel (ATM-Pilotprojekte, Fiber-Channel-Kopplung von Speichernetzen
usw.)
Im MWN werden vom LRZ aktuell auf vier Verbindungen WDM-Systeme eingesetzt (s. Tabelle 25).
Tabelle 25: WDM-Verbindungen
Verbindung
TU-Nordgelände
LMU-Stammgelände
–
TU-Nordgelände
Garching
–
TU-Nordgelände
Großhadern
–
LMU-Stammgelände
Martiusstraße 4
–
WDM-Typ
Zweck
MRV LambdaDriver 800
Verbindung der Backbone-Router (1 x 10 Gbit/s)
ATM-Testnetz Erlangen -- IRT (1 x 2,4 Gbit/s
(OC48))
Intranet der Max-Planck-Gesellschaft (1 x 10 Gbit/s)
Intranet der Max-Planck-Gesellschaft (1 x 10 Gbit/s)
Pan Dacom T-3009-LC
(passiver WDM)
Anbindung des Gebäudes Martiusstr. 4 ans 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)
Die Hochschule München setzt darüber hinaus noch auf einigen internen Verbindungen WDMs zur Kopplung von TK-Anlagen ein. Die Telefonanlagen sowie deren abgesetzten Telefonanlagenteile der Technischen Universität und der Ludwig-Maximilians-Universität werden zum größten Teil mittels IP, d.h. über
das Standardprotokoll im MWN, miteinander gekoppelt.
Im Jahr 2014 wurde geplant, die Intranet-Kopplung zwischen den Max-Planck-Instituten in Martinsried und
dem Rechenzentrum der Max-Planck-Gesellschaft in Garching quantitativ und qualitativ zu erweitern. So
sollte die Übertragungsgeschwindigkeit zwischen diesen Standorten von 10 Gbit/s auf 100 Gbit/s erhöht
132
werden. Außerdem sollte eine redundante Verbindung zwischen Martinsried und Garching geschaffen werden (vgl. Abschnitt 11.1.2). Da die bisher eingesetzten WDMs hierfür nicht geeignet sind, müssen diese
ersetzt werden. Für die Redundanz der Intranet-Kopplung müssen außerdem zusätzliche WDMs installiert
werden. Mit dem Einsatz einer neuen WDM-Generation ist es dann auch möglich, die Backbone-Router
des MWN mit höheren Geschwindigkeiten untereinander zu verbinden (entweder n x 10 Gbit/s oder 1 x
100 Gbit/s). Für die Beschaffung der neuen WDM-Komponenten wurde in der zweiten Jahreshälfte von der
Max-Planck-Gesellschaft eine Ausschreibung durchgeführt. Die Entscheidung fiel dabei auf Geräte des
Herstellers ADVA (FSP 3000). Bis Ende 2014 wurden die Geräte bereits größtenteils geliefert. Die Installation und Inbetriebnahme der neuen WDM-Generation soll bis Ende März 2015 abgeschlossen werden.
Abbildung 73: Struktur des Querverbindungsnetzes
Den zentralen Mittelpunkt des Querverbindungsnetzes bildet die Telefonanlage in der Obersten Baubehörde. Dort gibt es neben den Verbindungen zu den Hochschulen auch noch eine ganze Reihe weiterer
Kopplungen zu Telefonanlagen staatlicher Einrichtungen, wie z.B. Ministerien, Finanz- und Polizeibehörden, Theater usw. Auch diese Verbindungen erfolgen nicht über das öffentliche Telefonnetz, sondern über
eigene Leitungen.
11.8.4
NeSSI
Das „Portal für Netzverantwortliche“ NeSSI (Network Self Service Interface) erlaubt den Netzverantwortlichen, Informationen aus ihrem Netzbereich abzufragen (z.B. Mac-Adressen, per DHCP vergebene Adressen).
2014 wurde NeSSI neu konzipiert und dann neu programmiert. Ziel war es dabei, die Funktionalitäten in
separate Module aufzuteilen, um eine größere Flexibiltät im Hinblick auf zukünftige Funktionen zu erreichen.
Als erste derartige neue NeSSI-Funktion, die den bisherigen Funktionsumfang erweitert, steht den Netzverantwortlichen jetzt die Möglichkeit zur Verfügung, IP-Adressen, die aufgrund erkannter, sicherheits-relevanter Auffälligkeiten durch Mitarbeiter des LRZ Abuse-Response-Teams (AR-Team) gesperrt wurden,
wieder freizuschalten. Notwendig hierzu ist lediglich eine kurze Beschreibung der durchgeführten Maßnahmen. Dies wird zum einen die Mitarbeiter des LRZ AR-Teams von derartigen Routinetätigkeiten entlasten
und zum anderen eine schnellere Wiederinbetriebnahme eines nach einem Malware-Befall erfolgreich bereinigten oder beispielsweise neu installierten IT-Systems ermöglichen.
Neben der Funktionserweiterung und einer besser strukturierten, modular aufgebauten Implementierung
galt es auch, Sicherheits- und Datenschutzaspekte zu berücksichtigen. Bei allen innerhalb des NeSSIPortals angebotenen Funktionen musste gewährleistet werden, dass Netzverantwortliche nur die Daten
133
einsehen oder etwa IP-Adressen freischalten können, die ihrem Zuständigkeitsbereich zugeordnet sind.
Der nun modulare Aufbau erleichtert die Anbindung weiterer Datenquellen und insbesondere auch die
schrittweise weitere Ergänzung des Funktionsumfangs. So könnte beispielsweise die Verwaltung von Ausnahmelisten für das LRZ Security-Monitoring oder ein Schwachstellen-Scanner-Modul, den Funktionsumfang des Netzverantwortlichen-Self-Services weiter ergänzen.
11.9 Netzmanagement und –monitoring
Zur Verwaltung und zum Betrieb des Münchner Wissenschaftsnetzes und seiner Subnetze setzt das LRZ
eine Reihe von Standard-Softwaresystemen und komplementäre Eigenentwicklungen ein. In den folgenden Abschnitten wird auf die Werkzeuge zum Netzmanagement, die LRZ-Netzdokumentation und das
mandantenfähige Netz-Performancemanagement eingegangen.
11.9.1 Netzmanagement
Das Netzmanagement bildet die Basis für die Qualität der Netzdienstleistungen des LRZ im MWN. Wesentliche Komponenten des Netzmanagements sind das Konfigurations-, das Fehler- und das Performance-Management. Die Aufgaben des Konfigurations- und Fehler-Managements werden im MWN durch
den Netzmanagement-Server erfüllt. Die Aufgaben des Performance-Managements werden im ServiceLevel-Management-Werkzeug InfoVista umgesetzt (siehe Abschnitt 11.9.5).
11.9.1.1 Netzmanagement-Software und Netzmanagement-Server
Im Jahr 2008 wurde der IBM Tivoli Network Manager IP (ITNM) als neue Netzmanagement-Software ausgewählt. Der Auswahlprozess und die Gründe für die Wahl von ITNM sind im Jahresbericht 2008 zusammengefasst. Die Produktivführung des IBM Tivoli Network Manager wurde 2010 durchgeführt. Seitdem
übernimmt ITNM die Überwachung des MWN und wird laufend an Änderungen im MWN angepasst.
Die Layer-2-Topologie-Discovery des Netzmanagementsystem IBM Tivoli Network Manager IP (ITNM)
wurde im Jahr 2014 weitgehend (sofern von den Komponenten unterstützt) auf das Link Layer Discovery
Protocol (LLDP) umgestellt und die Auswertung des Cisco Discovery Protocol (CDP) in ITNM deaktiviert.
Für diese Umstellung musste erst ein Fehler des LLDP-Abfrage-Agenten durch den IBM-Support behoben
werden. Der LLDP-Agent lieferte bei mehreren an einem Port angeschlossenen Geräten (dieser Fall tritt
bei der Verwendung von nicht-SNMP-fähigen Switchen auf) immer nur ein Ergebnis zurück. Das führte bei
der Verwendung von LLDP zu einer teilweise unvollständigen Topologie. Desweiteren musste der Algorithmus zur Topologie-Erstellung bei LLDP noch an einige Besonderheiten der im MWN eingesetzten Komponenten angepasst werden. Diese Anpassung wurde ohne den IBM-Support nur LRZ-intern durchgeführt.
Das "Out of Memory"-Problem bei der Discovery, das schon in den Jahren 2011 - 2013 wegen zu vielen
MAC-Adressen in den Forwarding-Tabellen der Switches aufgetreten ist, hat sich 2014 weiter verschärft.
Deswegen wurde ein Workaround für dieses Problem entwickelt. In der In-Memory-Datenbank des Discovery Prozesses wird nach der ersten Phase der Topologie-Erstellung der Teil der Daten gelöscht, der
nicht mehr benötigt wird. Dadurch wird genügend Hauptspeicher frei, um die zweite Phase der TopologieErstellung problemlos in der 4 GB großen Hauptspeichergrenze des Discovery-Prozesses durchzuführen.
In der folgenden Abbildung ist die Topologie des gesamten MWN (ca. 4.010 Netzkomponenten) am Ende
des Jahres 2014 zu sehen.
134
Abbildung 74: Topologie des Münchner Wissenschaftsnetzes Ende 2014
Die wichtigsten darüber hinaus 2014 an ITNM durchgeführten Arbeiten sind:
•
Mehrere Fixpacks und Security-Patches wurden eingespielt. Insbesondere vor dem Einspielen von
Fixpacks und Patches werden auch immer Komplett-Backups der ITNM Installation erstellt.
• Eine Lösung für die fehlerhafte Discovery von IPv6-Adressen (siehe Jahresbericht 2013) wurde
mit Hilfe des IBM-Supports entwickelt und implementiert.
• Eine Web-Seite mit dem Status der WLAN-Accesspoints im MWN wurde entwickelt und umgesetzt.
• Regeln für die Alarmverarbeitung der neuen HP 5900 Switches, der NetApp Switches und der
Broadcom Switches wurden entwickelt und implementiert.
• Das SSLv3-Protokoll wurde wegen eines bekannten Sicherheitsproblems in der Web-Schnittstelle
von ITNM deaktiviert.
• Die Performance des Discovery-Prozesses wurde bzgl. des Zeitverbrauchs verbessert. Dazu wurden verschiedene Einstellungen bzgl. der Thread-Zahlen der Abfrage-Agenten getestet. Generell
brachte in den meisten Fällen eher eine niedrigere Thread-Zahl Zeit-Vorteile als eine höhere. Damit
konnte die Zeit vom Start bis zum Ende der Topologie-Erstellung von ca. 3 Stunden auf ca. 2
Stunden verkürzt werden.
• Verschiedene Fehler in den SNMP-MIBs der Geräte machen es immer wieder nötig, die von ITNM
nicht vollständig richtig erkannte Layer-2-Netz-Topologie des MWN durch manuelle Eingriffe zu
korrigieren oder zu ergänzen.
Ende 2014 wurden vom IBM Tivoli Network Manager ca. 4.010 (im Vorjahr 3.830) Netzkomponenten und
Server (mit netzrelevanten Diensten) überwacht. Das ist eine Steigerung von ca. 180 Geräten gegenüber
2013.
Der Netzmanagement-Server, auf dem der IBM Tivoli Network Manager installiert ist, hat außerdem noch
folgende Funktionen:
•
Arbeitsserver für die Geräteadministratoren
•
•
•
135
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
11.9.1.2 WWW-Server zum Netzmanagement
Auf einem separaten Webserver sind seit 2002 aktuelle Informationen über die Topologie für die Nutzer
des Münchner Wissenschaftsnetzes und die Performance des MWN-Backbone abrufbar. Unter
http://wwwmwn.lrz.de werden Performance-Daten zu den wichtigsten Elementen des MWN (Backbone, XWiN Anbindung, IPv6 Verkehr, Secomat, Demilitarisierte Zone (DMZ) des LRZ, Modem- und ISDN-Zugang,
usw.) dargestellt. Die Performance-Daten werden dazu jeweils in Form von MRTG-Statistiken oder InfoVista-Reports 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. 2014 waren auch hier einige Anpassungen
bzgl. Interface-Änderungen notwendig.
11.9.2 Netzdokumentation
In der LRZ-Netzdokumentation werden für den Betrieb des MWN relevante Informationen (Netzkomponenten, Subnetze, Ansprechpartner, Räume, ...) gespeichert. Die Netzdokumentation basiert auf einer relationalen Datenbank, auf die über ein Web-Interface zugegriffen werden kann.
Im LRZ wurde 2013 beschlossen, den Betrieb der Oracle-Datenbank, in der auch die Sollzustandsdaten
der Netzdokumentation gespeichert sind, mittelfristig einzustellen. Deshalb musste Oracle als relationale
Datenbank für die Netzdokumentation ersetzt werden. Als zukünftige relationale Datenbank für die Netzdokumentation wurde PostgreSQL gewählt (siehe auch Jahresbericht 2013). Die Migration des Anwendungscodes von Oracle nach PostgreSQL wurde 2013 begonnen und im April 2014 nach ausführlichen
Tests des neuen Anwendungscodes durch die Umstellung der Netzdokumentation auf PostgreSQL beendet. Mit der Migration zu PostgreSQL als Datenbank wurde auch gleichzeitig eine Migration des verwendeten Zeichensatzes von ISO-8859-15 zu UTF-8 durchgeführt. Dadurch erfolgte eine Angleichung an die
Standard-Einstellung bei Linux-Servern, was dazu dient, bisher bestehende Probleme bei der Zeichensatzumwandlung zukünftig zu vermeiden.
Außerdem wurden 2014 folgende Erweiterungen und Verbesserungen durchgeführt:
•
•
•
•
•
•
•
Das neue LRZ Logo wurde für die Netzdokumentation übernommen und das Aussehen der Webseiten wurde an das neue Logo angepasst.
Die veraltete und von mehreren Nutzern nutzbare Benutzerkennung nduser wurde endgültig deaktiviert. Künftig ist nur noch eine Benutzer-individuelle Anmeldung möglich.
In allen Bemerkungs- und Beschreibungsfeldern kann mit regulären Ausdrücken gesucht werden.
Bei Subnetzbereichen kann nach den Reservierungsterminen gesucht werden.
Alle IPv4-Subnetze können in mehrere Subnetzbereiche unterteilt werden. Bisher war das nur für
/24 oder kleinere Netze möglich.
Die Netzdokumentation wurde um die Unterstützung der neuen HP 5900 Switches erweitert (Abfrage der VLAN-Daten von diesen Switchen, Integration des neuen Namens-Schemas der SwitchPorts, ...).
Bei den Subnetzbereichen wurde ein neues Feld (IPAM-Gruppen) eingeführt, um die zukünftige
IP-Adressvergabe durch das Tool Nixu Namesurfer zu unterstützen.
11.9.3 MWN-WLAN-Visualisierung mit OpenStreetMap für Endbenutzer
2013 wurde bereits die MWN-Visualisierung mit OpenStreetMap für Endbenutzer in die Netzdokumentation
integriert (siehe Jahresbericht 2013). 2014 wurden in diese Karte auch die Standorte eingetragen, an denen
die Stadtwerke München (SWM) die SSID Eduroam ausstrahlen (s. Abbildung 75). Diese Karte mit allen
MWN- und SWM-WLAN-Standorten für Endbenutzer ist weiter unter der URL http://www.lrz.de/services/netz/mobil/mobil_ap/map zugänglich. Basierend auf dieser Integration wurden die Eduroam-WLANStandorte auch in die Eduroam-Karte des DFN-Vereins (http://airoserv4.dfn.de) und damit in die globale
Eduroam-Karte (http://monitor.eduroam.org/eduroam_map.php?type=all) exportiert.
136
Abbildung 75: Eduroam-WLAN-Standorte der Stadtwerke München
11.9.4 Inhaltliche Aktualisierung der Netzdokumentation
Um die Aktualität der Informationen zu den Netzverantwortlichen zu sichern, wurde 2014 wieder eine Benachrichtigung und Überprüfung der Kontaktinformationen durchgeführt. Jeder der 894 Netzverantwortlichen 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. In der E-Mail wurde auch auf das NeSSI-Interface für Netzverantwortliche
hingewiesen. An die 242 Netzverantwortlichen, die auch nach zwei Monaten noch nicht geantwortet hatten,
wurde per Skript automatisiert eine E-Mail zur Erinnerung geschickt.
Bei 232 Einträgen zu Netzverantwortlichen waren kleinere oder größere Änderungen während der Aktualisierung notwendig. Bei allen anderen Netzverantwortlichen blieben die Einträge unverändert. Neben dieser
jährlichen Aktualisierung werden aktuelle Änderungen im MWN laufend in die Netzdokumentation übernommen.
11.9.5 Überwachung der Dienstqualität
Das Service-Level-Management-Werkzeug InfoVista dient dazu, die Qualität von IT-Diensten zu überwachen und in Form von graphischen Reports darzustellen. Es wird seit dem Jahr 2000 zur Überwachung der
Dienstqualität im Münchner Wissenschaftsnetz (MWN) eingesetzt. Das InfoVista-System wird ständig an
die Entwicklungen im MWN angepasst bzw. Veränderungen im Netz werden in InfoVista übernommen.
Im Jahr 2014 wurde ein neuer Switch-Device-Report erstellt, der statt der Interface-Beschreibung den Interface-Alias bei den Interface-Verkehrszahlen anzeigt (s. Abbildung 76). Der Interface-Alias eines SwitchPorts muss manuell vom Administrator eingetragen werden, was bisher meistens nicht durchgeführt wurde.
Erst bei den neuen HP 5900 Switches, die im VMware-Cluster und im Cloud-Bereich eingesetzt werden,
wird der Interface-Alias durchgehend gesetzt. Damit ist dann eine einfache Zuordnung eines Switch-Ports
zu einem Dienst bzw. einer Dienst-Komponente möglich.
137
Abbildung 76: Device-Report mit Interface-Alias
Um die Aktualität der in InfoVista bereitgestellten Daten sicherzustellen, wurden alle konfigurierten Instanzen und Reports für Switches überprüft und falls notwendig korrigiert bzw. durch neue Switch-Instanzen
und -Reports ersetzt.
11.9.6 Reporting für Netzverantwortliche
Die Institute im MWN haben mit den Switch-Reports für Netzverantwortliche über die WWW-Schnittstelle
VistaPortal (https://vistaportal.lrz.de) zu InfoVista eine Übersicht über das Gerät und auch über die PortAuslastung der Switche, an denen sie angeschlossen sind. Durch die Reports wird die Diensterbringung
des LRZ transparenter, außerdem kann die Fehlersuche im Institut dadurch erleichtert werden. Die Reports
können im HTML-, GIF-, PNG-, PDF-, Text- oder Excel-Format abgerufen werden.
Das Web-Interface VistaPortal wurde bereits im Jahr 2013 auf die Version 4.2 aktualisiert. Dazu mussten
alle bestehenden VistaPortal-Anwender von der Umstellung informiert und nach deren LRZ-Kennung gefragt werden. Alle Anwender, die auf diese E-Mail-Umfrage eine Rückmeldung geliefert haben, wurden
auch im neuen VistaPortal freigeschaltet. Die Konfiguration für die Anwender ohne Rückmeldung wurde
dann 2014 endgültig gelöscht.
Desweiteren war es in 2014 notwendig, die Java-Archive-Files von VistaPortal mit einem LRZ-EntwicklerZertifikat zu signieren. Ohne diese Signierung würde die VistaPortal-Webanwendung wegen der Verschärfung der Sicherheitsrichtlinien in Java nicht mehr mit neueren Versionen des Java-Plugins ausgeführt werden können. Von der Firma InfoVista wird diese Signierung der Java-Archive-Files leider nicht bereitgestellt. Die Signierung der Java-Archive-File musste nach einem halben Jahr erneuert werden, weil das
entsprechende DFN-PCA-Zertifikat vom DFN wiederrufen wurde.
Zu den bereits in den Jahren 2003 – 2013 instanziierten Reports für Netzverantwortliche kamen 2014 noch
Reports für die Zentralabteilung der TUM in Weihenstephan und für das Bayerische Zentrum für Angewandte Energieforschung hinzu.
11.10
Internetzugang und LAN
Der Zugang zum weltweiten Internet wird über das Deutsche Wissenschaftsnetz (WiN) realisiert, die nutzbare Bandbreite liegt bei 23,6 Gbit/s.
138
Die monatliche Nutzung (übertragene Datenmenge) des WiN-Anschlusses seit Januar 2004 zeigt Abbildung 77. Die Datenmenge pro Monat liegt während der Vorlesungzeiten deutlich über einem Petabyte.
Allerdings zeigen sich im Jahr 2014 nicht mehr die starken Wachstumsraten wie in den Jahren davor. Dies
liegt auch daran, dass der Large Hadron Collider am Cern sich seit Ende 2013 in einer Umbauphase befindet und dort deshalb deutlich weniger Daten produziert werden. Mit dem Umbau, der bis März 2015
dauern wird, werden sich Leistung und Intensität um den Faktor 10 erhöhen. Damit wird ab 2015 die zu
verarbeitende Datenmenge wieder deutlich zunehmen.
Um diese hohen Bandbreitenanforderungen im MWN zu erfüllen, hat der DFN das MWN direkt an seinen
sogenannten Super-Core angebunden. Der Super-Core verbindet die Standorte Frankfurt, Erlangen, Berlin
und Hannover mit einem 100 Gbit/s Ring. An diesem sind weitere Kern-Router des DFN angebunden, an
denen wiederum die normalen Kunden-Router angebunden sind. Das MWN wurde mit zwei Trunks über
zwei unabbhängige Pfade einmal direkt an Erlangen und einmal direkt an Frankfurt angebunden. Die Tunks
selbst bestehen aus je zwei 10 Gbit/s-Schnittstellen, die Bandbreite ist pro Trunk auf je 11,3 Gbit/s beschränkt. Das MWN ist außerdem noch über M-net mit dem Internet verbunden. Diese Anbindung wurde
aufgrund des Bandbreitenwachstums und der höheren Bandbreite in das Wissenschaftsnetz im Berichtsjahr von 1 Gbit/s auf eine Bandbreite von 10 Gbit/s erhöht.
Damit wird ein dreistufiges Ausfallkonzept mit Backups für den Internetzugang umgesetzt (s.u).
Abbildung 77: Entwicklung der Nutzung des WiN-Anschlusses des MWN seit 2004
Seit September 2003 ist der X-WiN-Anschluss vertragstechnisch ein so genannter Clusteranschluss, bei
dem die vom MWN versorgten teilnehmenden Institutionen als eigenständige Partner mit eigenem Tarif
bezogen auf den eingehenden Datenverkehr aufgefasst werden. Zu diesem Zweck wurden die laufenden
Messungen kumuliert, um eine Verteilung des Datenverkehrs zu bekommen. Die prozentuale Verteilung
des Datenvolumens am WiN-Zugang (Messzeitraum November 2014) zeigt Tabelle 26.
139
Tabelle 26: Prozentuale Verteilung des Datenverkehrs am WiN Zugang
Institution
Anteil
LRZ und BAdW
44,3 %
IPv6 Verkehr
26,1 %
TUM
23,9 %
LMU
5,2 %
Hochschule München
0,4 %
Hochschule Weihenstephan
0,1 %
Studentenwerk, Wohnheime
13,0 %
Sonstige
1,7 %
Gesamtergebnis
100.0%
Die Statstik wird seit 2014 nicht mehr mit einem Accounting-System sondern mit QRadar (vgl. Abschnitt
5.5.2) ermittelt. Der IPv6 Verkehr (aller MWN-Nutzer) wird hierbei gesondert aufsummiert.
Die technische Realisierung der Anbindung des MWN an das Internet zeigt Abbildung 78:
Abbildung 78: Anbindung des MWN ans Internet
Der Standardzugang zum Internet ist über das vom DFN betriebene Wissenschaftsnetz (WiN) realisiert.
Der WiN-Anschluss des LRZ wie weiter oben bereits beschrieben über zwei Trunks direkt an den SuperCore des DFN. Derzeit ist ein zweistufiges Ausfallkonzept für den Internetzugang umgesetzt:
1. Falls eine Glasfaser oder eine Komponenten zwischen den MWN-Routern und dem WiN ausfallen
sollte, gibt es mindestens eine verbleibende alternative Strecke ins WiN, allerdings mit reduzierter
Bandbreite.
2. Sollten alle vier Leitungen oder aber die beiden DFN-Router gleichzeitig 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 10 Gbit/s zum
140
nächsten Anschlusspunkt von M-net geführt. Die LWL-Strecke kostet einen monatlichen Grundbetrag, das Datenvolumen wird nach Verbrauch berechnet.
Die Wahrscheinlichkeit eines derartig umfangreichen Hardware-Aussfall ist ausgesprochen gering. Trotzdem ist der M-net Backup auch weiterhin erforderlich und war in 2014 auch einige Male aktiv. In diesen
Fällen handelte es sich i.d.R. um Routing-Probleme innerhalb des IPv6 Routings im WiN. Ohne den Backup
über M-net wären in diesen Fällen ganze IPv6 Netzbereiche nicht mehr erreichbar gewesen.
Die Backup-Konzepte funktionieren für alle Systeme mit Provider-unabhängigen IP-Adressen (Standardfall
im MWN). Das LRZ-Netz kann nämlich mit einem Großteil seiner IP-Adressen als autonomes System im
Internet agieren. Einige Standorte (Krankenhaus Rechts der Isar, Hochschule München, Beschleunigerlabor, Zoologische Staaatsammlung, kath. Stiftungsfachhochschule) bzw. Systeme (Bibliotheksverbund Bayern), die aus historischen Gründen noch providerabhängige IP-Adressen (i.d.R. vom DFN vergeben) verwenden, können die Backup-Strecke über M-net nicht nutzen.
Im Jahr 2014 wurde die M-net Backup-Strecke in 3 Fällen aktiv. In der Regel handelte es sich dabei um
sehr kleine Störungen (z.B. im Routing oder bei IPv6) und der Backup war nur für wenige Minuten aktiv.
11.11
WLAN und Eduroam
Das LRZ versorgt primär öffentliche Bereiche (Seminarräume, Hörsäle, Bibliotheken, Foyers, Uni-Lounges)
mit Wireless LAN, eine Flächendeckung für Bürobereiche kann bis auf weiteres nicht realisiert werden.
Trotzdem sind Ende 2014 bereits 2.696 Accesspoints in Betrieb. Im Berichtsjahr 2014 wurden 350 Accesspoints neu installiert und 171 gegen neuere Modelle ausgetauscht, 18 nicht mehr benötigte wurden abgebaut.
Zuwachs an Access Points
350
312
300
255
250
332
281
259
210
200
140
150
160
160
171
136
89
100
50
311
14
63
37
0
2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
neu aufgebaute APs
ausgetauschte APs
Abbildung 79: Anzahl der jährlich installierten Accesspoints
Die Nutzung stieg erneut stark an, insbesondere bedingt durch die weiter zunehmende Anzahl von Smartphones und Tablets. Die im Jahr 2013 gemessene Zahl von 18.958 gleichzeitigen Verbindungen stieg 2014
auf maximal 26.390 an, insgesamt wurden dabei über 300.000 verschiedene Geräte beobachtet. Sehr
nachgefragt wurde das WLAN auch bei 635 Kongressen und Tagungen innerhalb des Jahres 2014.
141
Abbildung 80: Anzahl aktiver WLAN-Verbindungen am 5.11.2014 (5-Minuten-Mittel)
Abbildung 81: Entwicklung der Belegung über das Jahr 2014 (Tagesmittel)
Die am stärksten frequentierten Accesspoints waren mit bis zu 220 gleichzeitigen Verbindungen belegt.
Ältere hoch belastete Accesspoints wurden durch die aktuellste Geräte-Generation ersetzt, etliche Hörsäle
wurden durch die Installation zusätzlicher Accesspoints verstärkt.
Als Zugangskomponenten werden Accesspoints der Typen AP-135 von Alcatel-Lucent sowie MSM310,
MSM320, MSM422, MSM460 und MSM466 der Firma HP eingesetzt. Bei den ab 2011 eingesetzten
MSM460 und MSM466 sowie den ab 2013 eingesetzten AP-135 werden Datenraten bis zu 450 Mbit/s
(IEEE802.11n) unterstützt. Erste Accesspoints mit dem neuen Standard 802.11ac, die Datenraten von
mehr als 1 Gbit/s unterstützten, sind testweise im Einsatz.
Der Betrieb wird über zwei Controller OAW-4650-EU gesteuert, welche im Rechnergebäude des LRZ in
verschiedenen Brandabschnitten installiert sind. Sie sind im sog. Master / Master-Standby-Setup konfiguriert d.h. ein Gerät ist aktiv, das zweite übernimmt nur bei Ausfall des Master-Controllers. Im Jahr 2014
wurden zwei weitere Controller beschafft und „näher“ bei den zu verwaltenden Access Points positioniert.
Ein Controller wird am Campus Garching, der andere am Stammgelände der TU betrieben. Diese beiden
sind künftig für die Verwaltung der Access Points zuständig. Die beiden Controller im LRZ werden als
ausfallsicheres Cluster betrieben, sie verwalten die Lizenzen und die Sub-Controller. Bei einem Ausfall
eines Controllers kann das Cluster im LRZ transparent den Betrieb der APs übernehmen.
Wegen der Mischung von Alcatel-Lucent und HP-Accesspoints wird an den meisten Standorten der sogenannte Bridge-Modus verwendet. Nur in Neubauten laufen die Accesspoints im Tunnel-Modus, wobei die
142
Daten über den Controller geroutet werden und auch alle Vorteile, die der Controller bietet (z.B. Load Balancing, Load Sharing, usw.), genutzt werden können.
Im Laufe des Jahres 2014 wurden folgende Bereiche neu mit WLAN ausgestattet:
Studentenwohnheim der Ingeborg-von-Calker-Stiftung
Mensa Martinsried
TUM Protein Modelling
TUM Klinikum rechts der Isar Hörsaalgebäude
TUM Exzellenzcluster MIAPP
TUM Katalysezentrum
TUM Zentrum für Softskills
LMU Veterinärstr. 13
LMU Königinstr. 8
LMU Königinstr. 14
LMU Königinstr. 16
Hochschule Weihenstephan-Triesdorf, Kleine Kustermannhalle
Hochschule für Politik, Ludwigstr. 8
Historisches Kolleg
LMU Kaulbachstr. 45
Studentenwohnheim Haidpark
Studentenwohnheim Türkenstraße
11.11.1
Eduroam
Das LRZ nimmt seit Anfang 2005 am Eduroam (früher DFN-Roaming) teil. Damit ist es Wissenschaftlern
möglich, mittels einer vorhandenen Kennung ihrer Heimat-Hochschule einen einfachen Zugang ins Internet
zu erhalten, wenn sie sich im Bereich des MWN aufhalten. Als Zugangspunkte dienen die vorhandenen
WLAN-Accesspoints.
Die SSID eduroam wird auf allen Accesspoints im MWN zur Verfügung gestellt. Neben der SSID eduroam
wird zusätzlich eduroam-a angeboten, welche die Verbindungen auf das 5GHz-Frequenzband einschränkt.
Dadurch lassen sich Probleme mit manchen Linux-Clients verhindern, welche bei Verfügbarkeit von zwei
Frequenzbändern ständig zwischen diesen wechseln und dadurch keine stabile Verbindung erlauben. Außerdem ist noch die SSID eduroam-ipv6 konfiguriert, welche Verbindungen nur über IPv6 erlaubt.
Abbildung 82 zeigt die Jahresnutzungsstatistik in Abhängigkeit der genutzten SSID. Die roten Bereiche
zeigen die Nutzerzahlen von eduroam. Mittlerweile nutzt der größte Teil der Anwender diese SSID und hier
zeigt sich auch das größte Wachstum bei den Nutzerzahlen.
Eduroam erfreut sich so großer Beliebtheit, weil diese Technik nach einmaliger Konfiguration an allen teilnehmenden Einrichtungen genutzt werden kann. Dies zeigt auch die in Abbildung 83 dargestellte Nutzungsstatisitk aus dem Wintersemester 2014, in der die Anzahl der im eduroam angemeldeten Geräte
pro Woche dargestellt wird. Während des Semesters waren pro Woche mehr als 50.000 Geräte im eduroam aktiv. Gleichzeitig verwendeten bis zu knapp 17.000 Nutzer aus dem WMN das eduroam in anderen besuchten Einrichtungen. Die Anzahl der Besucher im MWN lag in der Spitze ebenfalls bei knapp
17.000. Die Besucher kamen aus über 40 unterschiedlichen Top-Level Domains. Addiert man die MWNNutzer, die eduroam im MWN und außerhalb nutzen, so ergibt sich eine Geräteanzahl von mehr als
70.000.
143
Abbildung 82: Nutzung des WLAN aufgeteilt nach SSIDs
Abbildung 83: Eduroam Nutzung durch MWN-Nutzer und Gäste
11.11.2
Vorkonfigurierte Profile für eduroam (CAT)
Über die Kollaborationsplattform eduroam CAT (https://cat.eduroam.org/) wurden Profile für die einfache
und sichere Eduroam-Einrichtung im MWN erzeugt. Sie werden den Nutzern über eine Webseite zum
Download angeboten. Mittels der Profile wird automatisch das nötige Wurzel-Zertifikat Deutsche Telekom
Root CA 2 installiert und eine korrekte Eduroam-Konfiguration inklusive der Prüfung des Radius-Servers
angelegt. Der Nutzer muss lediglich seine Kennung und sein Passwort angeben, alles weitere für eine
sichere Eduroam-Verbindung übernimmt das CAT-Tool.
144
Für die folgenden Systeme sind CAT-Profile verfügbar:
Windows 7
Windows 8
Windows Vista
Linux
IOS (IPhone und iPad)
MAC OS X
Für Android wird bisher keine Profilerzeugung möglich, dies soll aber Anfang 2015 möglich werden.
11.11.3
Eduroam off Campus
Im Rahmen des ZKI gibt es seit 2011 eine Kommission „eduroam off campus (EoC)“ in der das LRZ mitarbeitet. Das Ziel dieser Kommission ist es, die Beschränkung von eduroam auf Campus-Bereiche aufzuheben, eduroam auch in anderen Bereichen anzubieten und damit Studenten und Wissenschaftlern den Zugang mit der Kennung ihrer Heimatuniversität möglich zu machen.
Die Stadt München betreibt seit 2013 in Kooperation mit den Stadtwerken München ein offenes City-WLAN
(M-WLAN). Anfang 2014 wurde in einer engen Kooperation zwischen den Stadtwerken, dem LRZ und dem
DFN Verein eduroam auf den städtischen Access Points freigeschaltet und in Betrieb genommen
(http://www.swm.de/dms/swm/pressemitteilungen/2014/04/allgemein20140417/Pressemitteilung%20vom%2017.04.2014.pdf). Damit möchte die Stadt München die Studierenden und Wissenschaftler
unterstützen und die Campus-Bereiche der Universitäten und Hochschulen in die Innenstadt hinein ausdehnen. Gestartet wurde mit den Access Points am Marienplatz, dem Odeonsplatz, dem Sendlinger Tor
sowie dem Stachus. Mitte des Jahres wurden über diese Access Points bereits mehr als 50.000 eduroam
Nutzer in zwei Monaten registriert.
Abbildung 84: Dr. Dietmar Unger, Leiter IT bei den SWM und
Prof. Dr. Helmut Reiser, LRZ, nehmen das eduroam im M-WLAN in Betrieb
145
Ende des Jahres 2014 wurden neben den vier Standorten weitere neun in Betrieb genommen:
•
•
•
•
•
•
•
•
•
Giesinger Bahnhof
Harras
Lehel
Marienhof
Münchner Freiheit
Neuperlach Zentrum (PEP)
Orleansplatz
Rotkreuzplatz
Wettersteinplatz
Die Standorte der Access Points der SWM wurden mit in die Übersichtskarte der Access Points im MWN
(s. Abbildung 75) aufgenommen und mit einem eigenen Symbol versehen.
11.11.4
Gastkennungen
Für Gäste, die nur kurze Zeit an den Institutionen im MWN verbringen, wurde 2013 die Möglichkeit der
Vergabe von Gastkennungen eingerichtet. Diese können von den Master Usern an den Instituten über das
gewohnte ID-Portal für die Dauer von einem bis sieben Tagen eingetragen werden. Mit einer Gastkennung
kann das WLAN im MWN über die SSID eduroam genutzt werden. 2014 wurden insgesamt von 116 Master
Usern 2.133 Kennungen für Gäste eingerichtet.
11.11.5
Unterstützung von Veranstaltungen
Immer mehr nachgefragt wird die WLAN-Unterstützung für externe Teilnehmer bei Konferenzen und Tagungen, innerhalb des Jahres 2014 waren es 635 Veranstaltungen (+287 gegenüber 2013).
Bisher wurde auf den Access Points im Veranstaltungsbereich und auf die Dauer der Veranstaltung beschränkt eine SSID con freigeschaltet, über welche unverschlüsselte WLAN-Verbindungen ins Internet
ermöglicht wurden. Diese Lösung ist aber aus Gründen der Sicherheit und wegen des hohen Einrichtungsaufwands unbefriedigend. Deshalb wurde 2014 ein neues Konzept erarbeitet und ein neues Verfahren
prototypisch eingeführt.
Beim neuen Verfahren können die Verantwortlichen Veranstaltungen über ein Webportal
(https://wlan.lrz.de/conferences/new/) anmelden. Nach der Prüfung auf Kostenpflichtigkeit (bei kommerziellen Veranstaltungen) und erfolgter Genehmigung wird eine Login-Kennung generiert, welche für die
Dauer der Veranstaltung gültig ist. Mit dieser Kennung können alle Teilnehmer über die SSID mwn-events
mit WPA2 gesicherte Verbindungen in das Internet herstellen. Für die wichtigsten Plattformen stehen zur
einfachen und sicheren Einrichtung der Rechnerkonfiguration Profile zum Download bereit. Das neue Verfahren wurde im Rahmen der Testphase bereits 120 Mal erfolgreich eingesetzt, ab 2015 wird die Freischaltung über con nicht mehr angeboten.
Nur in Ausnahmefällen werden auch feste Netzanschlussdosen (100 Mbit/s oder 1 Gbit/s, TP oder LWL)
zur Verfügung gestellt. Für Geräte, die keine eingebaute Funkschnittstelle haben, werden vom LRZ Wireless-Client-Bridges (WCB) bereitgestellt. Die Realisierbarkeit des Dienstes hängt aber von der vorhandenen Infrastruktur ab, nicht in allen Gebäuden und Räumen sind die Voraussetzungen erfüllt. Allerdings ist
dies meistens der Fall.
11.12
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.
146
11.12.1
Technik
Die VPN-Hardware besteht aus zwei Appliances vom Typ „Adaptive Security Appliance ASA5585-X“, vier
Appliances vom Typ „Adaptive Security Appliance ASA5540“ und einer Appliance vom Typ „VPN-Concentrator 3030“ der Firma Cisco. Der VPN-Concentrator 3030 dient für die Anbindung von einigen externen
Einrichtungen außerhalb des MWN über IPsec LAN-to-LAN Tunnel. Vier der sechs ASA-Appliances sind
zu einem VPN-Cluster zusammengefasst, zwei werden für Tests und für Beta-Software verwendet. Dieser
VPN-Cluster wird von IPsec-Clients unter der Adresse ipsec.lrz.de, von SSL-VPN-Clients unter der Adresse asa-cluster.lrz.de angesprochen. Die Nutzer werden beim Anmelden mit der am geringsten ausgelasteten Appliance verbunden. Der VPN-Concentrator 3030 ist über zwei 100 MBit/s Anschlüsse (öffentlich
und privat) angeschlossen. Die zwei ASA5585X sind mit jeweils 10 GBits/s angeschlossen, die vier
ASA5540 mit jeweils 1GBit/s. Die verfügbare Bandbreite für verschlüsselte Verbindungen (AES/3DES) beträgt 50 MBit/s beim VPN-Concentrator 3030 350 MBit/s pro ASA5540 und 1 GBit/s bei den ASA5585-X.
Authentifizierung, Autorisierung der Nutzer sowie Accounting werden über das Radius-Protokoll abgehandelt.
11.12.2
VPN-Software
Berechtigte Nutzer können die aktuellen Versionen der VPN-Software vom Web- oder VPN-Server des
LRZ herunterladen. Für Linux und Mac OS X stehen neben den Cisco-IPsec und AnyConnect-Client der
„Open Source“ VPN-Client vpnc (IPsec) und openconnect (SSL-VPN) zur Verfügung, der erfahrenen Nutzern erweiterte Möglichkeiten bietet. Diese Clients sind inzwischen in den Linux-Standarddistributionen wie
z.B. Debian, SuSE und Ubuntu enthalten.
11.12.3
Telearbeitsplätze von LRZ-Mitarbeitern
Mitarbeiter an einem Heimarbeitsplatz nutzen interne 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 VPNRouter ist so konfiguriert, dass er automatisch eine Verbindung zum VPN-Server im LRZ aufbaut. Über
diese Verbindung, einen verschlüsselten IPsec LAN-to-LAN Tunnel, wird ein Subnetz mit der Subnetzmaske 255.255.255.248 geroutet. Damit stehen sechs IP-Adressen für Router, Rechner, ggf. 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.
Da insbesondere der VPN-Router veraltet ist, bedarf es einer alternativen Lösung.
Neue Telearbeiter erhalten deshalb nun einen Remote-Access-Point RAP3. Dieses Gerät baut einen
IKEv2/IPsec Tunnel zum WLAN-Controller im LRZ auf. Am RAP3 sind ein PoE Anschluss für das Telefon
und ein Ethernetanschluss für einen Rechner vorhanden. Zudem werden noch die WLAN-SSIDs aus dem
MWN ausgestrahlt. Diese Lösung wird sukzessive auch auf die anderen Telearbeitsplätze ausgerollt.
11.12.4
Entwicklung des Datenverkehrs über die VPN-Server
Im Jahr 2014 stieg der Datendurchsatz über die VPN-Server wieder leicht an. In Spitzenzeiten waren bis
zu 4.400 Nutzer parallel angemeldet. Im Monat November, dem Monat mit dem höchsten Datenaufkommen
wurden über 600.000 Verbindungen aufgebaut. Der im Jahr 2009 eingeführte SSL-VPN Client (Cisco
AnyConnect) hat inwischen einen Anteil von 90% aller Verbindungen erreicht.
147
Tabelle 27: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November
70
Jahr
Ausgehend
Eingehend
Gesamt
2005
0,7
3,2
3,9
50
2006
1,7
6,2
7,9
40
2007
3,1
11,4
14,5
30
2008
3,8
12,7
16,5
20
2009
4,6
20,7
25,3
10
2010
8,0
28,8
36,7
0
2011
11,4
44,9
56,3
2012
12,0
51,6
63,6
2013
10,5
43,1
53,6
2014
11,7
48,4
60,1
60
Ausgehend
Eingehend
Gesamt
Abbildung 85: Datenverkehr in Terabytes
über die VPN-Server im Referenzmonat
November
5000
4500
4000
3500
3000
2500
2000
1500
1000
500
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 86: Anzahl der maximal gleichzeitig an den VPN-Servern angemeldeten Nutzer
148
70.000
Eingehend
60.000
Ausgehend
Summe
50.000
40.000
30.000
20.000
10.000
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 87: Monatliches Datenvolumen der VPN-Server in Gigabyte im Jahr 2014
149
12 Kurse, Ausbildung und Benutzerbetreuung
12.1 Kurse und Veranstaltungen
Das LRZ bietet seinen Kunden regelmäßig an die 30 Kurse an, die sich in die Bereiche PC-Software,
Hochleistungsrechnen und weitere Veranstaltungen einteilen lassen. Die in Tabelle 28 bis Tabelle 30 aufgeführten Veranstaltungen wurden von fast 6.500 Teilnehmern besucht. Zusätzlich haben externe Anbieter
weitere Kurse angeboten.
12.1.1 Kursübersicht, Statistik 2014
Wie schon in den vergangenen Jahren wurden die Kurse, die vom LRZ zum Thema Hochleistungsrechnen
angeboten wurden, gut angenommen. Bei der Planung konnte stets davon ausgegangen werden, dass alle
Teilnahmewilligen, die einen Platz im Kurs erhalten, diesen auch wahrnehmen würden. Dies darf beim
übrigen Kursangebot leider nicht als selbstverständlich vorausgesetzt werden. Gerade bei den Kursen zu
PC-Software ist der Unterschied zwischen der Zahl der Anmeldungen und der Zahl der Teilnehmer nach
wie vor groß. Dies hat hohen Verwaltungsaufwand für diese Kurse zur Folge, müssen doch bei jeder Absage auf einen erteilten Kursplatz wieder alle organisatorischen Schritte für die Nachrücker durchlaufen
werden.
Es zeigte sich, dass das Interesse an Kursen zu den aktuellen Microsoft Office-Produkten nach wie vor
groß war. 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 „übersprungen“.
Gerade bei den Microsoft Produkten neigen Anwender und Systemverantwortliche dazu, nur immer jede
übernächste Version zu akzeptieren und zu installieren; und dies meist mit guten Gründen und einem zeitlichen Versatz – während auf die ersten Service Packs gewartet wird.
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. In Zusammenarbeit mit dem Herdt-Verlag und dem RRZN ist auch ein noch günstigerer
Erwerb der Schriften als PDF-Variante im Testbetrieb.
Tabelle 28: Kurse zu PC-Software 2014
Dauer (Stunden)
Anzahl der Kurse
Anzahl der angemeldeten Teilnehmer
Word 2013 (Kompaktkurs)
9
3
136
Word 2013 (Fortsetzungskurs)
9
1
21
Excel 2013 (Kompaktkurs)
9
5
453
Excel 2013 (Fortsetzungskurs)
9
3
241
PowerPoint 2013 (Kompaktkurs)
7
4
150
Access 2013 (Kompaktkurs)
11
1
41
Photoshop Elements 11
Einführungskurs
9
1
56
Einführung in SPSS
8
2
50
Insgesamt
71
20
1.148
Kurstitel
150
Kurse, Ausbildung und Benutzerbetreuung
Tabelle 29: Kurse zum Hochleistungsrechnen 2014
Dauer (Stunden)
Anzahl der Kurse
Anzahl der angemeldeten Teilnehmer
Introduction to GASPI
18
1
5
PRACE PATC Course: NodeLevel Performance Engineering
16
1
23
Advanced Fortran Topics
48
1
24
Alinea DDT Workshop
9
1
9
C/C++ Workshop
15
1
38
Extreme Scaling Workshop
27
1
10
Insgesamt
133
6
109
Kurstitel
Tabelle 30: Führungen durch das LRZ und Vorführungen am V2C
Anzahl der Veranstaltungen
Anzahl der angemeldeten
Teilnehmer
Führung durch das LRZ
86
2.702
Besichtigung des Zentrums für
virtuelle Realität und Visualisierung
305
2.505
Insgesamt
391
5.207
Veranstaltungstitel
Auch im Jahr 2014 wurde – zusätzlich zum regulären Kursprogramm – die vorhandene, moderne Infrastruktur im Hörsaal, den Seminar- und Kursräumen für andere Veranstaltungen genutzt. Softwarefirmen
hatten die Gelegenheit, neue Produkte bzw. neue Versionen bekannter Produkte zu präsentieren. Dabei
standen wieder Beispiele für die Nutzung in Forschung und Lehre im Vordergrund.
Tabelle 31: Weitere Veranstaltungen in den Räumen des LRZ
Titel
Datum
DRIHM-Meeting
20.01.2014
piCS Workshop Geoscience
21.01.2014
VAO-II Alpen-DAZ
29.01.2014
CSC-Board Visit
28.01.2014
Münchener Kreis
29.01.2014
3M-Meeting
30.01.2014
SeisSol-Meeting
31.01.2014
Lenkungsausschuss-Sitzung SuperMUC
13.02.2014
Rechenzentrum Darmstadt
10.02.2014
piCS Workshop
11.02.2014
Fujitsu
12.02.2014
SfH Service Management
14.02.2014
USM – LRZ Non-relational Database Meeting
20.02.2014
151
FitSM Foundation und ITSM Workshop
25.02. – 26.02.2014
Einführung Duale Hochschule Karlsruhe
26.02.2014
Megware – LRZ-Treffen
27.02.2014
SeisSol PRACE-PaperWP141
28.02.2014
OCIP-Meeting
03.03. – 05.03.2014
Parallel Programming of High Performance Systems
10.03. – 14.03.2014
BSB Fedora
17.03. – 21.03.2014
Peter Kacsuk: Research Laboratory / MTA-STAKI, Hungary
18.03.2014
Meeting SCI-BUS/SHWA/ER-Flow
19.03.2014
CAD-Stelle Bayern, Staatliches Bauamt München
19.03.2014
Deutsche Börse (Cloud Computing)
20.03.2014
RZG Technical Meeting
24.03.2014
Eclipse Kurs
25.03.2014
Girls’ Day
27.03.2014
Intel (Vortrag Hr. Klemm)
31.03.2014
Advanced Parallel Programming
31.03. – 04.04.2014
Citrix Veranstaltung
01.04. – 02.04.2014
FedSM work meeting
03.04. – 04.04.2014
Mellanox CEO Meeting
Open Foam
11.04.2014
12.04. – 14.04.2014
Ansys und Cadfem
24.04.2014
FAST-Treffen
23.04.2014
MIC & GPU Programming
28.04.2014
ISO/IEC 27001 Foundation
28.04. – 29.04.2014
SASER-Demo mit NSU und TUM
LRZ CEA Meeting
29.04.2014
05.05. – 06.05.2014
Workshop HP Networking ProVision
06.05.2014
Rechenzentrumslösungsberater Microsoft Deutschland
09.05.2014
Flow AirS Workshop TU
13.05.2014
Microstaxx HP-Networking Technology Day
15.05.2014
Audi-Kooperations-Treffen
16.05.2014
Workshop “Internet of Things”
21.05.2014
BGCE Research Day
22.05.2014
Alinea Workshop
02.06.2014
Extreme Scaling Workshop
Australian National University
ISAM Mathematical Writing Course
Compact Course Stabilized Finite Elements in fluid Dynamics for Simulation and Optimization
03.06. – 05.06.2014
20.06.2014
24.06. – 25.06.2014
25.06.2014
152
Kurse, Ausbildung und Benutzerbetreuung
Lehrveranstaltung Prof. Mainzer, “Geist-Gehirn-Maschine”
26.06.2014
Prof. Renner, Hochschule München
07.07.2014
KONWIHR
08.07.2014
Rotary Club
08.07.2014
SuperMUC Review Workshop
09.07.2014
NEC – LRZ-Meeting
10.07.2014
Jacobsen Research Day
16.07.2014
Besuch Lehrstuhl Prof. Ruhl (LMU)
17.07.2014
ISO/IEC 2000 Kurs
22.07. – 23.07.2014
IPCC Meeting
23.07.2014
Delegation Beihang University
23.07.2014
Immunoinformatik Prof. Antes
08.08.2014
Clean Tech Campus – LRZ
11.08.2014
GNU Hacker Meeting
15.08.2014
ICT-Glow 2014 Symposium
04.09.2014
IESP Besuch
09.09.2014
Mr.SymBioMath 2nd Summerschool
15.09. – 17.09.2014
Iterative Gleichungslöser und Parallelisierung HPARIS14
15.09. – 19.09.2014
PRACE-4IP HM Meeting
29.09.2014
Tag der offenen Tür
11.10.2014
Wissenschaft und Dialog
20.10. – 21.10.2014
Vorlesung Strategisches IT-Management Prof. Haucke TU
23.10.2014
GCS Lenkungsausschuss-Sitzung
20.10.2014
Software-Architecture
27.10.2014
KONWIHR
28.10.2014
Autotune Plenary Meeting
03.11.2014
Architectures for managing Big Data in the Enterprise
03.11. – 05.11.2014
HPCCIW-Kurs
03.11. – 07.11.2014
Jugend präsentiert
05.11. - 07.11.2014
Mellanox-Treffen
05.11.2014
Vortrag Prof. Dr. Matiyaesvich (TU)
05.11.2014
CIMA Cooperation-Meeting
06.11.2014
Daten-Schutztag
12.11. – 13.11.2014
FitSM-SPD-Pilot-Training
20.11. – 21.11.2014
Study Visit Jahrestagung – Netzwerk Wissensmanagement
Open FOAM Kurs
20.11.2014
24.11. – 25.11.2014
27.11.2014
Gastvortrag TU Strategisches IT-Management
27.11.2014
Intel Long Range Planung (CPU)
01.12.2014
153
Introduction to OpenFOAM
01.12. – 03.12.2014
BayFOR-Meeting
02.12. – 03.12.2014
GEANT – CMon Team F2F Meeting
04.12. – 05.12.2014
PATC Kurs: Node Level Engineering
04.12. – 05.12.2014
BGCE-Research Day
11.12.2014
Kontron Meeting
11.12.2014
Open-Lab-Day
16.12.2014
EnCompHS Proposal-Preparation Meeting
17.12. – 18.12.2014
Fort Fantastic-Hochschule Kempten
19.12.2014
Exkursion Hochschule Kempten ans LRZ mit Fort Fantastic
22.12.2014
154
Software-Bezug und Lizenzen
13 Software-Bezug und Lizenzen
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 aufs 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.
13.1 Microsoft
13.1.1 Mietlizenzen für LRZ und Akademie
2014 wurde entschieden, die Versorgung der Arbeitsplatzrechner der BAdW mit Microsoft-Lizenzen von
Kauf- auf Mietlizenzen umzustellen. Gründe sind u.a.:
•
Die Mietlizenzen werden pro Mitarbeiter gezählt, die Kauflizenzen pro Gerät – es sind aber mehr
Geräte als Mitarbeiter vorhanden, u.a. wegen Kursräumen, Laptops, Poolrechnern und Laboren
• Die Lizenzierung von virtuellen Desktops wird dadurch erleichtert und billiger
• Die Lizenzierung wird generell einfacher
Durch den Bundesrahmenvertrag des LRZ mit Microsoft sind diese Vorteile nun realisierbar geworden.
Durch Beitritt zu diesem Vertrag kann auch eine relativ kleine Einrichtung wie die BAdW (dreistellige Mitarbeiterzahl) die beste Preisstufe bei Mietlizenzen erhalten. Die LRZ-Mitarbeiter sind durch den Beitritt der
Akademie mit abgedeckt, nicht jedoch die des Walter-Meißner-Instituts, da dieses von Microsoft nicht als
Verwaltungseinrichtung für Hochschulen angesehen wird. Die bisher gekauften Lizenzen bleiben im Eigentum der BAdW. 2014 wurden im Hinblick auf den kommenden Vertrag fast ausschließlich nur noch solche
Kauflizenzen erworben, die im neuen Vertrag nicht enthalten sein werden (z.B. Serverlizenzen oder spezielle Zugriffslizenzen). Der Vertragsabschluß ist für Anfang 2015 vorgesehen.
13.1.2 Zugang der Universitätskliniken zum Bundesvertrag
Im Juni 2014 hat das LRZ einen Rahmenvertrag mit Microsoft Irland geschlossen, der den deutschen Universitätskliniken Zugang zu Mietlizenzen wie im Bundesvertrag für Hochschulen ermöglicht. Hintergrund:
Microsoft behandelt Universitätskliniken nicht wie Hochschulen. Mit diesem Vertrag können sie jedoch die
gleichen Konditionen und Rabatte erhalten, es handelt sich quasi um einen Klon des Bundesvertrags.
13.1.3 Plausibilisierungen
oder: „Damokles-Schwert der Software-Audits“
In diesem Jahr begann Microsoft, einzelne deutsche Universitäten zu Plausibilisierungen der SoftwareLizenzierung ihrer Server und Arbeitsplätze aufzufordern. Damit konkretisiert sich der bereits in den letzten
Jahren beobachtete Trend, dass große Hersteller Audits und Plausibilisierungen an Hochschulen verlangen. Im Softwarelizenz-Bereich vertragskonform zu bleiben wird jedoch durch die stark zunehmende Komplexität im Lizenzrecht vor allem in virtualisierten Infrastrukturen zunehmend erschwert. Einige deutsche
Hochschulen sprechen mit Microsoft über Pilotprojekte zur Einführung einer Lizenzverwaltung, aus denen
eventuell auch Microsoft selbst lernen kann, dass ihr Lizenzrecht für Hochschulen zu kompliziert und nicht
umsetzbar ist. Die Universität Bonn hat ein solches Projekt gestartet.
13.2 Adobe
13.2.1 CLP
CLP (Cumulative License Program), der bundesdeutsche Rahmenvertrag für Kauflizenzen, wurde vom
LRZ mit Adobe Ende 2014 für zwei weitere Jahre verlängert, allerdings veröffentlicht Adobe im CLP-Programm kaum noch neue Versionen und kündigte zuletzt an, im ersten Quartal 2015 die meisten Produkte
aus dem CLP-Programm abzukündigen.
155
13.2.2 ETLA Desktop
Neben dem CLP gibt es noch einen weiteren bundesweiten Rahmenvertrag des LRZ mit Adobe, bekannt
als ETLA (Enterprise Term License Agreement). Dieser Vertrag allein wird aber künftig, nachdem CLP von
Adobe nun „entkernt“ wird, nicht genügen, um alle Universitäten und Hochschulen mit Adobe-Lizenzen zu
versorgen, da er nur flächendeckende Versorgung („Flatrate“) über alle Mitarbeiter regelt. Viele Produkte
werden aber lediglich von einem kleinen Anteil der Mitarbeiter benötigt („Einzelplatzlizenzen“) und sie für
die gesamte Einrichtung zu lizenzieren wäre unwirtschaftlich (Einzelplatzlizenzen wurden bisher über CLP
abgedeckt). Adobe will, dass künftig Einzellizenzen nur noch zur Miete („Creative Cloud“) erhältlich sind,
und zwar in Form von für Hochschulen ungeeigneten "VIP"-Verträgen.
Die seit 2013 laufenden Gespräche zwischen Adobe und Hochschulvertretern aus Deutschland, Österreich
und der Schweiz zur Anpassung der neuen Lizenzstrategie von Adobe an die europäische Hochschullandschaft („ETLA Desktop“: Ziel ist, dass einzelne Lizenzen nach Bedarf und ohne die Nachteile von „VIP“
gemietet werden können) sind im November 2014 gescheitert, da Adobe entgegen vorheriger Ankündigungen keinen Vertragsentwurf außerhalb von VIP anbieten wollte. Seitdem müssen wir den Lehrstühlen Alternativen zu Adobe-Produkten empfehlen.
13.3 Ansys
Die Versorgung mit Ansys-Lizenzen im MWN wurde von Miete auf Kauf mit Wartung umgestellt und die
Versorgungsgüte konnte für die Ansys-Anwender im MWN bei gleichbleibenden oder sinkenden Preisen
verbessert werden. Die Umstellung auf Kauflizenzen bot sich an, da die Konditionen für den Kauf im Vergleich zu den Vorjahren deutlich günstiger geworden waren. Der Break-Even gegenüber fortgesetzter Miete
wird dabei vorausichtlich nach weniger als drei Jahren erreicht.
13.4 SPSS
Der bestehende Landesvertrag zu SPSS mit IBM läuft zum 1.1.2016 aus. IBM konnte bisher kein bezahlbares Angebot für die Verlängerung der Wartung der seinerzeit gekauften Lizenzen machen sondern
möchte scheinbar nur Neulizenzen verkaufen, und zwar über einen von IBM exklusiv bestimmten Händler,
die Firma Asknet. Die Gespräche mit Asknet, die wir gemeinsam mit Vertretern der Arbeitskreises Software-Lizenzen des ZKI und den Rahmenvertragshaltern der anderen Bundesländer führen, gestalten sich
ziemlich komplex.
13.5 VMware
Zur Verlängerung und Harmonisierung der Wartung der VMware-Lizenzen bayerischer Hochschuleinrichtungen hat die Vergabestelle der Universität Würzburg die Ausschreibung eines Händlers organisiert, an
der sich u. a. das LRZ und die TUM beteiligt haben.
13.6 Software Asset Management
In Abstimmung mit Vertretern der Arbeitskreises Software-Lizenzen des ZKI wurden schon 2013 Anbieter
für Softwareprodukte zur Verwaltung von Lizenzen evaluiert und das Produkt Spider der Fa. Brainwaregroup für ein Pilotprojekt ausgewählt. Spider war deutlich günstiger als die Konkurrenz, kann hochschulübergreifendes Vertragsmanagement und bei der Preisberechnung werden Mitarbeiter, nicht Geräte, gezählt, was dem Hochschulumfeld besser entspricht. Im Pilotprojekt werden die Module Vertragsmanagement und Lizenzmanagement für die hochschulinterne Lizenzverwaltung getestet. Die Teilnehmerzahl in
diesem deutschlandweiten Projekt ist 2014 gestiegen und es wurde 2014 die Basis gelegt, um Rahmenund überregionale Verträge in das jeweilige Vertragsmanagement der einzelnen Hochschulen einpflegen
zu können. Ab dem nächsten Jahr soll auch die Zuordnung, welche Lizenzen auf welchen Geräten eingesetzt werden, nach und nach eingepflegt werden. Das LRZ plant, das Produkt für das hausinterne Software
Asset Management einzusetzen.
13.7 Verlängerung und Ausbau bestehender Verträge
2014 wurden mehrere auslaufende Verträge abgelöst oder planmäßig verlängert:
•
Labview-„Flatrates“ (Academic Teaching Site License) der Firma National Instruments im MWN
156
Software-Bezug und Lizenzen
•
•
SAS (neben SPSS eine weitere häufig nachgefragte Statistik-Software)
Matlab (LMU, Hochschule München; nicht TU München, wo weiterhin ein Flatrate-Vertrag direkt
mit Mathworks besteht)
• Intel (Lizenzen für Compiler und Tools)
• ESRI-Landeslizenz (Verlängerung der ESRI-Landeslizenz um weitere drei Jahre unter Berücksichtigung der aktuellen Bedarfe der Teilnehmer und Änderungen im Produktportfolio (z.B. CloudDienste))
• Corel-„Flatrate“ für BAdW/LRZ
• Amira: bei Amira hat sich sowohl die Nachfragesituation im MWN als auch die Paketierung von
Seiten des Anbieters in den letzten 1-2 Jahren geändert, so daß die bestehende Campuslizenz
zunehmend unwirtschaftlich wird. Vermutlich wird 2015 nicht mehr verlängert.
• Erdas
• Scientific Workplace: Die Campuslizenz für SWP konnte im Preis deutlich heruntergehandelt werden, da die Nutzung in den letzten Jahren zurückgegangen ist.
• Mindmanager (Downloadzahlen in 2014: LMU 61, TUM 338)
Die NAG-Landeslizenz (für numerische Bibliotheken) wurde nicht mehr verlängert, da die beteiligten Hochschulen finanziell nicht mehr im erforderlichen Umfang beitragen möchten.
13.8 Tagesgeschäft
13.8.1 Abläufe und Änderungen bei der Versorgung der Kunden des LRZ
Das LRZ stellt den Münchner Hochschulen unter anderem Kauflizenzen aus den Bereichen
• Microsoft-Lizenzen im Rahmen der Select-Plus-Verträge
• Adobe- und Corel-Bestellungen im Rahmen des Adobe CLP-Vertrags
zur Verfügung. Dies sind bisher die umsatzstärksten Bereiche. Wo es sinnvoll ist, eine flächendeckende
Pauschalversorgung mit Mietlizenzen einzuführen, sollte das auch gemacht werden. Dadurch kann der
anfallende Arbeitsaufwand sowohl in den Instituten als auch im LRZ reduziert werden. Der mit Kauflizenzen
erzielte Umsatz ist also kein Erfolgsindikator. Die TUM ist Bundesrahmenvertrag des LRZ mit Microsoft
schon vor einiger Zeit beigetreten und musste daher in 2014 nur noch spezielle Lizenzen über das SelectPlus Programm kaufen.
Bei Bestellungen zu Microsoft und Adobe/Corel-Kauflizenzen kümmert sich das LRZ im Tagesgeschäft
lediglich um Authentifizierung/Autorisierung der Besteller, Verteilung der Software, Beratung und 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. Die zuletzt angestiegenen Adobe-Bestellungen lassen sich auf „Vorratskäufe“ zurückführen, da 2015 vorerst kein geeigneter Bezugsweg für Adobe-Lizenzen bereitsteht (s. o.).
Tabelle 32: Die umsatzstärksten Softwarepakete
Hersteller /
Beschreibung
Lizenzzahlen 2014
Name
Microsoft
Applikationen, System- und ServerSoftware (Kauflizenzen)
Adobe
Bruttowert
der
2014 beschafften
Lizenzen
11.851
424.780 €
Kauflizenzen
6.773
452.885 €
Corel
Kauflizenzen
161
7.414 €
Systat
Datenanalyse und
Datenpräsentation
44
13.272 €
157
Tabelle 32 listet die wertmäßig umsatzstärksten Softwarepakete (nur Kauflizenzen) auf. Miet- und Subskriptionsmodelle (SPSS, Matlab, Novell, SAS) sowie Flatrate Verträge (ESRI, Sophos) werden nicht in
dieser Tabelle erfasst.
Für Einrichtungen mit zentralem Einkauf besteht die Möglichkeit, die am meisten nachgefragten Kauflizenzen beim LRZ online zu bestellen. Zu diesen Einrichtungen zählen die Münchner Universitätskliniken, die
Universität Augsburg, einige Fachhochschulen aus dem südbayerischen Raum, einige Institute von LMU
und TUM sowie einige kleinere Einrichtungen.
Bei den meisten anderen Produkten tritt das LRZ in Vorleistung und beteiligt die Institute an den Kosten.
Produkte aus Landesverträgen des LRZ (Novell, Sophos, ESRI, auch Microsoft Premier Support) werden
den bayerischen Universitäten und Hochschulen nach einem festen Kostenschlüssel bereitgestellt (ESRIProdukte werden an der LMU teilweise noch mit den Instituten einzeln abgerechnet). Produkte aus den
Bundesrahmenverträgen (Microsoft, Adobe ETLA) werden dagegen direkt zwischen den ausgeschriebenen Händlern und den Lizenznehmern abgewickelt, ohne dass das LRZ involviert werden muss.
Über den Microsoft-Bundesrahmenvertrag versorgten sich Universitäten und Hochschulen allein in Bayern
im Jahr 2014 mit Software-Lizenzen im Wert von brutto fast 2 Mio. Euro, Tendenz steigend. Im Bundesgebiet sind bis Jahresende 147 Hochschulen diesem Vertrag beigetreten.
13.8.2 Betrieb von Lizenzservern für Kunden des LRZ
Das LRZ betreibt derzeit für ca. 35 unterschiedliche Softwarepakete Lizenzserver, die für die Benutzer im
MWN Netzwerklizenen zur Verfügung stellen. Das angebotene Spektrum der Netzwerklizenzen beinhaltet
vor allem technisch-wissenschaftliche Software wie Matlab, Mathematica, Ansys, Tecplot, etc. Einen weiteren Schwerpunkt bilden Lizenzen für Pakete zur Softwareentwicklung wie Compiler, Debugger und Tools
zur Performanceanalyse.
Für Kurse und Praktika in den CIP-Pools der berechtigten Einrichtungen im MWN werden die Teaching
Lizenzen der FE-Software Ansys über den Lizenzserver vom LRZ kostenfrei zur Verfügung gestellt. Seit
Beginn des Wintersemesters 2014/2015 sind zudem für alle Studenten und Mitarbeiter der beteiligten
Hochschulen die Ansys Teaching Lizenzen des Lizenzservers auch allg. kostenfrei verfügbar.
Der zentrale Betrieb der Lizenzserver am LRZ erspart den Mitarbeitern an den Lehrstühlen und Instituten
im MWN den redundanten Betrieb eigener Lizenzserver und damit viel Arbeit. Im Bedarfsfall unterstützt
das LRZ die Anwender bei der Anbindung ihrer Rechner an die Lizenzserver am LRZ.
158
Gebäude und Infrastruktur
14 Gebäude und Infrastruktur
14.1 Gebäudemanagement
Das Hauptanliegen der Gebäudetechnik, dem IT-Betrieb des LRZ eine verlässliche Betriebsumgebung zu
bieten, wurde auch 2014 erreicht. Einige Stromunterbrechungen auf Versorgerseite und anhaltende Mängelproblematiken auf Kühlungs- und Leittechnikseite stellten die besonderen Herausforderungen des Jahres dar. Die Infrastruktur an Kühlung als wichtigste Aufgabe des Infrastrukturmanagements konnte mit großem Einsatz des Gebäudebetriebspersonals stabil betrieben werden, obwohl mehrere Personalwechsel
innerhalb der Haustechnik den Verlust von Know-How spürbar werden ließen.
Im Einzelnen gab es noch immer viel Arbeit mit Restleistungen und Mängeln aus dem Bauabschnitt 2
(„Erweiterungsbau“) aus den Jahren 2009-2011. Dies betraf vornehmlich die Bereiche der Gebäudeleittechnik (GLT), des Wasserkühlsystems und der Luftkühlung.
•
Die GLT hat für Überwachung und Steuerung der Gebäudetechnik rund um die Uhr zentrale Bedeutung. Erst 2014 konnten die wichtigsten Funktionen der GLT zuverlässig erbracht und Störungsmeldungen wirksam zugestellt werden. Trotzdem kommt es hier immer wieder zu betriebsgefährdenden Rückschlägen. Diese sind teils Inbetriebnahme-Mängeln, teils den verwendeten
GLT-Steuerungskomponenten mit ihren nicht robusten Kommunikationsprotokollen geschuldet.
Diese scheinen eher für allgemeine Haus- und Gebäudetechnik als für unseren Effizienz-betonten
RZ-Betrieb mit bescheidener Redundanz entworfen.
•
Im Bereich der Wasserkühlsysteme konnten Kühltürme und Wasseraufbereitung einem einigermaßen stabilen Betrieb zugeführt werden.
Leider musste wegen der unergiebigen Niederschlagssituation auf die Kühlleistung des Grundwasserbrunnens weitgehend verzichtet werden.
Die Luftkühlungssysteme leiden noch immer darunter, dass unter dem Zeit- und Preisdruck in der
Erstellungsphase 2009-2011 notwendige Inbetriebnahme-Aufwände unterblieben oder nur inkompetent erledigt wurden.
Auf Elektroversorgungsseite wurde der Gesamtwirkungsgrad durch die zeitweilige Abschaltung redundanter Komponenten, v.a. dynamischer USVs, erhöht.
Größere Revisionen waren an den Batterieanlagen der stat. USVs und am Austausch verkalkter
Rückkühlregister fällig.
•
•
•
•
An Maßnahmen waren 2014 wichtig:
•
Der 2013 auf Wasserkühlung ertüchtigte HRR-Bereich wurde für die Phase 2 des SuperMUC vorbereitet und nimmt gegen Jahresende die ersten Racks in Betrieb (s. Abbildung 88). Hier wurde
auch die Elektroversorgung verändert, um der Phase 2 eine getrennte Versorgungsumgebung zu
bieten zu können und einen großen Teil des Jahres 2014 den elektrischen Wirkungsgrad der Phase
1 erhöhen zu können (durch Abschaltung einzelner USVs).
14.2 Energieeffizienz
Die im Jahr 2013 begonnene Erweiterung der Messinstrumentierung für die Kühlungs- und Stromversorgungsinfrastruktur konnte in 2014 abgeschlossen werden.
Auf der Basis der ausgebauten Instrumentierung konnte die Betriebseffizienz verbessert werden: es gelang
einerseits, Störungen beim Betrieb der Klima-und Kälteaggregate zu verringern bzw. in ihren Auswirkungen
durch frühere Erkennung und Fehlerisolation zu dämpfen. Andererseits ermöglicht die Verbesserung des
Umfangs und der Qualität der Anlagendaten eine präzisere Ermittlung der Kenngrößen, die im Rahmen
der Maßnahmen zur Steigerung der Energieeffizienz benötigt werden.
Um die Leistungsfähigkeit der Kühlungsinfrastruktur zu optimieren, ist mit einer Detailanalyse der Kenndaten für die Rückkühlwerke begonnen worden und eine Revision der Steuer- und Regelungscharakteristik
der Kälteerzeugungsgewerke eingeleitet worden. Diese Maßnahmen zur Optimierung der Rechenzentrumsinfrastruktur sollen im nächsten Jahr fortgeführt werden.
Abbildung 88: Wasseranschlüsse für die Racks des SuperMUC Phase 2
159
160
Personal
15 Personal
Die Anzahl der Mitarbeiter im LRZ ist im Jahre 2014 weiter leicht angestiegen. Leider konnten wie im Vorjahr aufgrund der guten Konjunkturlage im IT-Bereich erneut offene Stellen teilweise gar nicht bzw. erst
nach mehrfachen Ausschreibungen erfolgreich besetzt werden. So waren Ende 2014 am LRZ 160 Mitarbeiter und 42 wissenschaftliche und studentische Hilfskräfte beschäftigt. Wie in den Vorjahren wurden wieder zwei Auszubildende (ein IT-System-Elektroniker und ein Fachinformatiker der Richtung Systemintegration) am LRZ eingestellt. Zwei Auszubildende konnten ihre Ausbildung erfolgreich abschließen und einer
davon konnte befristet übernommen werden.
Ein Mitarbeiter des LRZ, Herr PD. Dr. Helmut Reiser, wurde zum außerplanmäßigen Professor an der LMU
ernannt. Zahlreiche Vorträge auf Konferenzen und Fachtagungen, viele wissenschaftliche Veröffentlichungen sowie der erfolgreiche Abschluss mehrerer Promotionen belegen zudem die Kompetenz des LRZ.
161
16 Zahlen und Fakten
16.1 Personal
Tabelle 33: Tabellarische Personal-Übersicht
Personalstand (31.12.2014)
160
Mitarbeiter
42
Stud. und wiss. Hilfskräfte
9
Wiss. Mitarbeiter
1
Verwaltungsangestellte
2
Auszubildende
4
Praktikanten
16
7
Wiss. Mitarbeiter
2
Verwaltungsangestellte
1
Auszubildender
3
Praktikanten
11
208
Inland
149
Ausland
357
Insgesamt
Neueinstellungen
Abgänge
Dienstreisen
Entwicklung des Dienstreiseaufkommens
400
Anzahl der Reisen
350
300
250
200
150
100
50
0
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
Anzahl der Reisen gesamt
Auslandsreisen
Inlandreisen
Abbildung 89: Entwicklung des Dienstreiseaufkommens 2000-2014
162
Zahlen und Fakten
16.2 E-Mail und Exchange
Tabelle 34: E-Mail und Exchange
E-Mail und Exchange
gerundet
Exchange-Postfächer
42.000 mit 12 TByte
POP/IMAP-Postfächer
94.500 mit 10 TByte
E-Mail-Verteilerlisten
1.050
Eintreffende E-Mails/Tag
800.000
•
davon angenommen
190.000 (24 %)
•
davon abgelehnt (Spam- und Virenmails)
610.000 (76 %)
Server für E-Mail-Dienste
30
Server für Exchange
12
16.3 Poster und Schriften
Tabelle 35: Poster und Schriften
Großformat Poster - Schriften
Großformat Poster insgesamt
4.115
•
am LRZ abgegeben
1.377
•
Bibliothek der LMU
1.518
•
Bibliothek der TUM
1.092
•
Biozentrum der LMU
Schriften - Umsatz
128
3.349
16.4 Benutzerverwaltung und Shibboleth
Tabelle 36: Benutzerverwaltung und Shibboleth
Benutzerverwaltung und Shibboleth
Master User
2.158
LRZ-Projekte
1.877
•
Davon SuperMUC-Projekte
614
Authentifizierungen pro Woche an den Shibboleth IdPs
•
TUM Identity Provider
100.000
•
LMU Identity Provider
30.000
Server für Benutzerverwaltung, Directories und DFN-AAI
30
163
16.5 Höchstleistungsrechner
Tabelle 37: Höchstleistungsrechner SuperMUC
SuperMUC Phase 1
Anzahl Rechenkerne
159.496
Gesamthauptspeicherkapazität
342 TByte
Spitzenleistung
3,3 PFlop/s
Plattenspeicherkapazität
15.000 TByte
Anzahl Infinibandkabel
11.900
Gesamtlänger der Infinibandkabel
195 km
Direktwarmwasserkühlungsinfrastruktur mit
Eingangstemperatur
45°C
7,9 m3
Kühlwasservolumen (nur Rechnerraum)
Gesamtrohrlänge (nur Rechnerraum)
38,9 km
8 m2
Gesamt-CMOS-Fläche aller Intel-Prozesoren in der Anlage
Maximale elektr. Leistungsaufnahme der Anlage
Typische Leistungsaufnahme der Anlage
3,9 MW
< 2,3 MW
Gesamtgewicht der Anlage
Anzahl
Komponenten
Gesamter
Hauptspeicher
(in GB)
18 Thin 297216
Node Inseln
Eine Fat 52480
Node Insel
Knights 2432
Corner
Testsystem
200 t
Systemdaten
Typ der Komponenten
Prozessoren der
Komponenten
Aufgabe
Hochtemperatur-wassergekühl- Je Insel 516 iDataP- Höchstleistungsrechner
tes IBM System x iDataPlex mit lex Knoten mit jeweils für Benutzer aus den
Fat-Tree Verbindungsnetz auf zwei 8-Core Intel Hochschulen in Deutschder Basis von Mellanox FDR10 Sandy
Bridge-EP land sowie Tier-0 System
Infiniband Technologie.
(Xeon E5-2680) So- für europäische Nutzer
Die Inseln sind untereinander ckeln und 32 GByte aus dem PRACE Projekt;
für die Nutzungsberechtiebenfalls mit einem Fat-Tree ver- Hauptspeicher.
gung ist eine spezielle Bebunden, allerdings mit einer um
gutachtung durch den wisden Faktor 4 reduzierten Bandsenschaftlichen Lenkungsbreite.
ausschuss oder PRACELuftgekühltes IBM BladeCenter 205 x3850 Blades mit Begutachtung notwendig.
HX5 mit Fat-Tree Verbindungs- jeweils vier 10-Core Typ: Parallel-Rechner
netz auf der Basis von Mellanox Westmere-EX (Intel
QDR Infiniband Technologie.
Xeon E7-4870) Sockeln und 256 GByte
Hauptspeicher
Luftgekühltes IBM System mit Je Knoten zwei 8- Evaluation der Intel ManyMellanox FDR 14 Dual-Rail Inter- Core Ivy-Bridge Pro- Core Architektur, Portieconnect und 32 Rechenknoten zessoren und zwei rung und Optimierung von
60-Core Knight’s Cor- Applikationen.
ner Beschleuniger mit
insgesamt 76 GByte
Hauptspeicher
164
Zahlen und Fakten
16.6 Hochleistungs-Linux-System
Aus mehreren heterogenen Segmenten zusammengesetztes Linux-Cluster, der aus ca. 1.100 Komponenten mit insgesamt 23.5 TByte Hauptspeicher besteht, die mit 1 oder 10 GBit Ethernet, Myrinet, NUMALink
oder Infiniband vernetzt sind. Er dient zur Bearbeitung üblicher, auf Linux verfügbarer Anwendungsprogramme und für Programme, die mittels MPI und/oder OpenMP parallelisierbar sind.
Tabelle 38: Hochleistungs-Linux-Systeme (ohne SuperMUC)
Systemdaten
Anzahl
Anzahl der
Hauptder
Prozesso–
Typ der Komponenspei–cher
Komporen der
ten
der Komnenten
Kompoponente
nente
Aufgabe
1
SUN X4100
Opteron, 2600 MHz
2
4 GB
Komponente des Linux-Clusters:
SGE 6.2u2 Master-Server
1
SUN X4100
Opteron, 2600 MHz
4
8 GB
Komponente des Linux-Clusters:
Zentraler nagios-Überwachungsserver
8
MEGWARE
Xeon 8
E5462, 2800 MHz
16
15
SUN 4600
Opteron, 2800 MHz
64 GB
Attended Cluster-Housing-Knoten des Lehrstuhls für Mathematik der TU-München
35
MEGWARE
Xeon 4
X3230, 2667 MHz
8 GB
Attended Cluster-Housing-Knoten der Bayerischen Staatsbibliothek
124
MEGWARE
Xeon 4
X3230, 2667 MHz
8 GB
Komponente
des
Linux-Clusters:
LCG Tier-2 Rechen-Knoten
32
DELL
12
Xeon L5640, 2261
MHz
36 GB
Komponente
des
Linux-Clusters:
68
MEGWARE
Xeon 8
L5420, 2500 MHz
16 GB
Komponente
des
Linux-Clusters:
15
MEGWARE
Xeon 4
5060, 3200 MHz
4 GB
Komponente
des
Linux-Clusters:
LCG Tier-2 dCache-Knoten
13
MEGWARE
Xeon 4
5148, 2333 MHz
4 GB
Komponente
des
Linux-Clusters:
10
MEGWARE
Xeon 4
L5240, 3000 MHz
8 GB
Komponente
des
Linux-Clusters:
6
DELL
24
Xeon L5640, 2261
MHz
16 GB
Komponente
des
Linux-Clusters:
2
MEGWARE Quad- 16
Core Opteron, 2400
MHz
132 GB
Attended Cluster-Housing-Knoten des LMU
Exzellenz-Cluster
20
MEGWARE
Xeon 8
L5420, 2500 GHz
32 GB
Exzellenz-Cluster
112
MEGWARE Xeon L 8
5420, 2500 GHz
16 GB
Exzellenz-Cluster
32
GB Attended Cluster-Housing-Knoten des Lehrstuhls für Geodäsie der TU-München
165
Systemdaten
Anzahl
Anzahl der
Hauptder
Prozesso–
Typ der Komponenspei–cher
Komporen der
ten
der Komnenten
Kompoponente
nente
Aufgabe
1
MEGWARE
Xeon 4
E5504, 2000GHz
12
Attended Cluster-Housing-Knoten der LMU,
LS Prof. Ruhl
12
MEGWARE
Xeon 6
X5500, 2660GHz,
Je 1 NVidia GPU
48
LS Prof. Ruhl
4
MEGWARE
AMD Opteron,
Je 1 NVIDIA GPU
48
16 GB
LS Prof. Ruhl
19
Sysgen
Intel Xeon
16
128 GB
LS Prof. Scrinzi
1
SGI UV 2000
320
Sandy Bridge CPUs (8)
(NVidia GPUs)
5000 GB
LS Prof. Frey
4
SGI UV 20
32
Sandy Bridge CPUs
256 GB
LS Prof. Frey
38
MEGWARE
Opteron, 2600 MHz
32 GB
Komponente
des
Linux-Clusters:
x86_64-Cluster Knoten für parallele MPIund 8-fach Shared Memory Jobs
234
MEGWARE Opteron, 4
2600 MHz
8 GB
Komponente
des
Linux-Clusters:
x86_64-Cluster Knoten für serielle und parallele 4-fach Shared Memory Jobs
64
SGI Altix ICE8200
512
Xeon E5540, 2533
MHz
1536 GB
X86_64-MPP-Rechner
2 Prozessorsockel pro Knoten
8 Prozessorkerne pro Knoten
3 GB pro Prozessorkern
1
SGI UV1000
Xeon E7-4780,
2400 MHz
2080
3328 GB
X86_64-SMP-Rechner. Er wird mit zwei separierten Partitionen betrieben.
183
MEGWARE
2928
CoolMUC,
AMD
Opteron
6128HE,
2000 MHz
2928 GB
X86_64-MPP-Rechner
2 Prozessorsockel pro Knoten
16 Prozessorkerne pro Knoten
1 GB pro Prozessorkern
63
MEGWARE
1904
Unterschiedliche Architekturen, teilw. Mit
Beschleunigern
11200 GB
Wird für die Informatik der TUM gehostet;
Einsatz für Forschung an aktuellen Systemen sowie auch an Kühltechnologien.
8
166
Zahlen und Fakten
16.7 Hochleistungs-Graphik-System
Tabelle 39: Hochleistungs-Graphik-System
System
Remote
Visualisierungs
Cluster
Hersteller
und System-Typ
Systemdaten
(Bei Systemen, die aus mehreren Komponenten
bestehen, stehen die Daten der einzelnen Komponenten in den Zeilen darunter)
Struktur
Anzahl der Typ der
Komponen- Kompoten
nenten
IBM Sys- serielles
8 (7 für Betem
x Batch-Clus- nutzerbeiDataplex ter
(unter
trieb)
dx360 M4 SLURM)
server
Anzahl der
Prozesso- Hauptspeiren der
cher der
Kompo- Komponente
nente
Intel Xeon 2 CPUs, 1
E5-2690,
GPU
2.9 GHz,
NVidia Kepler GPU
128 GB
Aufgabe
Remote Visualisierung
von SuperMUC
Datensätzen
167
16.8 Datenspeicher
Die Tabelle gibt differenziert nach Speicherarchitektur einen Überblick über die Bruttokapazität der Plattenspeichersysteme des LRZ Ende 2014 und deren primäre Verwendung. Die tatsächliche Nutzspeicherkapazitä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 Protokolle CIFS und NFS und zugegriffen. Die SANPlattensysteme sind mit den Rechnern und Bandlaufwerken über die Speichernetz-Infrastruktur verbunden.
Tabelle 40: Bruttokapazitäten Online-Speicher (NAS + SAN)
BRUTTOKAPAZITÄTEN ONLINE-SPEICHER (NAS+SAN)
Typ
Modell
Anwendung
Kapazität
NAS
2 x NetApp FAS 6280
MWN Storage Cloud, NFS-Dateidienste, LinuxMailsysteme
NAS
1 x NetApp FAS 6280
Replikationssystem für MWN Storage Cloud,
NFS-Dateidienste, Linux-Mailsysteme
912 TB
NAS
2 x NetApp FAS 6280
Speicher für Sync+Share (zukünftig auch für
MWN Storage Cloud, NFS-Dateidienste)
960 TB
NAS
1 x NetApp FAS 6280
Replikationssystem für Sync+Share
912 TB
NAS
4 x NetApp FAS6290
Speicher für VMWare (inkl. Replikation)
675 TB
NAS
2 x NetApp FAS 3170
Speicher für LZA-Projekte der BSB
730 TB
NAS
16 x NetApp FAS 6280
Projektspeicherplatz für SuperMUC
5.000 TB
NAS
6 x NetApp FAS 6280
Replikation Projektspeicherplatz für SuperMUC
und VMware
4.224 TB
NAS
2 x NetApp FAS 3170
Metrocluster für Hochschulstart.de
NAS Gesamt
9 x IBM DS3500
Cache für Archiv- und Backupsystem
SAN
3 x SUN 6780
DB+Cache für Archiv- und Backupsystem
SAN
2 x IBM StorWize SSD
DB für Archiv- und Backupsystem
SAN
4x Dell PowerVault
DB+Cache für Archiv- und Backupsystem
Gesamt NAS+SAN
74 TB
14.927 TB
SAN
SAN Gesamt
1.440 TB
1938 TB
486 TB
10 TB
281 TB
2.729 TB
17.642 TB
Unter Nearline-Systemen 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 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.
168
Zahlen und Fakten
Tabelle 41: Kapazitäten der Nearline-Speicher
KAPAZITÄTEN DER NEARLINE-SPEICHER
Systemname
Bandbibliothek
Bandlaufwerke
Kassetten
Kapazität
DRABS
IBM TS3500
7 x IBM LTO 5
8 x IBM LTO 6
12.700
25.750 TB
SUN SL8500
26 x SUN T10K
10.000
10.000 TB
IBM TS3500
15 x IBM LTO 5
10 x IBM LTO 6
9500
19.150 TB
15.000
21.616 TB
47.200
76.516 TB
HABS
IBM TS3500
LABS
Gesamt
10 x IBM LTO 4
8 x IBM LTO 5
16 x IBM LTO 4
SUN SL8500
16 x IBM LTO 5
20 x IBM LTO 6
5
126
169
16.9 Das Münchner Wissenschaftsnetz (MWN)
Tabelle 42: Das MWN in Zahlen
MWN in Zahlen
Netzkomponeten im Management
4.000
Switches
1.500
Access Points
2.700
Ports (Kupfer)
93.000
Ports (Glas)
7.700
Bandbreite des Internet-Zugangs (X-WiN)
23,6 Gbit/s
Bandbreite des Internet-Zugangs (M-net)
10 Gbit/s
Datenmenge pro Monat am Internet-Übergang
eingehend
1 bis 1,2 PB
ausgehend
0,5 bis 0,8 PB
Wohnheime
Angeschlossene Heime
Versorgte Wohnheimplätze
52
12.500
Dienste
WLAN
Maximum der gleichzeitigen Nutzer im 5 Minuten Mittel
26.300
Verschiedene Geräte im WLAN
300.000
Kongresse und Tagungen
635
VPN
Maximale Anzahl gleichzeitiger Verbindungen
Maximale Anzahl von Sessions pro Monat
Maximales Datenvolumen pro Monat
4.400
600.000
60 TB
DNS
Verwaltete Domains
Eingetragene IPv4 Adressen
2.570
294.000
DHCP
Verwaltete Adressen
176.000
IPv6; Geräte mit nativem IPv6
90.600
Netzverantwortliche in Instituten
894
170
Zahlen und Fakten
16.10
Netzkomponenten im MWN
16.10.1
Router
Tabelle 43: Netzkomponenten im MWN: Router
Einsatz
Aktive
Ports
100GE
Aktive
Ports
10GE
Aktive
Ports
1GE
Aktive
Ports FE
Cisco Nexus 7010
Backbone-Router
2
67
275
1
4
Cisco Nexus 7010
RZ-Router
0
163
4
0
3
Cisco Catalyst 6509
Firewall
0
3
26
0
1
Cisco 7206VXR
Anbindung Triesdorf
0
0
2
0
1
Cisco 2911
Anbindung FFB
0
0
2
0
2
Cisco 1921
Standortanbindung
0
0
4
0
20
Cisco 1811/1812
Standortanbindung
0
0
0
40
2
Cisco 1721
Standortanbindung
0
0
0
2
2
Cisco 891
Standortanbindung
0
0
0
4
1
Cisco 1921
Site2Site VPN
0
0
0
4
2
F5 BigIP 8900
Server Load Balancer
0
4
0
0
1
F5 BigIP 3400
Server Load Balancer
0
0
4
0
49
Router gesamt
2
237
317
51
Anzahl
Hersteller/Typ
10
16.10.2
171
Switches
Tabelle 44: Netzkomponenten im MWN: Switches
verfügbare TP-Ports
Anzahl
2
verfügbare Glasfaserports
Hersteller/Typ
HP E8212zl
10/100/1000
10GE
100/1000
10GE
148
-
72
48
329
HP 5412zl / 5406zl
33.623
7
3.931
471
213
HP 4208vl / 4204vl
23.472
-
531
3
154
HP 4108gl / 4104gl
10.321
-
1.790
-
624
13
-
146
137
-
7
-
572
-
33
19
HP E6600-24XG/-24G-4XG
25
HP E6600-48G-4XG
HP 3500yl-24G-PoE+
5
HP 3500yl-48G-PoE+
15
HP 3800-48G / -24G
40
HP E2910al-48G / -24G
1.551
-
9
14
37
HP2900-48G / -24G
1.584
68
-
39
44
HP E2810-48G / -24G
1.437
-
27
-
11
HP3400cl-48G
523
-
5
6
-
13
-
7
2.158
-
26
-
362
-
12
-
6.462
-
112
-
1.031
-
19
-
3.315
-
93
-
HP 6400cl-6XG
3
HP 6410cl-6XG
70
HP 2848 / 2824
13
HP E2620-48 / -24
HP E2610-48 / -48pwr
223
HP E2610-24 / -24pwr
HP E2610-24/12pwr
HP E2615-8-PoE
105
HP E2915-8G-PoE
HP 2650 / HP 2626
94
HP 2626pwr / HP 2600-8pwr
12
HP 2510G-48 / HP 2510G-24
289
-
13
-
1
HP 2520G-48 / -24 /-24PoE
24
-
-
-
4
HP 2530-48/-24, HP25308Gpwr
123
-
-
-
2
HP 2524
50
-
-
-
1
Cisco Nexus7000
-
-
-
288
1.403
Switches gesamt
87.806
101
6.680
1.041
172
Zahlen und Fakten
16.10.3
WLAN-Komponenten
Tabelle 45: Netzkomponenten im MWN: WLAN-Komponenten
Anzahl
339
Hersteller/Typ
Verwendung
Standards
Radios
802.11a/g/n
2
Alcatel-Lucent AP-135
Access Point
2
Alcatel-Lucent
OAW-4650EU
Controller
834
HP MSM 310
Access Point
802.11b/g
1
10
HP MSM 310
Gebäudeanbindung
802.11b/g
1
82
HP MSM 320
Access Point
802.11a/b/g
2
1
HP MSM 320
Gebäudeanbindung
802.11a/b/g
2
440
HP MSM 422
Access Point
802.11a/g/n
2
4
HP MSM 422
Gebäudeanbindung
802.11a/g/n
2
533
HP MSM 460
Access Point
802.11a/g/n
2
37
HP MSM 466
Access Point
802.11a/g/n
2
4
HP MSM 466
Gebäudeanbindung
802.11a/g/n
2
1
HP MSC3200
Controller
6
HP M111
Wireless Client Bridge
2293
WLAN gesamt
2
802.11b/g
1
16.10.4
173
Netz-Server
Tabelle 46: Netzkomponenten: Server
Anzahl
Hersteller/Typ
Verwendung
Betriebssystem
Prozessoren
Hauptspeicher
proprietär
2
24 GB
6
Cisco ASA5540
VPN-Server
proprietär
2
Cisco ASA5585-X
VPN-Server
propritär
1
Cisco 3030E
VPN-Server
proprietär
2
Cisco AS5350XM
Modem/ISDNServer, SIP-Gate- proprietär
way
2
Cisco ASA5580
Firewall
1
Meinberg Lantime M300 NTP-Server
Linux
1
256 MB
1
Meinberg Lantime
NTP-Server
Linux
1
32 MB
14
Dell PowerEdge R610
DNS/DHCPServer
Security-Server
VoIP-Server
Linux
96
268 GB
4
Dell PowerEdge R620
Netzmanagement Linux
32
64
2
Sun Fire X4100
Radius
Linux
4
4 GB
2
Sun Galaxy
VoIP
Linux
2
8 GB
2
Sun Fire X4150
Netzmanagement Linux
8
8 GB
1
Dell GX150
DSL-Server
Linux
1
256 MB
2
Sun Fire X2100
Bibliotheksproxy
Linux
2
2 GB
42
Server gesamt
Mit uns können Sie rechnen!
Boltzmannstraße 1
85748 Garching b. München
Telefon:
Telefax:
+49 89 35831 - 8000
+49 89 35831 - 9700
E-Mail:lrzpost@lrz.de
Internet:www.lrz.de

2014 - LRZ

Transcription

Similar documents

2015 - LRZ

2010 - LRZ

2008 - LRZ

Volltext - Heidelberger Akademie der Wissenschaften

Informationsveranstaltung für Netzverantwortliche im MWN

Ausgabe 08/2015 - Evangelischer Presseverband für Bayern eV

02-03 News/Inhalt

E-Mailversand beim BVB

2006 - LRZ