2012 - LRZ

Transcrição

2012 - LRZ

Leibniz-Rechenzentrum
der Bayerischen Akademie der Wissenschaften
Jahresbericht
2012
Juli 2013
Direktorium:
Prof. Dr. A. Bode (Vorsitzender)
Prof. Dr. H.-J. Bungartz
Prof. Dr. H.-G. Hegering
Prof. Dr. D. Kranzlmüller
LRZ-Bericht 2013-01
Boltzmannstraße 1
85748 Garching b. München
UST-ID-Nr. DE811335517
Telefon:
Telefax:
E-Mail:
Internet:
(089) 35831-8000
(089) 35831-9700
[email protected]
http://www.lrz.de
Öffentliche Verkehrsmittel:
U6: Garching-Forschungszentrum
Jahresbericht 2012 des Leibniz-Rechenzentrums
Vorwort
........................................................................................................................................1
1
Überblick ........................................................................................................................................4
2
Hochleistungsrechnen und Grid....................................................................................................6
2.1
Schwerpunkte der Arbeit und neue Abteilungsstruktur .........................................................6
2.2
Supercomputing .....................................................................................................................6
2.2.1 SuperMUC: Ein neuer Höchstleistungsrechner für Europa.......................................6
2.2.2 Installation und Inbetriebnahme des SuperMUC ......................................................9
2.2.3 Betrieb des Höchstleistungsrechners SuperMUC......................................................9
2.2.4 Benutzerverwaltung für die Hochleistungssysteme.................................................10
2.2.5 Nutzungsstatistik .....................................................................................................10
2.3
Linux-Cluster .......................................................................................................................13
2.3.1 Übersicht über die Cluster-Systeme ........................................................................13
2.3.2 Erweiterung des wassergekühlten Clusters von MEGWare / MAC-Cluster ...........13
2.3.3 Betrieb der Cluster-Systeme ....................................................................................14
2.3.4 Tests und Prototypen ...............................................................................................14
2.3.5 GPGPU-System .......................................................................................................14
2.3.6 Nutzungsstatistiken..................................................................................................14
2.4
Technisch-wissenschaftliche Software.................................................................................16
2.5
Remote Visualisierung .........................................................................................................16
2.6
Projekte im Hochleistungsrechnen .......................................................................................16
2.6.1 Gauss Centre for Supercomputing (GCS) ...............................................................16
2.6.2 KONWIHR ..............................................................................................................18
2.6.3 Partnership for Advanced Computing in Europe: PRACE......................................18
2.6.4 DEEP .......................................................................................................................19
2.6.5 Mont-Blanc ..............................................................................................................19
2.6.6 AutoTune .................................................................................................................20
2.6.7 ScalaLife ..................................................................................................................20
2.6.8 Arbeiten für die Antragstellung REACT .................................................................20
2.6.9 Arbeiten für die Antragstellung FEPA ....................................................................20
2.6.10 PROSPECT e.V.......................................................................................................21
2.6.11 ETP4HPC ................................................................................................................21
2.7
Benutzerunterstützung für Hochleistungssysteme ...............................................................21
2.7.1 Benutzeranfragen .....................................................................................................21
2.7.2 Kurse und Ausbildung .............................................................................................21
2.7.3 Standardisierungs-Aktivitäten im Bereich der parallelen Programmierung ............22
2.7.4 Öffentlichkeitsarbeit ................................................................................................22
2.8
Grid-Dienste .........................................................................................................................23
2.9
Projekte im Grid-Computing ................................................................................................25
2.9.1 Initiative for Globus in Europe (IGE)......................................................................25
2.9.2 D-Grid (Förderung „e-Science und vernetztes Wissensmanagement“ des
BMBF).....................................................................................................................25
2.9.3 EGI-InSPIRE ...........................................................................................................26
2.9.4 VERCE ....................................................................................................................27
2.9.5 MAPPER .................................................................................................................27
2.9.6 DRIHM ....................................................................................................................27
2.9.7 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3) ...................28
2.9.8 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) ....................28
i
Inhaltsverzeichnis
ii
3
4
5
Serverbetrieb ................................................................................................................................ 30
3.1
Linux-Server ........................................................................................................................ 30
3.2
Windows .............................................................................................................................. 31
Datenhaltung ................................................................................................................................ 33
4.1
Überblick Datenhaltung....................................................................................................... 33
4.2
Archiv- und Backupsystem ................................................................................................. 33
4.2.1 Konfiguration.......................................................................................................... 33
4.2.2 Aktivitäten .............................................................................................................. 38
4.2.3 Statistik ................................................................................................................... 40
4.2.4 Plattform für digitale Langzeitarchivierung ........................................................... 42
4.2.5 Projekt Rosetta ........................................................................................................ 43
4.2.6 Projekt Google ........................................................................................................ 44
4.3
Datenbanken und Web-Schnittstellen für den Betrieb der Supercomputer am LRZ........... 46
4.4
Online-Speicher ................................................................................................................... 46
4.4.1 Konfiguration und Entwicklung im Überblick ....................................................... 46
4.4.2 Hochverfügbarer Speicher für virtuelle Server ....................................................... 47
4.4.3 MWN-Speicher ....................................................................................................... 48
4.4.4 Sonstige Aktivitäten................................................................................................ 50
4.5
Daten- und Archivräume ..................................................................................................... 51
Internetdienste ............................................................................................................................. 53
5.1
E-Mail .................................................................................................................................. 53
5.1.1 Ersatz des Dienstes Mailout durch Postout............................................................. 53
5.1.2 Neuer Webmailer Roundcube................................................................................. 53
5.1.3 Spezielle Markierung von Newslettern................................................................... 53
5.1.4 Snowshoe-Spam ..................................................................................................... 54
5.1.5 Virenabwehr ........................................................................................................... 54
5.1.6 SRS – Sender Rewriting Scheme ........................................................................... 54
5.1.7 Einsatz von Puppet mit Subversion ........................................................................ 55
5.1.8 Maximale Mailgröße erhöht ................................................................................... 55
5.1.9 Statistiken ............................................................................................................... 55
5.2
Exchange ............................................................................................................................. 58
5.2.1 Statistik zur Nutzung des Exchange-Dienstes ........................................................ 58
5.3
Sharepoint ............................................................................................................................ 58
5.4
Webhosting .......................................................................................................................... 59
5.4.1 E-Learning .............................................................................................................. 59
5.4.2 TUM-Portal ............................................................................................................ 59
5.4.3 Userweb und Research ........................................................................................... 59
5.4.4 Downloadbereiche zur Softwareverteilung ............................................................ 59
5.4.5 Neuauflage des Webauftritts der BAdW ................................................................ 60
5.4.6 Redesign des Webauftritts des LRZ ....................................................................... 60
5.4.7 Webhosting-Statistik............................................................................................... 60
5.5
Serveradministration und Applikationsunterstützung ......................................................... 62
5.5.1 Serveradministration in BDS .................................................................................. 62
5.6
Streamingserver ................................................................................................................... 63
6
Netzdienste für Institutionen .......................................................................................................64
6.1
Struktur und Betrieb des Münchner Wissenschaftsnetzes (MWN) ......................................64
6.1.1 Struktur des Backbone Netzes .................................................................................69
6.1.2 Router Auswahl .......................................................................................................70
6.1.3 Struktur der Gebäude-Netze im MWN....................................................................71
6.1.4 Struktur des Rechenzentrumsnetzes (RZ-Netz).......................................................72
6.2
Anschluss ans MWN; Wesentliche Änderungen im Netz ....................................................73
6.2.1 Wesentliche Netzänderungen im Jahr 2012 ............................................................73
6.2.2 Netzausbau (Verkabelung); Netzinvestitionsprogramm..........................................74
6.2.3 Anbindung Studentenwohnheime............................................................................75
6.3
DNS und Sicherheit im DNS...............................................................................................77
6.3.1 DNS-Amplifikation-Attacks und offene Resolver ..................................................79
6.4
DHCP ...................................................................................................................................80
6.5
Radius ...................................................................................................................................80
6.6
Netzkomponenten-Beratung .................................................................................................82
6.6.1 Switch-Auswahl ......................................................................................................83
6.7
Telefonie...............................................................................................................................83
6.7.1 Zugang über UMTS .................................................................................................83
6.8
Unterstützende Infrastruktur-Dienste ...................................................................................83
6.8.1 Service Load Balancer (SLB) ..................................................................................83
6.8.2 IPv6 .........................................................................................................................85
6.8.3 Wellenlängenmultiplexer ........................................................................................86
6.8.4 IP-Multiplexer .........................................................................................................87
6.9
Netzmanagement und –monitoring ......................................................................................88
6.9.1 Netzmanagement .....................................................................................................88
6.9.2 Netzdokumentation..................................................................................................89
6.9.3 Überwachung der Dienstqualität .............................................................................95
6.9.4 Evaluation VistaFoundation Kit 4.3 ........................................................................95
6.9.5 Reporting für Netzverantwortliche ..........................................................................96
6.10 Projekte im Bereich Netze ....................................................................................................96
6.10.1 D-Grid GIDS ...........................................................................................................96
6.10.2 SASER.....................................................................................................................98
6.10.3 Customer Network Management (CNM) ................................................................99
6.10.4 Projekte im Rahmen von Géant .............................................................................101
6.10.5 Projekte im Rahmen von Geant3 ...........................................................................103
7
Netzdienste für Endanwender ...................................................................................................106
7.1
Internetzugang und LAN ....................................................................................................106
7.2
WLAN und Eduroam .........................................................................................................108
7.2.1 WLAN-Ausbau im Gebäude der Fakultät Maschinenwesen.................................110
7.2.2 WLAN-Auswahl....................................................................................................111
7.2.3 Eduroam ................................................................................................................111
7.2.4 Unterstützung von Veranstaltungen ......................................................................112
7.3
VPN ....................................................................................................................................113
7.3.1 Technik ..................................................................................................................113
7.3.2 VPN-Software .......................................................................................................113
7.3.3 Telearbeitsplätze von LRZ-Mitarbeitern ...............................................................113
iii
Inhaltsverzeichnis
iv
7.3.4
7.4
8
9
Entwicklung des Datenverkehrs über die VPN-Server......................................... 113
Modem / ISDN .................................................................................................................. 115
Virtual Reality und Visualisierung .......................................................................................... 117
8.1
Sichtbarkeit und Öffentlichkeitsarbeit ............................................................................... 117
8.2
Kooperationen ................................................................................................................... 118
8.3
Forschung und Lehre ......................................................................................................... 118
IT-Service-Management............................................................................................................ 120
9.1
IT-Service-Management: Einführung von ISO/IEC 20000 ............................................... 120
9.1.1 Incident-Management ........................................................................................... 120
9.1.2 Weitere ITSM-Prozesse ........................................................................................ 121
9.1.3 Sonstige Aktivitäten.............................................................................................. 121
9.2
Service-Management-Plattform Action Request System .................................................. 122
9.3
Servicedesk ........................................................................................................................ 122
10 Informationen und Weiterbildung ........................................................................................... 123
10.1 Kurse und Veranstaltungen ............................................................................................... 123
10.1.1 Kursübersicht, Statistik 2012 ................................................................................ 123
10.1.2 Kurse und Ausbildung im Bereich Hochleistungsrechnen ................................... 124
10.2 Vorträge „Schattenseiten des Internet“.............................................................................. 124
10.3 Öffentlichkeitsarbeit .......................................................................................................... 125
11 Software-Bezug und Lizenzen .................................................................................................. 127
11.1 Bundesweiter Rahmenvertrag für Microsoft-Lizenzen ..................................................... 127
11.2 Überregionaler Rahmenvertrag zum Bezug von Beratungs- und
Supportdienstleistungen zu Microsoft-Produkten ............................................................. 127
11.3 Bayernweiter Mietvertrag für Adobe-Lizenzen................................................................. 127
11.4 Vereinfachung der Versorgung mit ESRI-Lizenzen an der TU München ........................ 127
11.5 Vereinfachung der Versorgung mit Mathematica-Lizenzen an der LMU München......... 128
11.6 Weitere laufende Verhandlungen und Planungen ............................................................. 128
11.7 Tagesgeschäft .................................................................................................................... 128
11.7.1 Abläufe und Änderungen bei der Versorgung der Kunden des LRZ ................... 128
11.7.2 Routinemäßige Verlängerung und Ausbau bestehender Verträge ........................ 129
11.7.3 Betrieb von Lizenzservern für Kunden des LRZ .................................................. 129
12 Benutzerverwaltung und Verzeichnisdienste .......................................................................... 130
12.1 Benutzerverwaltung für LRZ-Dienste ............................................................................... 130
12.1.1 Für LRZ-Systeme vergebene Kennungen............................................................. 130
12.1.2 Identity Management und Verzeichnisdienste ...................................................... 131
12.2 CampusLMU und TUMonline .......................................................................................... 135
12.2.1 CampusLMU-Anbindung ..................................................................................... 135
12.2.2 TUMonline-Anbindung ........................................................................................ 135
12.3 MWN Active Directory ..................................................................................................... 136
12.4 DFN-AAI/Shibboleth ........................................................................................................ 137
12.4.1 Entwicklungen im Identity-Provider-Dienstbetrieb ..............................................137
12.4.2 Anpassungen für spezielle Service Provider .........................................................137
13 Dienste mit Sondervereinbarungen...........................................................................................139
13.1 Bibliotheksverbund Bayern ................................................................................................139
13.2 Managed Hosting für hochschulstart.de .............................................................................139
14 IT-Sicherheit ...............................................................................................................................140
14.1 Antivirus .............................................................................................................................140
14.2 WSUS .................................................................................................................................140
14.3 Virtuelle Firewall ...............................................................................................................140
14.4 Sicherheitswerkzeuge und Sicherheitsmanagement ...........................................................141
14.4.1 Secomat .................................................................................................................141
14.4.2 Security Information & Event Management..........................................................143
14.4.3 Nessi ......................................................................................................................144
14.4.4 Nyx ........................................................................................................................144
14.5 Server- und Benutzerzertifizierung nach X.509 .................................................................145
15 Arbeitsplätze ...............................................................................................................................146
15.1 Windows.............................................................................................................................146
15.2 Linux-Mitarbeiter-PCs .......................................................................................................146
15.3 Rechnerpools und Spezialarbeitsplätze ..............................................................................146
16 Interna
....................................................................................................................................149
16.1 Personal ..............................................................................................................................149
16.1.1 Personalausstattung ...............................................................................................149
16.1.2 Personalveränderungen 2012.................................................................................149
16.2 Gebäude und Infrastruktur..................................................................................................149
16.2.1 Gebäudemanagement ............................................................................................149
16.2.2 Energieeffizienz .....................................................................................................150
16.3 Das LRZ als Ausbildungsbetrieb .......................................................................................150
16.4 Dienstleistungskatalog........................................................................................................151
16.5 Management-Tools, Dokumentation und Dienstleistungsbaum ........................................151
16.6 Mitarbeit in Gremien ..........................................................................................................151
16.6.1 Abteilung „Benutzernahe Dienste und Systeme“ ..................................................152
16.6.2 Abteilung „Hochleistungssysteme“ .......................................................................152
16.6.3 Abteilung „Kommunikationsnetze“ ......................................................................153
16.6.4 Abteilung „Zentrale Dienste“ ................................................................................153
16.7 Veranstaltungen am LRZ ...................................................................................................154
16.8 Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen ......................156
16.8.1 Abteilung „Benutzernahe Dienste und Systeme“ ..................................................156
16.8.2 Abteilung „Hochleistungssysteme” .......................................................................157
16.8.3 Abteilung „Kommunikationsnetze“ ......................................................................161
16.8.4 Abteilung „Zentrale Dienste“ ................................................................................162
16.9 Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten.....................................164
16.10 Veröffentlichungen der Mitarbeiter 2012...........................................................................165
v
vi
Inhaltsverzeichnis
16.11 Promotionen und Habilitationen am LRZ ......................................................................... 169
17 Technische Ausstattung............................................................................................................. 170
17.1 Datenspeicher .................................................................................................................... 170
17.2 Rechner und Server ........................................................................................................... 171
17.2.1 Höchstleistungsrechner SuperMUC ..................................................................... 171
17.2.2 Migrationssystem SuperMIG (IBM BladeCenter HX5) ....................................... 172
17.2.3 Hochleistungs-Linux-Systeme .............................................................................. 172
17.2.4 Grid-Rechner ........................................................................................................ 174
17.2.5 Hochleistungs-Graphik-System ............................................................................ 174
17.2.6 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner ...................................... 175
17.3 Netzkomponenten .............................................................................................................. 179
17.3.1 Router ................................................................................................................... 179
17.3.2 Switches ................................................................................................................ 179
17.3.3 WLAN-Komponenten .......................................................................................... 180
17.3.4 Netz-Server ........................................................................................................... 180
Jahresbericht 2012 des Leibniz-Rechenzentrums, Vorwort
1
Vorwort
2012 war ein außergewöhnliches Jahr für das Leibniz-Rechenzentrum der Bayerischen Akademie der
Wissenschaften: unter großer Anteilnahme hochrangiger und internationaler Festgäste, aktueller und
ehemaliger Mitarbeiter, Kunden und Kooperationspartner konnte das LRZ am 20. Juli nicht nur seinen
50. Geburtstag feiern, sondern auch die äußerst erfolgreiche Inbetriebnahme des Höchstleistungsrechners
SuperMUC, leistungsfähigster Rechner in Europa und Platz vier der Welt!
Der vorliegende Jahresbericht dokumentiert wiederum die gestiegene regionale, nationale und internationale Bedeutung des LRZ als Wissenschafts-Rechenzentrum mit vielfältigen Dienstleistungen für Forschung, Lehre und Verwaltung.
Die von allen anerkannte Stellung des LRZ konnte nur erreicht werden, weil die Förderer des LRZ mit
großer Weitsicht nachhaltig die Arbeit dieser einmaligen Einrichtung finanzieren, allen voran die Bayerische Staatsregierung und speziell das Bayerische Staatsministerium für Wissenschaft, Forschung und
Kunst, dem wir zu großem Dank verpflichtet sind.
Den Mitarbeiterinnen und Mitarbeitern des LRZ möchte ich für ihre engagierte Arbeit danken. Mein besonderer Dank gilt aber auch der Bayerischen Akademie der Wissenschaften, den Mitgliedern des Lenkungsausschusses und der Kommission für Informatik, die die Arbeit des LRZ mit konstruktiver Kritik
stets fachkundig unterstützt haben.
Persönlich danke ich insbesondere den Mitgliedern des Direktoriums des LRZ, den Kollegen HansJoachim Bungartz, Dieter Kranzlmüller und Heinz-Gerd Hegering, die ihre große Fachkompetenz in die
Prof. Dr. Karl-Heinz Hoffmann, Präsident der BAdW, Martina Koederitz, Geschäftsführerin IBM
Deutschland GmbH, Bundesministerin Prof. Dr. Annette Schavan, Prof. Dr. Bernd Huber, Präsident der LMU, Staatsminister Dr. Wolfgang Heubisch, Prof. Dr. Wolfgang A. Herrmann, Präsident der TUM, Prof. Dr. Arndt Bode, Vorsitzender des Direktoriums des LRZ, Prof. Dr. HeinzGerd Hegering, Direktoriumsmitglied des LRZ und Prof. Dr. Achim Bachem, Vorstandsvorsitzender des Forschungszentrums Jülich (v.l.n.r.) bei der Feier am 20. Juli 2012
Leitung des LRZ mit eingebracht haben.
Der vorgelegte Jahresbericht geht wieder bewusst über das Zahlenwerk üblicher Jahresberichte hinaus.
Wir versuchen wie in den letzten Jahren, viele unserer Dienste und Geschäftsprozesse zu erklären und
unsere Konventionen und Handlungsweisen zu begründen. Dies soll die Komplexität unserer Aufgaben-
2
Vorwort
stellung und das LRZ als Institution transparenter machen. Das LRZ nimmt aufgrund seiner Größe und
Organisationsform, des Umfangs seines Versorgungsbereiches, der Anzahl seiner Nutzer, Anzahl, Vielfalt und Heterogenität der Systeme, Beteiligung an Entwicklungsprojekten usw. eine deutliche Sonderstellung ein, die auch im Bericht sichtbar wird.
Eine moderne IT-Infrastruktur ist essentiell für die Wettbewerbsfähigkeit der Hochschulen und des Landes, und so muss auch das IT-Kompetenzzentrum fest im Hochschulumfeld verankert sein. Das LeibnizRechenzentrum als das technisch-wissenschaftliche Rechenzentrum für die Münchner Hochschulen wird
sich auch in Zukunft den Anforderungen eines modernen IT-Kompetenzzentrums stellen, und das nicht
nur durch den zuverlässigen Betrieb von IT-Infrastruktur, sondern auch durch aktive Beteiligung an Forschung und Entwicklung in den Bereichen Kommunikationssysteme, IT-Managementprozesse, Computational Science und Grid-Computing. Hierzu zählen auch die Initiativen im Rahmen von ISO/IEC 20000.
Ich danke für die gute Zusammenarbeit mit Ihnen im Jahr 2012 und freue mich auf alle gemeinsamen
Vorhaben im Jahr 2013.
Univ.-Prof. Dr. Arndt Bode
Vorsitzender des Direktoriums
des Leibniz-Rechenzentrums
3
Überblick
4
1 Überblick
Herausragende Ereignisse waren im Jahr 2012 die Verleihung des Deutschen Rechenzentrumspreises
2012 in der Kategorie "Energie- und Ressourceneffiziente Rechenzentren", die Festveranstaltung zum 50jährigen Bestehen der Kommission für Informatik sowie zur Inbetriebnahme des neuen europäischem
Höchstleistungsrechners am 20. Juli 2012 im Beisein von Bundesministerin Annette Schavan und des
bayerischen Wissenschaftsministers Wolfgang Heubisch und die erfolgreiche Installation und Eröffnung
des Zentrums für virtuelle Realität und Visualisierung (V2C).
Abbildung 1
Prof. Dr. Karl-Heinz Hoffmann, Präsident der BAdW, Prof. Dr. Arndt Bode, Vorsitzender des Direktoriums des LRZ, Martina Koederitz, Geschäftsführerin IBM Deutschland
GmbH, Bundesministerin Prof. Dr. Annette Schavan und Staatsminister Dr. Wolfgang
Heubisch (v.l.n.r.) bei der Feier am 20. Juli 2012
Nach der erfolgreichen Inbetriebnahme des SuperMUC (Platz 4 weltweit, Platz 1 in Europa auf der
Top500-Liste vom Juni 2012) sind hier die Aktivitäten zum Ausbau der Stellung des LRZ als ein Europäisches Zentrum für Supercomputing, das seine Dienste eingebettet in GCS und die europäische Infrastruktur PRACE (Partnership for Advanced Computing in Europe) einbringt, zu benennen.
Im Hinblick auf die zukünftige Versorgung mit Höchstleistungsrechnerkapazität haben Bund und Länder
im Jahr 2012 zusätzliche Mittel im Rahmen des Förderprojektes PetaGCS in Höhe von weiteren € 52
Mio. (damit insgesamt € 400 Mio.) für das GCS für Phase 2 zur Verfügung gestellt. Personell ist und war
das LRZ bzw. das Direktorium durch Prof. Hegering als Leiter des GCS e.V. (Verlängerung bis Frühjahr
2013), mit Prof. Bode als Vertreter der Bayerischen Akademie der Wissenschaften im Vorstand von GCS
sowie als Deutscher Vertreter im PRACE Council, als Mitglied des Verwaltungsrates der European Open
File Systems Initiative (EOFS) sowie Gründungmitglied der European Technology Platform for High
Performance Computing ETP4HPC und mit Prof. Kranzlmüller als deutschem Vertreter des NGI-DE in
EGI in nationale und europäische Aktivitäten eingebunden.
5
Weitere herausragende Ereignisse im Jahr 2012 waren:
 Ausbau der Mail-, Groupware- und E-Learning-Dienste für die Münchner Hochschulen, auch bedingt durch den „doppelten“ Studienjahrgang
 Ausbau des Münchner Wissenschaftsnetzes, ebenfalls bedingt durch den „doppelten Studienjahrgang“
 Ausbau der Dienstleistungen in den Bereichen Virtuelle Server, Desktop Management, eLearning
Plattformen und Digitale Langzeitarchivierung
 Professionalisierung verschiedener Dienste (u.a. Sicherheit)
 Weitere Rezentralisierung (Übernahme überregionaler Aufgaben)
 Einwerbung weiterer Drittmittelprojekte; das LRZ ist aktuell an 13 EU- und 2 BMBF-Projekten
beteiligt
 Tag der offenen Tür am 27.10.2012 mit etwa 1.500 Besuchern
 Antrag und erfolgreiche Umsetzung zahlreicher Großgeräteanträge der DFG (insbes. zum Aufbau
eines Visualisierungs- und Virtual-Reality-Zentrums, für ein Hochleistungs-Archiv- und BackupSystem, zum Ausbau des Kommunikationsnetzes und zur Modernisierung der IT-Infrastruktur
des Bibliotheksverbunds Bayern).
Die Planung aller Aktivitäten erfolgt in direkter Absprache mit den Hochschulleitungen von LMU und
TUM.
Der Umfang der Dienstleistungen des LRZ nahm auch im Berichtsjahr weiter zu. Allerdings ist anzumerken, dass die vielfachen Aktivitäten im EU-Umfeld sowie der Inbetriebnahme des SuperMUC und der
Planung der Erweiterung des Höchstleistungsrechners (SuperMUC Phase 2) große personelle Ressourcen
binden, die nur durch einen außerordentlichen persönlichen Einsatz der Mitarbeiter erfolgreich zu erledigen waren. Darüber wird im Folgenden ausführlich berichtet.
Hochleistungsrechnen und Grid
6
2 Hochleistungsrechnen und Grid
2.1
Schwerpunkte der Arbeit und neue Abteilungsstruktur
Der Schwerpunkt der Aktivitäten der Abteilung Hochleistungssysteme bestand in der Installation und
Abnahme des zum Lieferzeitpunkt leistungsfähigsten Rechensystems in Europa SuperMUC und der zu
seinem Betrieb notwendigen Infrastruktur. Diese Aktivitäten gingen einher mit der Umstrukturierung der
Abteilung Hochleistungssysteme, in der es seit Mai statt bisher vier Gruppen nunmehr fünf gibt:
 APP: Applikationsunterstützung
 HPC: HPC Server u. Dienste
 DAT: Datenhaltung
 ITS: IT-Infrastruktur Server und Dienste
 VER: Verteilte Ressourcen
2.2
Supercomputing
2.2.1 SuperMUC: Ein neuer Höchstleistungsrechner für Europa
Nach einer Betriebszeit von fünf Jahren wurde der Höchstleistungsrechner in Bayern (HLRB II), eine SGI
Altix 4700, Ende Oktober 2011 außer Betrieb genommen und durch ein wesentlich leistungsfähigeres
System mit dem Namen SuperMUC ersetzt. Bei SuperMUC handelt es sich um die erste Ausbaustufe
eines Clustersystems der Firma IBM, das aus 19 miteinander gekoppelten Rechnerinseln besteht. Das
System wurde im obersten Stockwerk des erweiterten Rechnerkubus des LRZ installiert. Die für
2014/2015 geplante zweite Installationsstufe wird dann zusätzlich den Platz des bisherigen Rechners im
Bestandsbau einnehmen.
Die Leistungsdaten des neuen Systems sind bereits in der ersten Ausbaustufe imposant: SuperMUC besteht aus 9.400 Rechenknoten mit insgesamt 155.656 Prozessorkernen. Die Spitzenleistung des Systems
beträgt 3,2 Petaflops (drei PetaFlop/s, das sind drei Billiarden Rechenoperationen pro Sekunde oder eine
3 mit 15 Nullen). Darüber hinaus ist der Supercomputer mit über 300 TByte Arbeitsspeicher sowie 12
PByte Hintergrundspeicher ausgestattet. Alle Rechenknoten sind über ein FDR10-Infinibandnetz mit
einer Bisektrionsbandbreite von 35,6 TByte/s untereinander verbunden.
Nach den fast vier Monate dauernden Installationsarbeiten konnte rechtzeitig zur Internationalen Supercomputing Konferenz in Hamburg im Juni 2012 ein LINPACK-Leistungswert von beeindruckenden 2.9
PFlop/s demonstriert werden, womit die Einstufung als viertschnellstes System der Welt und schnellstes
System Europas verbunden war. Auch in der Top500-Liste vom November 2012 lag SuperMUC noch auf
Platz 6.
Während der bisherige Rechner vor allem für Projekte aus Wissenschaft und Forschung innerhalb
Deutschlands genutzt wurde, stellt der neue Rechner auch einen Teil des deutschen Beitrags zur europäischen Höchstleistungsrechner-Infrastruktur innerhalb von PRACE (Partnership for Advanced Computing
in Europe) dar. Der deutsche Beitrag zur PRACE-Infrastruktur wird zusammen mit den beiden anderen
Partnern Jülich und Hochleistungsrechenzentrum Stuttgart (HLRS) vom Gauss-Zentrum für Supercomputing (GCS e.V.) erbracht.
Abbildung 2
7
SuperMUC im Rechnerraum: dieses Bild ist keine Photographie sondern wurde künstlich
auf dem Rechner aus den vorhandenen Geometriedaten berechnet
Architektur des Systems
Bei der Beschaffung des Rechners SuperMUC standen drei Aspekte im Vordergrund: eine breite und
einfache Nutzbarkeit des Systems für verschiedene Wissenschaftsdisziplinen, hohe Zuverlässigkeit sowie
eine möglichst hohe Energieeffizienz. Diese Ziele des LRZ wurden ab Mai 2009 mit Herstellern im Rahmen einer Markterkundung diskutiert. Nach dem europaweiten Teilnahmewettbewerb wurde ab März
2010 in einem Wettbewerblichen Dialog mit vier Firmen intensiv verhandelt und eine umfangreiche Leistungsbeschreibung erstellt, die auch Benchmark-Programme beinhaltete. Die Entscheidung fiel dann im
November 2010 zugunsten von IBM mit dem System X iDataPlex, das auf 64 Bit Intel StandardProzessoren der neuesten Generation basiert. Die wichtigsten Charakteristiken des neuen Rechners werden im Folgenden dargestellt:
Thin Node Insel
Anzahl Inseln
Anzahl Cores
Anzahl Knoten
Prozessor
Peak-Rechenleistung (PFlop/s)
Gesamter Hauptspeicher (TByte)
Gemeinsamer Hauptspeicher pro Knoten (GByte)
Bandbreite zum Hauptspeicher pro Core (GByte/s)
Verbindung innerhalb einer Insel
Verbindungstopologie innerhalb einer Insel
Verbindung zwischen den Inseln
Verbindungstopologie zwischen Inseln
Bisektionsbandbreite des Verbindungsnetzwerkes
Größe und Bandbreite des parallelen Dateisystems
GPFS
Größe und Bandbreite des Home Dateisystems
Stromverbrauch des Systems (MW)
Fat Node Insel
(zugleich Migrationssystem)
18
1
147456
8.200
9216
205
Intel Sandy Bridge-EP
Intel Westmere-EX
3.18
0.078
288
51
32
256
6.4
4.3
FDR10
QDR
Non-blocking
Non-blocking
Fat Tree
Fat Tree
FDR10
Ausgedünnter (4:1) Fat Tree
35.6 TByte/s
10 PByte mit 200 Gbyte/s
1.5 PByte mit 10 GByte/s
<3
Tabelle 1: SuperMUC-Kennzahlen
8
Das Gesamtsystem ist in 19 Compute-Inseln mit jeweils etwa 8.200 Rechenkernen unterteilt. Eine dieser
Inseln ist mit Knoten mit besonders viel Hauptspeicher ausgestattet (Fat-Node Insel mit 205 Rechenknoten). Die hierbei verwendete Prozessortechnologie ist Intel Westmere-EX. Dabei besteht ein Rechenknoten aus 40 Cores, die auf einen gemeinsamen Hauptspeicher von 256 Gigabyte zugreifen. Diese Insel
wurde schon im Jahr 2011 für den Einsatz als Migrationssystem (SuperMIG) vorab geliefert; sie soll nach
der Integration ins Gesamtsystem durch Programme benutzt werden, die extrem viel gemeinsamen
Hauptspeicher benötigen, etwa für Pre- oder Postprocessing. Der Hauptteil des Systems besteht aus Rechenknoten mit deutlich weniger Cores und Hauptspeicher pro Knoten (Thin-Node Inseln mit 16 Cores
und 32 Gigabyte pro Knoten), da bei hochskalierbaren Programmen die Daten über die Knoten verteilt
abgelegt werden. Jede dieser Inseln besteht aus 512 Knoten (zuzüglich Ausfallreserve und Serviceknoten). Ein Knoten besteht aus jeweils zwei 8-Core Sandy Bridge-EP Sockeln, deren Eigenschaften besonders für das Hochleistungsrechnen geeignet sind.
Abbildung 3
Schematischer Aufbau des SuperMUC
Energieeffizienz
Der Energieverbrauch des neuen Rechners von etwa 3 Megawatt unter Volllast, zu dem noch der Aufwand für die Kühlung hinzukommt, hat das LRZ vor hohe finanzielle und technische Probleme gestellt
und entscheidend die Verhandlungen mit den Herstellern geprägt. So wurde beschlossen, bei der Kühlung
des Rechners einen völlig neuen Weg zu beschreiten. Die meisten der Knoten des SuperMUC nutzen eine
Wasserkühlung, die aufgrund hoher Vorlauftemperaturen gleich mehrere Vorteile verbindet: Etwa 10
Prozent Energie werden durch die reine Wasserkühlung gespart, da auf den Knoten weniger bis gar keine
aktiven Lüftungskomponenten mehr benötigt und Leckströme verringert werden. Außerdem werden keine
energieintensiven Kältemaschinen für das Rechenzentrum benötigt, was den Energieverbrauch des Gesamtsystems erheblich reduziert. Die Warmwasserkühlung bringt zudem wertvolle Wärmeenergie zurück,
die sich vielfältig verwenden lässt, etwa zur Gebäudeheizung. Im Vergleich zu konventionellen, kaltluftgekühlten Systemen reduzieren sich die CO2-Bilanz und auch der Lärmpegel im Rechnerraum signifikant. Die Warmwasserkühlung, die die Chips des Systems direkt kühlt, wurde eigens durch IBM entworfen und implementiert. Der SuperMUC kombiniert diese Warmwasserkühlung mit den energieeffizienten
Intel Xeon Prozessoren und einer anwendungsorientiert arbeitenden Systemsoftware, die gemeinsam von
IBM und LRZ weiterentwickelt wird, um den Energieverbrauch weiter zu senken. So wird aufgrund von
Messungen des Energieverbrauchs und der Programmcharakteristiken die Taktung der Prozessoren opti-
9
mal eingestellt, ohne die Rechenleistung zu sehr zu beeinträchtigen. Außerdem werden Prozessoren, die
für einen gewissen Zeitraum nicht benötigt werden, herunter getaktet, bzw. vollständige Knoten in einen
energiesparenden Schlafzustand versetzt. Durch all diese Maßnahmen soll der Gesamt-Energieverbrauch
um 30 bis 40 Prozent gesenkt und ein wesentlicher Beitrag zum Klimaschutz geleistet werden.
Abbildung 4
Rechenknoten mit Warmwasserkühlung.
2.2.2 Installation und Inbetriebnahme des SuperMUC
Die physische Installation des Phase-1 Systems (Rechenknoten, Massenspeicher und Verbindungsnetzwerk) erstreckte sich über die Monate Februar bis April; nach Anlieferung der ersten Compute-Inseln
wurden die ersten LINPACK-basierten Burn-in Tests ab Anfang März vorgenommen. Der für die TOP500 Liste relevante LINPACK-Lauf wurde dann im Laufe des Monats Mai vorbereitet und durchgeführt.
Das Resultat von 2.897 PFlop/s platzierte den Rechner als weltweit schnellstes Intel-basiertes System auf
Rang 4 dieser Liste und damit auch als schnellsten Rechner in Europa.
Ende Juni begann dann – nach einigen weiteren notwendigen Arbeiten, die IBM an der Skalierung der
eingesetzten Systemsoftware vornehmen musste – die Abnahme des Systems, die sich aus der Leistungsprüfung (also der Verifikation der von IBM zugesicherten Rechenleistung für einen definierten Satz von
Benchmark-Programmen), der Funktionsprüfung (also der Verifikation von zugesicherter Funktionalität),
sowie der Zuverlässigkeitsprüfung (also der Betriebsstabilität im normalen Benutzerbetrieb) zusammensetzte. Leistungs- und Funktionsprüfung waren größtenteils bis Mitte August abgeschlossen; danach folgte die Zuverlässigkeitsprüfung im Benutzerbetrieb. Im Anschluss daran wurden noch einige Benchmarks
wiederholt, und noch ausstehende Funktionen nachträglich geprüft.
Die Abnahme des Rechensystems wurde am 11. September erklärt. Die während der Zuverlässigkeitsprüfung gemessene Systemverfügbarkeit betrug 99,23%.
Im Rahmen der Zuverlässigkeitsprüfung wurde noch eine Reihe von nicht betriebsgefährdenden Software-Mängeln festgestellt, die sich erst durch programm-spezifische Nutzungsmuster manifestierten.
Diese Mängel wurden entweder durch die üblichen IBM-seitigen Bereinigungsprozesse zumeist bis Ende
des Jahres behoben oder den Benutzern wurden Workarounds zur Verfügung gestellt.
Ein im Berichtsjahr offener Abnahmepunkt ergab sich im Bereich der Datenhaltung: Für die dem parallelen Dateisystem zugeordnete Storage-Infrastruktur war bereits vorab wegen Liefer-Verzögerungen der
Storage Controller eine Nachlieferung und verzögerte Abnahme vereinbart worden. Die Abnahme des
Hintergrundspeichers konnte aufgrund von Schwierigkeiten bei der Demonstration der vertraglich vereinbarten I/O-Leistung erst im Folgejahr erfolgen.
2.2.3 Betrieb des Höchstleistungsrechners SuperMUC
In der ersten Jahreshälfte stand für SuperMUC-Benutzer nur das Migrationssystem „SuperMIG“ zur Verfügung. Ausgewählte Nutzer konnten ab August Ihre Berechnungen auf dem neuen System durchführen.
Der allgemeine Nutzerbetrieb wurde Mitte September aufgenommen. Ab November hatte sich der Benut-
10
zerbetrieb dann soweit normalisiert, dass eine Abrechnung der des Rechenzeitverbrauchs auf die Kontingente der Benutzer vorgenommen wurde.
Ab September wurden auf dem Rechner dann auch die ersten Projekte von PRACE zugelassen. Dabei
wurde für die Dauer eines Jahres Rechenzeit im Umfang von 200 Millionen Core-Stunden für diese Projekte bereitgestellt, die als deutscher Betrag für das europäische Projekt vorgesehen sind.
Eine Reihe von Stabilitätsproblemen, die sich teilweise bereits während der Zuverlässigkeitsprüfung angedeutet hatten (allerdings dort noch in viel zu geringem Umfang, um deren Bestehen zu gefährden),
verschärften sich im regulären Benutzerbetrieb im Laufe des Spätherbstes zunehmend. Das Problem äußerte sich in erster Linie durch Abstürze und Fehlstarts insbesondere größerer Jobs; hierbei traten eine
Reihe von Signaturen auf (in erster Linie Fehler bei I/O Zugriffen sowie Wegbrechen einzelner Rechenknoten), die sich jedoch erst im Lauf der Zeit auf die wesentlichen Ursachen reduzieren ließen:
 eine im Laufe der Zeit stark zunehmende Anzahl von Defekten bzw. Performance-Verlusten an
Infiniband-Kabeln, bedingt durch überschnelle Alterung der integrierten Transceiver,
 Defekte in der auf dem Verbindungsnetzwerk eingesetzten Managementsoftware, die zum Absturz von ganzen Netz-Segmenten führen konnte,
 Auftreten von gehäuften Latenzen auf der gelieferten Charge von Festplatten, die zu einer deutlichen Verringerung der verfügbaren I/O Bandbreite sowie gelegentlich auch zu Hängern des parallelen Dateisystems führten.
Die Behebung oder wenigstens Beherrschung dieser Stabilitätsprobleme reichte noch bis in den Januar
des Folgejahres; ein wesentlicher Punkt hierbei war die Implementierung eines datenbankgestützten Fehleraufzeichnungsverfahrens, damit eine schnellere Korrelation von Job zu möglichen HardwareProblemen möglich ist, sowie auch als defekt erkannte Knoten möglichst schnell offline zu nehmen zu
können.
Sowohl der Betrieb des Migrationssystems als auch die Inbetriebnahme des SuperMUC haben zu einer
deutlichen Zunahme von Benutzeranfragen geführt. Die Stabilisierung des Benutzerbetriebes und die
Beantwortung von Benutzeranfragen bereite den Gruppen APP und HPC bis zum Jahresende (und darüber hinaus) viel Arbeit und führte in einigen Fällen zu einer zeitweiligen Überlastung der mit der Bearbeitung befassten Mitarbeiter. Zusammenfassend sind folgende Arbeitsschwerpunkte zu nennen:
 Ein- und Ausgabe von Daten über Infiniband auf das parallele Dateisystem (GPFS)
 Die Behebung von Software-Fehlern in den parallelen Schnittstellen
 Die Anbindung und Erweiterung der Archivierungs- und Grid-Infrastrukturen
 Implementierung von skalierbaren Mechanismen zum Budgeting, Accounting und SystemMonitoring
 Implementierung von datenbankgestützten Mechanismen zur Fehlererkennung
 Die Einbindung des von IBM gestellten Support-Personals in die LRZ-Prozesse
Die Implementierung von Maßnahmen zur Einsparung von elektrischer Energie
2.2.4 Benutzerverwaltung für die Hochleistungssysteme
Neben den klassischen Arbeiten der Benutzerverwaltung wie Organisation der Begutachtung der Rechenzeitanträge, Verwaltung der Benutzerkennungen und Rechenzeitabrechnung kamen im Berichtsjahr noch
umfangreiche neue Aufgaben für die Rechenzeitvergaben bei den HPC-Calls von PRACE und GAUSS
hinzu, nämlich Organisation und Vorbereitung dieser Calls, die Abstimmung mit den Partnern sowie die
technische Begutachtung der Projektanträge. Ein weiterer Punkt war die Klärung der Fragen in Zusammenhang mit Embargobestimmungen und der Zulassung von Nutzern aus Nicht-EU-Ländern auf den
Hochleistungsrechnern.
2.2.5 Nutzungsstatistik
Die folgende Tabelle gibt eine Übersicht über die Anzahl der durchgeführten Projekte in den vergangenen
Jahren auf den verschiedenen Höchstleistungsrechnern des LRZ wieder.
Insgesamt haben auf den Rechner 702 Projekt Rechenzeit erhalten, davon sind 465 beendet und 237 noch
aktiv.
Jahr
Rechner
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
HLRB I
HLRB I
HLRB I
HLRB I
HLRB I
HLRB I
HLRB I/HLRB II
HLRB II
HLRB II
HLRB II
HLRB II
HLRB II/SuperMIG
SuperMIG/SuperMUC
Gesamt
11
Projekte
begonnen
65
21
29
14
17
16
64
60
114
81
61
61
92
Projekte
beendet
0*
0*
0*
0*
0*
0*
2
7
47
86
77
h181
62
Projekte
aktiv
65
86
115
129
146
162
224
277
344
339
323
203
237
702
465
237
Tabelle 2: Anzahl der begonnen, beendeten und aktiven Projekte
(* In diesem Jahr wurde noch kein explizites Projektende in der Datenbank gespeichert).
Die Gesamtzeit der abgegebenen Rechenzeit im Jahr 2012 an den Systemen SuperMIG und SuperMUC
ist in der folgenden Tabelle angegeben.
SuperMIC
Core-Std.Jobs
59,7 Mio.
142.800
SuperMUC
Core-Std.Jobs
74,6 Mio.
34.746
Gesamt
Core-Std.Jobs
134,3 Mio.
177.546
Core-Stunden
Tabelle 3: Abgegebene Rechenzeit und Anzahl Jobs an den Höchstleistungssystemen im Jahr 2012
45,0
40,0
35,0
30,0
25,0
20,0
15,0
10,0
5,0
0,0
SuperMUC
SuperMIG
1 2 3 4 5 6 7 8 9 10 11 12
Abbildung 5
Abgegebene Rechenzeit pro Monat für 2012 an SuperMIG und SuperMUC
12
Abbildung 5 gibt die abgegebene Rechenzeit für jeden Monat in Core-Stunden von SuperMIG und von
SuperMUC nach Beendigung der „Friendly User Period“ und Aufnahme des allgemeinen Benutzerbetriebs im November 2012 wieder. Die Rechenzeitabgabe am SuperMIG mit etwa 5 Mio. Core-Stunden
pro Monat entspricht etwa der Leistung des vorherigen Höchstleistungsrechners HLRB II. November
2012 wurde auch das Accounting von Rechenzeit am SuperMUC aktiviert, wobei die Grafik einen ersten
Eindruck über die Zunahme an Rechenleistung am LRZ durch die Verfügbarkeit von SuperMUC vermittelt.
Die Aufteilung der abgegebenen Rechenzeit nach institutioneller Zugehörigkeit ist in der folgenden Tabelle aufgeführt
Institutionskategorie
Universitäten
Helmholtz-Gemeinschaft
Leibniz-Gemeinschaft
Max-Planck-Gesellschaft
Sonstige
PRACE
Deisa
SuperMIG SuperMUC Gesamt
75.2%
27.4%
48.6%
9.8%
17.0%
13.8%
2.4%
16.0%
9.9%
0.7%
16.3%
9.3%
9.2%
5.6%
7.2%
0.9%
9.5%
5.7%
0.0%
8.2%
4.5%
1.7%
0.2%
0.9%
Tabelle 4: Verteilung der abgegebenen Rechenzeit nach Institutionen
Hier wird deutlich, dass der SuperMUC im Jahr 2012 viel stärker für Projekte der Großforschungseinrichtungen und für PRACE benutzt wird als der SuperMIG. Der aktuell hohe Anteil an Rechenzeit für das
LRZ am SuperMUC ist durch Tests und Abnahmebenchmarks bestimmt und wird in den nächsten Monaten deutlich zurückgehen. Die jeweils fünf größten wissenschaftlichen Projekte auf SuperMUC und SuperMIG sind in der folgenden Tabelle aufgeführt. Auch hier wird das unterschiedliche Nutzungsspektrum
deutlich, nämlich dass die Nutzung des SuperMUC von einigen Großprojekten dominiert wird.
Projekt
Title
Principal Investigator
Usage
Average
Core
SuperMUC
pr63po
Chiral Symmetry and topological properties in Lattice
QCD with Wilson twisted mass quarks
Urbach/Rheinische FriedrichsWilhelms Universitaet
15%
1072
h009z
Local Supercluster Simulation
13%
5645
pr86go
pr86ba
pr58fa
Full-f gyrokinetic simulation of edge pedestal in Textor
Electrophysiology - Atomistic modeling
Structure Formation in Models Beyond LambdaCDM
Gottlöber/Leibniz-Institut für
Astrophysik Potsdam (AIP)
Kiviniemi/DEISA PRACE
Tarek/DEISA PRACE
Smith/Bonn
5%
4%
4%
3647
1814
1638
SuperMIG
pr63ce
h0983
h006z
h1142
pr47bu
Ab initio Metadynamics Simulations of Methanol Synthesis over Cu/ZnO catalyst surfaces
Large Scale CFD for Complex Flows
Frenzel/RUB Chemie
5.61%
417
Stemmer/TU München
5.15%
137
Simulation of N_f equal 2+1 lattice QCD at realistic
quark masses
Simulation of the unsteady flow around the Stratospheric Observatory For Infrared Astronomy SOFIA
Numerical Investigation of the Vortical Flowfield about
the VFE-2 Delta-Wing
Schierholz/DESY Zeuthen
4.67%
898
Engfer/Uni Stuttgart
4.55%
147
Hickel/TU München
3.38%
413
Tabelle 5: Die jeweils fünf größten wissenschaftlichen Projekte auf SuperMUC und SuperMIG
13
Auch in der Übersicht der Nutzung durch die einzelnen Fachgebiete wird das unterschiedliche Nutzungsspektrum der beiden Systemteile deutlich. Wie auch auf den bisherigen Höchstleistungsrechnern des
LRZ, dominieren auf dem SuperMIG die Anwendungen aus dem Bereich der Fluiddynamik, gefolgt von
der Astrophysik, die in den letzten Jahren beständig an Rechenzeit zugenommen hat. Die Anwendungen
in der Fluiddynamik stammen zum Großteil aus Universitätsinstituten. Auf dem SuperMUC stellt sich
aber eine ganz andere Verteilung dar. Hier haben zum ersten Mal die Astrowissenschaften die meiste
Rechenzeit verbraucht, da es mittlerweile in diesem Wissenschaftsbereich eine ganze Reihe hochskalierbarer Applikationen gibt.
Abbildung 6
2.3
Anteilige Nutzung von SuperMUC und SuperMIG
Linux-Cluster
2.3.1 Übersicht über die Cluster-Systeme
Das Linux-Cluster am LRZ ist über die Zeit immer weiter erweitert worden und wird als heterogenes
Cluster mit verschiedenen Segmenten betrieben.
Cluster-Segment
Anzahl
Cores
Gesamtleistung
(TFlop/s)
elektr. Leistung
(kW)
Beschaffungsjahr
Serielles Cluster (inklusive housing)
Myrinet 10 GE Systeme
(jetzt
serial)
SGI Altix
ICE
3.680
688
30.0
5.7
210
33
2007/2008/2010
2007
512
5.2
25
2010
MPP Infiniband Cluster
2.848
22.8
45
2011
SGI Altix UltraViolet
2.040
20.0
60
2011
Munich Adv. Comp. Infiniband Cluster
1.904
50.0
30
2012
Gesamt:
11.672
133.7
403
--
Tabelle 6: Übersicht über die wichtigsten Segmente des Linux-Cluster
Aus dieser Übersicht wird ersichtlich, dass für die bis 2007 beschafften Systeme dringend Ersatz beschafft werden muss. Eine entsprechende Antragstellung ist für 2013 geplant.
2.3.2 Erweiterung des wassergekühlten Clusters von MEGWare / MAC-Cluster
Das bereits 2011 gelieferte wassergekühlte Cluster wurde um zwei Racks erweitert, von denen eines in
die bestehende Kühl-Infrastruktur eingebunden wurde, und das andere mit einer über eine Absorptions-
14
kühlmaschine versorgte Luftkühlung versehen ist. Dieses für die Informatik der TU gehouste System
(MAC = Munich Centre of Advanced Computing) ist für Forschungszwecke ausgelegt und daher sehr
heterogen aus unterschiedlichen Prozessor- und Beschleuniger-Architekturen zusammengesetzt.
2.3.3 Betrieb der Cluster-Systeme
Im Laufe des Jahres konnte die schon länger geplante Migration der Cluster-Systeme von dem nicht mehr
längerfristig unterstützten SLES10 auf das neue Betriebssystem-Release, SLES11 durchgeführt werden.
Auf den parallelen Cluster-Segmenten kam hier zunächst SLES11 SP1 zum Einsatz, auf den seriellen nach dessen Verfügbarkeit – SLES11 SP2. Fast alle Cluster-Segmente wurden in die bestehende
SLURM-Infrastruktur integriert. Auch das Job Accounting unter SLURM konnte in Betrieb genommen
werden. Als letzte verbleibende SGE-Insel wird das für LCG gehostete Cluster noch eine Zeitlang mit
Sun Grid Engine (SGE) betrieben. Insgesamt kann der Betrieb des Linux-Clusters als stabil bezeichnet
werden. Es zeigt sich allerdings, dass auf Grund der sehr angespannten Personalsituation und der wachsenden Komplexität der Infrastruktur und des Betriebsmodells die Beseitigung von Störungen zunehmend
längere Zeit in Anspruch nahm. Auch geplante Wartungsmaßnahmen am wassergekühlten Cluster mussten meist über den ursprünglich vorgesehenen Zeitrahmen hinaus ausgedehnt werden.
2.3.4 Tests und Prototypen
Das LRZ wurde bereits 2010 als eines von weltweit 4 Zentren ausgewählt, um die neue Intel MIC
(„Many Integrated Core“) Architektur zu evaluieren. Seitdem wurden dem LRZ verschiedene Prototypen
dieser Architektur, wie „Knights Ferry“ und „Knights Corner“ (kürzlich umbenannt in „Intel Xeon Phi“),
von Intel zur Verfügung gestellt. Seitens des LRZ lag das Schwergewicht bei der Untersuchung mehrerer
Programmiermodelle hinsichtlich ihrer Eignung für die MIC Architektur. Hierbei wurden innerhalb des
KONWIHR-Projektes verschiedene Benchmarks und Applikationen auf MIC portiert. Während eines von
IBM und Intel veranstalteten Workshops in Montpellier wurde im September 2012 über die am LRZ gewonnenen Erfahrungen referiert. Diese fließen derzeit in den im Rahmen von PRACE erstellten Best
Practice Guide für die Intel MIC Architektur ein.
Eine erste Fassung ist unter http://weinberg.userweb.mwn.de/Best-Practice-Guide-Intel-MIC/BestPractice-Guide-Intel-MIC.pdf verfügbar.
2.3.5 GPGPU-System
Als PRACE-Prototyp für ein wassergekühltes GPU-beschleunigtes Cluster war vorgesehen, ein bereits
früher von der russischen Firma T-Platforms geliefertes System von Luftkühlung auf Wasserkühlung
umzustellen; auf Grund von konzeptionellen Problemen konnte diese Umstellung jedoch im Berichtszeitraum nicht fertiggestellt werden. Das System besteht aus vier Intel-Westmere basierten Rechenknoten mit
jeweils zwei NVidia Fermi Beschleunigerkarten.
2.3.6 Nutzungsstatistiken
Die Nutzung der unterschiedlichen Segmente des Linux-Cluster ist in Abbildung 7 dargestellt. Aufgrund
der sehr angespannten Personalsituation konnte die Abrechnung der abgegebenen Rechenzeit erst ab Juni
2012 und für den seriellen Teil sogar erst ab November 2012 realisiert werden.
Die Nachfrage nach Rechenzeit am Linux-Cluster übersteigt weiterhin die zur Verfügung stehenden Resourcen. Entsprechend lang sind die Wartezeiten bis ein Job zur Ausführung kommen kann (siehe Abbildung 8). Auch hier wird deutlich, dass dringend eine Erweiterung für den seriellen Teil des Clusters beschafft werden muss. Die SGI Altix UltaViolet Systeme sind wegen ihres großen Hauptspeichers eine
begehrte Ressource mit ebenfalls mit sehr langen Wartezeiten.
Auch wenn nicht für das vollständige Jahr 2012 Daten vorliegen, so lässt sich doch aus dem Vergleich
mit den vergangenen Jahren feststellen, dass die anteilige Nutzung des Linux-Clusters durch Hochschulen
außerhalb Münchens in den vergangenen Jahren weiter zurückgegangen ist. Die Nutzung wird nun durch
die beiden großen Münchner Universitäten dominiert. Dies ist vor allem auf den Ausbau der LinuxKapazitäten in Erlangen zurückzuführen.
Abbildung 7
Abbildung 8
15
Nutzung des Linux-Cluster (ab Juni bzw. November 2012 für seriellen Teil)
Durchschnittliche Wartezeit bis zur Jobausführung auf den verschiedenen Segmenten des
Clusters
16
Institution/Fachgebiet
Bayerische Akademie der Wissenschaften
Bayerische Hochschulen und Fachhochschulen soweit nicht gesondert erfasst
Hochschule München
Ludwig-Maximilians-Universität München
Biologie
Chemie / Pharmazie
Geowissenschaften
Mathematik / Informatik
Medizin
Physik
Nutzer am Höchstleistungsrechner Bayern
Öffentlich-Rechtliche und Gemeinnützige Körperschaften
Technische Universität München
Bauingenieur- und Vermessungswesen
Chemie / Pharmazie
Elektrotechnik und Informationstechnik
Maschinenwesen
Mathematik / Informatik
Physik
Sonstige
Wissenschaftszentrum Weihenstephan
Zentralinstitute / Verwaltung
Gesamtergebnis
Core-h
20.677
482.644
12.583
4.238.034
6.806
600.157
2.189.038
120.799
140.154
1.181.082
5.456
7.068
3.597.242
54.787
833.425
73.598
1.996.396
276.255
128.286
1.183
231.842
1.469
8.363.705
Jobs
1.862
6.927
497
170.912
477
350
2.481
9.886
2.887
154.831
3.284
7
36.057
10.839
11.438
1.849
4.200
3.525
3.822
179
145
60
219.546
Tabelle 7: Nutzung des Linux-Clusters im November und Dezember 2012
nach Institution und Fachgebiet
2.4
Technisch-wissenschaftliche Software
Die Überarbeitung des Software-Portfolios, die durch den Umstieg auf neue Betriebssoftware und
Scheduling-Systeme erforderlich geworden war, konnte im Verlauf des Jahres im Wesentlichen abgeschlossen werden. Im Software-Portfolio erfolgten Aktualisierungen und Erweiterungen. Aus dem Bereich der Quantenchemie sind neue Releases von NWChem, Quantum-Espresso, CPMD, CP2K,
GROMACS, NAMD und Molpro sowie zusätzliche Pakete wie Abinit, Desmond oder Schrödinger zu
nennen.
2.5
Remote Visualisierung
Für die Benutzer des Linux-Clusters standen während des gesamten Jahres drei dedizierte RemoteVisualisierungs-Server zur Verfügung (GVS2, GVS3 und GVS4). Aus Effizienzgründen wurde die Systemadministration der Remote-Visualisierungs-Server an die Firma MEGWare vergeben, die ein Upgrade
auf SLES 11 SP1, die automatisierte Installation per xCAT, sowie die Integration der Maschinen in das
neue Batch-Queueing System SLURM durchführte. Die Systeme sind durch die Benutzer des LinuxClusters nach wie vor gut ausgelastet.
Von einigen Benutzern von SuperMIG und SuperMUC wurde eine Möglichkeit zur RemoteVisualisierung nachgefragt. Aufgrund fehlender Investitionsmittel und Personalknappheit kann ein solcher Service für SuperMIG und SuperMUC aber leider derzeit nicht angeboten werden.
2.6
Projekte im Hochleistungsrechnen
2.6.1 Gauss Centre for Supercomputing (GCS)
Ziele
Mit der Gründung des Gauss Centre for Supercomputing (http://www.gauss-centre.eu) im Jahr 2007
durch die Kooperation der drei Bundeshöchstleistungsrechenzentren in Jülich, Garching und Stuttgart
wurde der Grundstein für die optimale Unterstützung der Wissenschaft, Wirtschaft und Politik durch
computergestützte Simulation der obersten Leistungsklasse (Tier-0) gelegt. Durch das Projekt PetaGCS
17
konnte das Gauss Centre for Supercomputing (GCS) die leistungsfähigste nationale Infrastruktur für Supercomputing in Europa aufbauen. Darüber hinaus hat GCS den organisatorischen Rahmen dafür geschaffen, dass Wissenschaftler und Forscher nicht mehr aufgrund regionaler oder institutioneller Strukturen,
sondern aufgrund fachlicher Kriterien das für ihre Bedürfnisse am besten geeignete SupercomputerZentrum für ihre Anwendung wählen können. Es wurde ein gemeinsames Zugangsverfahren entwickelt
und implementiert, das nach abgestimmten Regeln und ausschließlich wissenschaftlichen Kriterien in
einem peer-review Verfahren den einheitlichen und fairen Zugang sicherstellt. Die hohe Attraktivität und
der hohe Bedarf zeigen sich in der konstant 3-4 fachen Überzeichnung der ausgeschriebenen Rechenzeit
(Verhältnis von beantragter zu verfügbarer Rechenzeit). In Summe werden jährlich etwa 200 herausragende Projekte mit Rechenzeitvolumen auf GCS-Systemen gefördert. Die bereits jetzt erzielten wissenschaftlichen Ergebnisse zeigen deutlich die Wichtigkeit der Verfügbarkeit dieser Forschungseinrichtung
für Deutschland.
Weiterentwicklung
Die gemeinsamen Arbeiten im Jahr 2012 bestanden vor allem in der Erstellung des Strategiepapiers
„Weiterentwicklung des Gauss Centre for Supercomputing 2016 – 2020“.
Aus der Ausrichtung des GCS als eine Einrichtung für High Performance Computing sowie wichtigen
wissenschaftlichen und gesellschaftlichen Herausforderungen wurden folgende wesentliche Zieldimensionen für die zukünftige Entwicklung des GCS abgeleitet:
 Wissenschaftliche Exzellenz,
 HPC-Technologie,
 Anwendungsunterstützung, Brückenfunktion und Vernetzung,
 Aus- und Weiterbildung,
 Wettbewerb in Wirtschaft und Industrie,
 Gesellschaft / Politikberatung
Thematisch werden sich die Partner im Gauss Centre for Supercomputing zukünftig durch eigene Forschung auf folgende Gebiete konzentrieren und dabei neue Akzente im Hochleistungsrechnen setzen.
 Energie
 Mobilität
 Gesundheit
 Umwelt
Gemeinsames Rechenzeitvergabeverfahren
Der Zugang zu den Systemen wurde vor der Gründung von GCS in unabhängigen Verfahren durch die
jeweiligen Vergabegremien der einzelnen Zentren geregelt. Dies war nicht mehr ausreichend, weil nicht
garantiert werden konnte, dass Wissenschaftlern ein vergleichbarer Zugang zu allen GCS-Systemen möglich ist. Im Rahmen des Projektes wurde deshalb ein gemeinsames Zugangsverfahren entwickelt und implementiert, das nach einheitlichen Regeln und ausschließlich wissenschaftlichen Kriterien in einem peerreview Verfahren den einheitlichen und fairen Zugang sicherstellt. Es wurden dabei verschiedene Klassen
von Projektgrößen definiert, damit wissenschaftlich exzellente Projekte, die viel Rechenzeit benötigen,
besonders gefördert werden können. So wird zweimal jährlich ein nationaler Call für sogenannte „Large
Scale-Projekte“ veröffentlicht, die mindestens 2% der Leistung des Supercomputers über eine Laufzeit
von 12 Monaten benötigen.
GCS Lenkungsausschuss
Der gesamte Prozess der Rechenzeitvergabe wird durch den neu gegründeten gemeinsamen GCSLenkungsausschuss gesteuert und überwacht. Mitglieder des gemeinsamen GCS-Lenkungsausschusses
sind Vertreter der wissenschaftlichen Vergabegremien der GCS-Zentren. So wird die Kohärenz mit den
lokalen Vergabeverfahren sichergestellt.
Gemeinsames Ausbildungs- und Schulungsprogramm
Innerhalb von Gauss wird ein umfangreiches Ausbildungs- und Trainingsprogramm koordiniert
(http://www.gauss-centre.eu/events/). Viele der Kurse und damit auch diejenigen vom LRZ werden auch
auf europäischer Ebene innerhalb der PRACE Advanced Training Centers (PATC,
http://www.training.prace-ri.eu) angeboten.
18
2.6.2 KONWIHR
Im Rahmen des Kompetenznetzwerkes für Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR)
wird am LRZ und RRZE Erlangen das Projekt „OMI4papps: Optimierung, Modellierung und Implementierung hoch skalierbarer Anwendungen“ seit September 2008 durch das Bayerische Staatsministerium
für Wissenschaft, Forschung und Kunst gefördert.
Die Evaluierung neuer Programmiersprachen und –paradigmen insbesondere für Akzeleratoren steht seit
Beginn dieses KONWIHR-Projektes neben der synthetischen Applikationsmodellierung im Zentrum der
Arbeiten am LRZ. Wurden in der Anfangsphase des Projektes 2008 noch Cell-basierte Systeme untersucht, so konzentrierten sich die weiteren Arbeiten auf GPGPU-basierte Systeme und zunehmend auf
Intels neue MIC-Architektur. Im Bereich der GPU-Programmierung wurde insbesondere die Programmierung mit NVIDIA CUDA, Pragma-basierten Programmiermethoden wie HMPP (Hybrid Multicore Parallel Programming Workbench der französischen Firma CAPS), PGI Accelerator Compiler, sowie mit Bibliotheken wie CUBLAS, CUFFT, cuSPARSE und der Sprache OpenCL näher untersucht.
Die Intel MIC-Architektur ist als Kandidat für einen Teil der zweiten Ausbaustufe des SuperMUC (20142016) am LRZ von besonderem Interesse. Im Rahmen der Portierung mathematischer Kernel und ausgewählter Benchmarks der SuperMUC Benchmark-Suite auf Intel Xeon Phi Coprozessoren wurden diverse
Programmiermodelle für die MIC-Architektur evaluiert.
Verglichen wurden native Implementierungen mit OpenMP, MKL und Intrinsics, die direkt auf dem Coprozessor gestartet werden mit Implementierungen mit Offload Pragmas, die auf dem Host gestartet werden und rechenintensive Teile des Programms auf den Coprozessor auslagern. Auch die verschiedenen
Modi der MKL Bibliothek (native mode, compiler assisted offload und automatic offload) wurden detailliert getestet. Mit der Portierung von Applikationen wie SEISSOL oder BQCD konnten erste Erfahrungen
mit der MPI-Programmierung und den unterschiedlichen Ausführungsmodi (MPI Prozesse nur auf dem
Coprozessor, auf Coprozessor und Host etc.) gewonnen werden.
Das dabei gewonnene Knowhow fließt derzeit in den im Rahmen von PRACE federführend vom LRZ
erstellten Best Practice Guide für die Intel MIC Architektur ein.
Durch die Ressourcen aus KONWIHR konnte auch das Kursangebot des LRZ und RRZE erneut erweitert
werden.
Folgendes KONWIHR Projekt wurde vom LRZ unterstützt:
 GeoPF: Geophysik für PetaFlop Rechner: Projektleiter: Prof. Dr. Heiner Igel, Department für
Geo- und Umweltwissenschaften, Ludwig-Maximilians-Universität München, Projektlaufzeit:
September 2008 – voraussichtlich August 2013
Im Rahmen der KONWIHR Software Initiative wurden am LRZ folgende Projekte betreut:


Resamplingbasierte Modellierung und Evaluation bei Genexpressionsdaten,
Institut für medizinische Informationsverarbeitung, Biometrie und Epidemiologie der LudwigMaximilians-Universität München und LRZ, Projektlaufzeit: November 2011 - November 2012
Tuning a cosmo Gadget for SuperMUC, Universitäts-Sternwarte München (USM) und LRZ,
Projektlaufzeit: Dezember 2012 - Juni 2013
2.6.3 Partnership for Advanced Computing in Europe: PRACE
PRACE ist ein europäisches Projekt mit 25 Partnerländern. Das Ziel von PRACE ist die Entwicklung
einer europäischen Höchstleistungsrechner-Infrastruktur. Das LRZ war das ganze Berichtsjahr federführend in den beiden Projekten PRACE First Implementation Phase Projekt (PRACE-1IP) und Second Implementation Phase Projekt (PRACE-2IP) involviert. Seit seinem Start im September ist das LRZ auch an
dem Third Implementation Phase Projekt (PRACE-3IP) beteiligt. In PRACE-1IP und PRACE-2IP leitet
das LRZ das Arbeitspaket zum Thema Prototypen für neue Technologien, und in PRACE-2IP zusätzlich
auch die Säule „Technology & Industry“.
Im Softwarebereich koordinierte das LRZ im Rahmen von PRACE-1IP die Evaluierung neuer Programmiersprachen und beobachtete insbesondere die Entwicklung höherer Programmiersprachen für den Einsatz von Beschleunigern wie GPGPUs oder Intel Xeon Phi Coprozessoren. Hierbei wurden die Ergebnis-
19
se der Evaluierung der Programmiersprache Intel Array Building Blocks in einem PRACE Whitepaper
publiziert. In PRACE-2IP ist das LRZ ferner federführend an der Erstellung eines Best Practice Guides
für SuperMUC beteiligt. Im Rahmen von PRACE-3IP koordiniert das LRZ die Erstellung eines Best
Practice Guides für die neue Intel MIC-Architektur und kooperiert hierbei mit Partnern in Bulgarien,
Finnland und Schweden.
Im Bereich HPC-Hardware war das LRZ über den gesamten Berichtszeitraum für die Koordination und
Auswertung der PRACE-Prototyp Aktivitäten im Bereich „Energy-to-Solution“ federführend verantwortlich. Diese Untersuchungen dienen der Evaluierung des Energieverbrauchs von HPC-Systemen und Infrastruktur, bzw. der Untersuchung von potentiellen Einsparungsmöglichkeiten durch neue Prozessortechnologien (GPUs, FPGAs & ARM) und innovativer Rechenzentrums-Infrastruktur. Das LRZ kooperiert hierfür mit Partnern in Barcelona (ARM/GPU), Poznan/Posen (GPU), Linz (FPGA) und Stockholm
(ARM/DSP). Am LRZ wird die Möglichkeit untersucht, mit Hilfe von Warmwasserkühlung und „Trigeneration“ (Kraft-Wärme-Kälte-Kopplung), den für den Betrieb der Infrastruktur und der Rechner notwendigen Energiebedarf zu minimieren (z.B. durch das Ausnutzen „freier Kühlung“) und andererseits die
Rechnerabwärme zur Gebäudeheizung und Kühlung wiederzuverwenden (z.B. mit Hilfe von Adsorbtionskältemaschinen). Zur Messung des Energieverbrauchs wurde die „PRACE energy benchmark suite“
definiert, welche - im Vergleich zur Green500 - Aussagen für verschieden wissenschaftliche Anwendungen erlaubt.
Die im Rahmen des 4. und 5. „PRACE Access Call“ akzeptierten Projekte wurden erfolgreich betreut.
Das LRZ unterstützte dabei Projekte aus folgenden drei verschiedenen wissenschaftlichen Gebieten:
•
Chemistry and Materials
•
Astrophysics
•
Engineering and Energy
Diese insgesamt 10 Projekte stammen aus 7 Ländern und nutzen die Infrastruktur des SuperMUC am
LRZ im Rahmen von PRACE mit insgesamt 200 Millionen CPU-Stunden.
2.6.4 DEEP
DEEP ist ein von der Europäischen Kommission gefördertes und vom Forschungszentrum Jülich geleitetes Exascale-Projekt mit dem Ziel, eine neuartige 'Cluster Booster Architektur' zu entwickeln. Ein wichtiges Element dieser Architektur sind die kürzlich veröffentlichten XEON Phi Prozessoren von Intel, welche speziell für das Parallelrechnen ausgelegt sind und über 60 Rechenkerne auf einem Chip vereinen.
Die Kommunikation zwischen diesen Prozessoren übernimmt ein neuartiges Verbindungsnetz, welches
an der Universität Heidelberg entwickelt wurde.
Seit dem Projektstart im Dezember 2011 leitet das Leibniz-Rechenzentrum die Öffentlichkeitsarbeit des
Projektes und konnte durch seine Expertise im Bereich des energieeffizienten Höchstleistungsrechnens
die Hardwareentwicklung maßgeblich beeinflussen. So wird das finale DEEP System, von dem übrigens
auch ein kleinerer Teil im kommenden Jahr am Leibniz-Rechenzentrum in Betrieb geht, über umfassende
Überwachungsmöglichkeiten zur Erfassung und Optimierung des Energieverbrauchs verfügen. Die Fortschritte und Zwischenergebnisse der Projektarbeit, welche zu großem Teil auch unmittelbar zur Optimierung des Betriebs am Leibniz-Rechenzentrum beitragen konnten, wurden in mehreren Projektberichten
dokumentiert.
2.6.5 Mont-Blanc
Mont-Blanc ist ein von der Europäischen Kommission gefördertes Exascale-Projekt, dessen Ziel es ist,
auf Basis der ARM-Prozessorarchitektur eine neue, besonders energieeffiziente Systemarchitektur für
zukünftige Hochleistungsrechner zu entwickeln. Das Projekt startete im Oktober 2011 unter der Leitung
des Barcelona Supercomputing Center.
Im ersten Projektjahr konnte durch das Leibniz-Rechenzentrum bereits eine wissenschaftliche Anwendung aus dem Bereich der Quantenchromodynamik auf einem Vorläufer des finalen Mont-Blanc-Systems
zur Ausführung gebracht werden. Zudem konnte, ähnlich wie im DEEP Projekt, in enger Absprache mit
den an der Hardwareentwicklung beteiligten Firmen ein Konzept zum energieeffizienten Betrieb des Systems entwickelt werden.
20
Mit der Durchführung der beiden Exascale Projekte DEEP und Mont-Blanc sind am LeibnizRechenzentrum derzeit mehr als 7 wissenschaftliche Mitarbeiter beauftragt.
2.6.6 AutoTune
Das LRZ ist Projektpartner innerhalb des FP7-Projektes „Automatic Online Tuning“ (AutoTune). Das seit
Oktober 2011 durch die EU für drei Jahre geförderte Projekt wird von der TUM koordiniert und hat die
automatische Optimierung von Applikationen im HPC-Umfeld bezüglich Performancesteigerung und
Energieeffizienz zum Ziel. IBM unterstützt das LRZ bei der Realisierung der Ziele auf dem neuen LRZHöchstleistungsrechner SuperMUC. In der ersten Phase des Projektes entwickelte das LRZ verschiedene
Modelle für eine energieeffiziente Nutzung von SuperMUC. Die Modelle basieren auf der Regelung der
CPU-Frequenz in Abhängigkeit verschiedener Frequenz-Parameter (CPU-Governor und TaktfrequenzBereich) sowie der Berücksichtigung des Laufzeitverhaltens verschiedener paralleler Applikationen. Für
die praktische Umsetzung der Modelle wurde eine Energie-Optimierungs-Bibliothek entwickelt, die eine
einfache Instrumentierung des Programmcodes hinsichtlich Messung der Energie und Performance sowie
des Setzens der Frequenzparameter auf CPU-Ebene erlaubt. Sie bildet die Grundlage für die momentan
anstehende Implementation von Energie-Plugins für Periscope, die Teil des Periscope-Tool-Framework
(PTF) von AutoTune bilden.
2.6.7 ScalaLife
Das EU-Projekt ScalaLife (Scalable Software Services for Life Science), bei dem das LRZ die Leitung
eines Workpackages übernommen hat, soll die Grundlage für die e-Infrastruktur im Bereich Life Science
in der EU bilden. Das LRZ hat in diesem Rahmen eine Benchmark- und Validierungssuite entwickelt, die
es Hochleistungsrechenzentren erlaubt, automatisierte Performanceanalysen durchzuführen. Von Anwendern wurden Inputdaten für Tests und Benchmarks zur Verfügung gestellt. Das Projekt hat noch eine
Laufzeit bis September 2013. Im Herbst 2012 wurde das Projekt von der EU positiv begutachtet.
2.6.8 Arbeiten für die Antragstellung REACT
Im Rahmen des zehnten ICT-calls „FP7-ICT-2013.12.1“ hat das LRZ an einen Projektantrag „ResourceAware Dynamic Application Tuning“ (REACT) mitgewirkt. Neben dem LRZ sind die Technische Universität München, die Universität Wien, die Universitat Autònoma de Barcelona und die National University of Irland, Galway sowie CAPS Enterprise an dem Projektantrag beteiligt. REACT soll die Arbeiten
des FP7-Projektes AutoTune fortsetzen bzw. ergänzen, indem das in AutoTune realisierte Periscope Tuning Framework (PTF) für massiv parallele Applikationen weiterentwickelt werden soll. Es soll das innerhalb des PTF realisierte statische Tuning bezüglich Performance und Energieersparnis dynamisch und
in Abhängigkeit aktuell bereitstehender System-Ressourcen erfolgen. Über den Antrag wird im Jahr 2013
entschieden.
2.6.9 Arbeiten für die Antragstellung FEPA
Innerhalb des dritten BMBF-Call „HPC-Software für skalierbare Parallelrechner“ hat das LRZ mit dem
Regionales Rechenzentrums Erlangen (RRZE) und mit dem Industriepartner NEC Deutschland GmbH
die Projektskizze „Ein flexibles Framework zur Energie- und Performanceanalyse hochparalleler Applikationen im Rechenzentrum“ (FEPA) eingereicht. Das Ziel von FEPA ist die Realisierung einer Überwachungssoftware zur systematischen Effizienzanalyse von Applikationen in Abhängigkeit des zu Grunde
liegenden HPC-Systems. Neben der gezielten Optimierung bezüglich Performance und Energieverbrauch
von kritischen Applikationen sollen im Projekt Erkenntnisse gewonnen werden, die eine Senkung des
Energieverbrauchs durch angepasste Ausführungs-Modalitäten (Frequenzanpassung, Nutzung weniger
Cores/Sockel, etc.) bei vertretbaren Laufzeit-Zugeständnissen ermöglichen. Für das LRZ würde dabei
eine Projektstelle geschaffen, mit der u .a. das im LRZ produktiv eingesetzte Monitoring-Tool „PerSyst“
weiterentwickelt werden könnte. „PerSyst“ wurde während des BMBF-Projektes ISAR entwickelt, welches 2011 erfolgreich abgeschlossenen wurde. Über den Antrag wird im Jahr 2013 entschieden werden.
21
2.6.10 PROSPECT e.V.
Das LRZ ist gemeinsam mit dem FZ Jülich und dem Barcelona Supercomputing Center Gründungsmitglied von PROSEPCT e.V. Der Fokus der Arbeiten lag auch 2012 auf den Themen „European OFS“ und
„European Technology Platform (ETP) for HPC“.
2.6.11 ETP4HPC
Die European Technology Platform for High Performance Computing (ETP4HPC) wurde nach intensiven
Abstimmungsgesprächen mit anderen europäischen HPC-Akteuren im Juni 2012 als niederländischer
Verein mit Büros in Barcelona, Bologna, München und Paris gegründet. Ziel der ETP4HPC ist es, mit
Hilfe eines noch auszuarbeitenden Forschungs- und Entwicklungsprogrammes sowohl die Anwendung
als auch die Herstellung von HPC-Technologien in Europa zu fördern. Das LRZ ist ein Gründungsmitglied und im Lenkungsausschuss mit einer Stimme vertreten.
2.7
Benutzerunterstützung für Hochleistungssysteme
2.7.1 Benutzeranfragen
Die in den vergangenen Jahren deutlich gestiegene Anzahl von Nutzern und der große Job-Durchsatz an
den Höchstleistungssystemen und am Linux-Cluster haben zu einer kontinuierlichen Steigerung von Supportanfragen geführt, die nur mittels des Troubleticket-System kontrolliert abgearbeitet werden können
(siehe Abbildung 9). Diese Möglichkeit der Kontaktaufnahme wurde von den Benutzern sehr gut angenommen und hat die Kontaktaufnahme via E-Mail oder Telefon fast völlig ersetzt. Die leichte Benutzung
des Servicedesk-Portals “verleitet“ leider manche Benutzer dazu, einfache Fragen direkt in das System
einzustellen, ohne vorher die Dokumentation oder die aktuellen Meldungen des LRZ gelesen zu haben.
1400
1166
1200
1000
800
600
838
574
625
2008
2009
934
400
200
0
Abbildung 9
2010
2011
2012
Entwicklung der Anzahl der Supportanfragen im Bereich Hochleistungsrechnen
2.7.2 Kurse und Ausbildung
Der hohe Stand des Aus- und Weiterbildungsangebots mit den etablierten Kursen zu Programmiersprachen und Programmentwicklung, Parallelisierung und Optimierung, Fluid-Dynamik sowie Life-Sciences
und Visualisierung wurde gehalten. Darüber hinaus wurden das erste Mal eine Reihe von Kursen im
PRACE Advanced Training Centre (PATC) Programm angeboten, in dem die drei Gauß-Zentren partizipieren.
Neben dem traditionellen, halbjährlich stattfindenden Workshop zum parallelen Programmieren fanden
auch ein einwöchiger Fortran-Kurs sowie mehrere eintägige Einführungen in Tools zur parallelen Performance-Analyse statt.
Als PATC-Kurse fanden statt: Eine einwöchige Veranstaltung zur Programmierung und Optimierung am
neuen Supercomputer des LRZ in Zusammenarbeit mit den Lieferfirmen IBM und Intel, ein einwöchiger
22
Workshop zu fortgeschrittenen HPC Themen, sowie ein einwöchiger Kurs zu fortgeschrittenen Fortran
Themen.
Die Aktivitäten zu parallelen Programmiersprachen (PGAS) wurden mit einem Tutorial auf der Supercomputing Conference in Salt Lake City fortgeführt.
2.7.3 Standardisierungs-Aktivitäten im Bereich der parallelen Programmierung
Die technische Spezifikation ISO/IEC TS29113, die als Erweiterung des Fortran-Standards zusätzliche
Interoperabilität mit C definiert, hat ihre Abstimmung erfolgreich bestanden und ist damit veröffentlichungsreif. Diese Spezifikation ist eine wesentliche Grundlage für die Fortran-spezifischen Neuerungen
im ebenfalls veröffentlichten MPI-3 Standard, der darüber hinaus signifikante Erweiterungen für das parallele Programmieren bereitstellt. Im Bereich der PGAS-Funktionalität wurde darüber hinaus vom Standardisierungskomitee die Arbeit an zusätzlicher in Fortran integrierter paralleler Semantik in Angriff
genommen, die für eine bessere Skalierbarkeit von Programmieraufwand und erzielbarer Rechenleistung
ausgelegt ist.
Als Vertreter der deutschen Delegation in der internationalen Standardisierungskommission
JTC1/SC22/WG5 für die Programmiersprache Fortran wirkte und wirkt der LRZ-Mitarbeiter Dr. Reinhold Bader an der Erstellung der vorgenannten Technischen Spezifikationen mit; er hat darüber hinaus
auch bei der Definition der neuen Fortran-Schnittstelle für MPI-3 in beratender Funktion an der diesbezüglichen Diskussion im MPI-Forum teilgenommen.
2.7.4 Öffentlichkeitsarbeit
Das LRZ hat sich wieder auf den Supercomputing-Konferenzen ISC12 in Hamburg und SC12 in Salt
Lake City präsentiert. Dabei traten die drei Gauss-Mitgliedszentren auf der ISC zum ersten Mal mit einem neu gestalteten, gemeinsamen Stand auf. Das LRZ verwendete wieder sein verteiltes Display mit
vier großen HD-Monitoren, das mit Informationen, Filmen, Animation oder Simulationen beschickt wurde, die alle Bereiche des LRZ vorstellen und zudem einen Ausblick auf den Neubau und den SuperMUC
boten.
Abbildung 10 Neuer GCS Stand auf der ISC
Während der CeBIT vom 6.-10. März 2012 war das LRZ erneut mit seinen GCS Partnern am Stand des
Bundesministeriums für Bildung und Forschung unter dem diesjährigen Motto „Energie“ vertreten. Gezeigt wurden primär Simulationen zum Thema „Supercomputing im Bereich regenerativer Energieerzeugung“, z.B. eine 3-D „Virtual Reality“ Simulation eines von EnBW geplanten Pumpspeicherkraftwerkes
23
im nördlichen Schwarzwald und eine „Augmented Reality“-Simulation einer Kaplan-Turbine, bei der
dem Kamerabild einer real aufgebauten Turbine der hydrodynamisch berechnete Wasserfluss durch die
Turbinenschaufeln überlagert werden konnte. Neben den auf einem 152 Zoll großen Monitor gezeigten 3D Simulationen liefen an einer Info-Säule u.a. diverse wissenschaftliche Simulationen, die auf dem
HLRB II berechnet wurden. Viele der im Schnitt täglich 1.000 Besucher am Stand waren an näheren Informationen zu den gezeigten Filmen u.a. aus Astrophysik, CFD und Biochemie interessiert.
Abbildung 11 Bundesministerin Annette Schavan verfolgt eine 3-D Simulation am BMBF-Stand auf
der CeBIT 2012
Anfang 2012 wurde ein abschließender Berichtsband über die
Arbeiten am HLRB II erstellt. Der Berichtsband enthält mehr als
90 Artikel aus den Fachgebieten Astrophysik, Chemie, Fluiddynamik, Informatik und Mathematik, Geowissenschaften, Hochenergiephysik, Lebenswissenschaften und Festkörperphysik. Das
Buch liefert einen Überblick über das breite Anwendungsspektrum von Problemen, die eine Nutzung von Höchstleistungsrechnern erfordern. Die Artikel liefern Informationen über den wissenschaftlichen Hintergrund, die erzielten Resultate und über die
eingesetzten Methoden. Das Buch bietet auch Einblicke in die
erreichte Rechenleistung sowie in die Skalierbarkeit der Anwendungen. Viele Autoren geben auch einen Ausblick auf die Probleme die sie mit dem neuen Höchstleistungsrechner lösen wollen.
Dieser Berichtsband und auch Berichtsbände aus den Vorjahren
können beim LRZ angefordert werden oder sind unter der folgenden Adresse abrufbar:
http://www.lrz.de/services/compute/supermuc/magazinesbooks/
Der Berichtsband wurde auch bei der Einweihungsfeier für den SuperMUC verteilt. Für die Einweihungsfeier des SuperMUC wurde auch ein 10-minütiger 3-D Film erstellt, der mit Animationen das Gebäude
des LRZ, den Rechner selbst aber auch viele Aspekte des wissenschaftlichen Rechnens am LRZ aufzeigt.
Ein Ausschnitt davon (Animation des SuperMUC) findet sich unter folgender Adresse:
http://www.youtube.com/watch?v=GxGrLm4ufYE
2.8
Grid-Dienste
Grid-Computing bezeichnet die Vernetzung weltweit vorhandener heterogener Ressourcen wie Rechner,
Instrumente, Software und Daten zur koordinierten Lösung sogenannter „großer Herausforderungen “
24
(grand challenges). Die Grid middleware abstrahiert dabei von den Eigenheiten der Hardware und stellt
dem Benutzer ein einfach zu bedienendes, homogenes Interface zur Verfügung. Typische GridAnwendungen sind daher datenintensive (Big Data) oder rechenintensive Berechnungen, die auf Ressourcen innerhalb sogenannter virtueller Organisationen (VOs) verteilt werden. Beispiele finden sich in der
Wettervorhersage, in Astronomie-Projekten, der Hochenergiephysik, in biologischen Genom-Projekten,
in der Medikamentenforschung oder in den Wirtschaftswissenschaften. Schon heute sind sich deshalb
viele Analysten darüber einig, dass sich verteilte Systeme, insbesondere Grid-Computing und das in seiner Bedeutung rapide zunehmende Cloud-Computing, das besonders zur Deckung von Bedarfsspitzen
geeignet ist, mit zu den wichtigsten Technologien der nächsten Jahre und zum Motor völlig neuer Anwendungen entwickeln werden. Der große Unterschied zwischen Grid-Computing und Cloud-Computing
ist der föderale Aspekt beim Grid-Computing, der beim Cloud-Computing fehlt: eine Gruppe von Ressourcenanbietern, z.B. Rechenzentren wie das LRZ, stellen ihre Rechner ins Grid, das dann den GridBenutzern eine sehr hohe Gesamtrechenkapazität bieten kann. Dank Grid-Middleware wie Globus,
Unicore oder gLite, welche die Unterschiede in der Bedienung der verschiedenen Ressourcen nivelliert,
erscheint das Grid dem Benutzer wie eine einzige große, homogene Ressource.
Bis zu 10% der Rechenleistung der LRZ-Höchstleistungsrechner SuperMUC und SuperMIG sowie ein
nicht unerheblicher Teil der Rechenleistung unseres Linux Clusters werden über Grid-Middleware von
den Wissenschaftlern in Deutschland und Europa abgerufen.
Der Regelbetrieb der Grid-Dienste wurde durch die Mitarbeiter der Gruppe „Verteilte Ressourcen“ betreut und ausgebaut. Derzeit betreut die Gruppe etwa 70 Server auf denen ca. 40 Dienste in Produktionsund Testbetrieb laufen. Bei den seit Anfang 2012 in Produktion befindlichen Systemen lag die Verfügbarkeitsquote bei 99.998%. Um die Ausfallsicherheit der Dienste weiter zu erhöhen, wurde fortgefahren,
sie von physischer Hardware auf virtuelle Maschinen aus dem LRZ VMware-Pool zu migrieren. Außerdem wurde die automatische Überwachung der Maschinen und Dienste deutlich erweitert, sowie regelmäßige Kernel-Updates und Security-Checks durchgeführt.
Das LRZ bot seinen Benutzern die folgenden Grid-Dienste an
 Interaktiver Zugang über Globus GsiSSH
 Datentransfer (Globus GridFTP, Unicore, gLite dCache). Das LRZ installierte weltweit sichtbare
Einstiegspunkte für die LRZ Hoch- und Höchstleistungsrechner im neuen europäischen GlobusOnline Service (http://www.globusonline.eu/).
 Job-Submission (Globus, Unicore, gLite). Auf dem Linux-Cluster wurden 4.867.331 Grid-Jobs
mit insgesamt 10.428.658 CPU-h gerechnet.
 Grid-FTP, Gsi-SSH und GRAM Door Node für PRACE
 Proxyzertifikatsmanagement (Globus MyProxy) für PRACE und D-Grid
 Ausstellen von langlebigen Grid-Zertifikaten im Rahmen des Betriebs der Registration Authorities für die großen Münchner Universitäten (TUM, LMU, Universität der Bundeswehr) wie auch
für das LRZ selbst. Insgesamt wurden 2012 49 Zertifikate ausgestellt. Der Rückgang dieser Zahl
gegenüber dem Vorjahr begründet sich in einer zunehmenden Nutzung des Short Lived Credential Services (SLCS) des DFN, der ein langlebiges Zertifikat überflüssig macht.
 Grid-Überwachungs- und -Informationsdienste (Inca, MDS, WebMDS, D-MON, DMOS,
NAGIOS)
 Grid Test Bed (für die Projekte IGE, SLA4D-Grid, VERCE und DGSI)
 Download-Site (sog. Repository) für das Projekt IGE
 Web-Server für das European Globus Community Forum (EGCF)
 Grid Anwenderprogramme: GlobusOnline, gtransfer, GSI-SSHTerm, JSAGA, UNICORE
 Training-Kurse für die Globus Middleware
 Grid-Benutzerunterstützung (Helpdesk)
 Grid-Portal (http://www.grid.lrz.de/)
 Grid-Benutzerverwaltung (GUA) als Bindeglied zwischen den unterschiedlichen Benutzerverwaltungssystemen der Grid-Projekte (siehe nächster Abschnitt) und dem am LRZ verwendeten System LRZ-SIM. Die Zahl der Grid-Accounts betrug ca. 1.250.
Als abteilungsübergreifende Einrichtung war und ist der Arbeitskreis Grid Computing (AK-Grid) maßgeblich an der Koordinierung der verschiedenen Grid-Projekte (DGI-2, PRACE-1IP, PRACE-2IP,
PRACE-3IP, LCG Tier-2, EGI-InSPIRE, IGE, VERCE, Grid Aktivitäten an LMU, TUM, RZG, UniBW
25
und LRZ) innerhalb des LRZ und im Münchner Raum beteiligt, hilft Synergien auszunutzen und Doppelarbeit zu vermeiden.
2.9
Projekte im Grid-Computing
Das LRZ ist aktiv beteiligt an vielen nationalen und internationalen Grid-Projekten „Initiative for Globus
in Europe – IGE“, „European Grid Initiative - Integrated Sustainable Pan-European Infrastructure for
Researchers in Europe – EGI-InSPIRE“,„Partnership for Advanced Computing in Europe, 1st Implementation Phase - PRACE-1IP“, „Partnership for Advanced Computing in Europe, 2nd Implementation Phase
- PRACE-2IP“, „Partnership for Advanced Computing in Europe, 3rd Implementation Phase - PRACE3IP“ , „Virtual Earthquake and seismology Research Community e-science environment in Europe –
VERCE“, den D-Grid-Projekten DGI2, SLA4D-Grid sowie DGSI, LHC-Grid (LCG) und „eInfrastructure Reflection Group Support Programme 3 (e-IRGSP3)" beteiligt. Dabei hat das LRZ bei IGE
erstmalig die Führungsrolle in einem europäischen Projekt inne.
Im Folgenden beleuchten wir einige der in den Grid-Projekten durchgeführten Arbeiten ausführlicher.
2.9.1 Initiative for Globus in Europe (IGE)
IGE will hauptsächlich koordinierend
eingreifen und die europäischen Wünsche zur Globus Middleware bündeln
und abstimmen, um sie dann mit einer
gewichtigen Stimme gegenüber den anderen Globus-Entwicklern vorzutragen.
IGE integriert zehn europäische Partner
sowie die University of Chicago, die die
zentrale Globus-Codebasis pflegt.
IGE liefert die Globus Middleware für
die europäischen Grid-Infrastrukturen
wie EGI, PRACE, VERCE, DRIHM,
etc., und führt neben Benutzerunterstützung und Training auch Anpassungen von Globus an europäische Bedürfnisse durch. Dieses Projekt
stärkt die Rolle Europas und natürlich auch des LRZ im Globus-Projekt, dem weltweit führenden Middleware-Projekt.
Das LRZ hat hier erstmals die Konsortialführerschaft eines EU Projekts inne und organisierte im November 2012 das zweite EU Review Meeting von IGE in Brüssel. Die Gutachter konstatierten dem Projekt
gute bis sehr gute Fortschritte.
Es wurde das zweite Treffen des European Globus Community Forums (EGCF: http://www.egcf.eu/) am
LRZ ausgerichtet und die zweite GlobusEUROPE-Konferenz, das europäische Pendant zur amerikanischen GlobusWORLD-Konferenz, in Prag organisiert. IGE lieferte Software-Releases der Globus Tools
für die europäischen e-Infrastrukturen aus, die auch Eingang in die Unified Middleware Distribution
(UMD) von EGI fanden.
2.9.2 D-Grid (Förderung „e-Science und vernetztes Wissensmanagement“ des
BMBF)
In Deutschland hat insbesondere die D-Grid-Initiative (www.dgrid.de) die Auswirkungen der neuen Technologie „Grid“ auf
das wissenschaftliche Arbeiten thematisiert und ein entsprechendes Forschungs- und Entwicklungsprogramm vorgeschlagen.
D-Grid hat es sich zum Ziel gesetzt, alle Grid-Aktivitäten in
Deutschland zu bündeln, um so intern Synergieeffekte auszunutzen und nach außen mit einer einheitlichen Stimme sprechen
zu können. Die vom BMBF für den Zeitraum von 2005 bis 2012
26
geförderte D-Grid Initiative will in Deutschland eine e-Science-Kultur ähnlich der überaus erfolgreichen
britischen e-science initiative aufbauen. Im Rahmen von D-Grid nahm das LRZ 2012 an vielen Workshops und Treffen teil.
Da D-Grid zum Jahresende 2012 zu Ende ging, wurden die Aktivitäten im letzten Jahr schrittweise an
NGI-DE (National Grid Initiative – Deutschland) übergeben. NGI-DE ist die deutsche Vertretung im
Rahmen des europäischen Grid-Verbunds, der European Grid Infrastructure (EGI).
2.9.2.1
D-Grid Integrationsprojekt (DGI)
Als Rechenzentrum und damit als Ressourcenanbieter war das LRZ vorrangig am D-Grid Integrationsprojekt (DGI, Laufzeit Jan. 2008 bis Dez. 2012) beteiligt. Aufgrund langjähriger guter Kontakte zu HPCBenutzern aus Astro- und Hochenergiephysik trat das LRZ aber auch als assoziierter Partner der Astrophysik- und der Hochenergiephysik-Community auf. Außerdem war zur Vertretung der GlobusRessourcen-Anbieter ein Mitarbeiter des LRZ im Technical Advisory Board (TAB) des D-Grid vertreten.
Das LRZ stellt im verteilten Kompetenzzentrum Middleware vielfältiges Know-how für die Unterstützung von Benutzern und Ressourcenanbietern bezüglich Globus bereit. Auf den Produktionssystemen des
LRZs wurde Globus von GT5.0.3 auf GT5.2.2 angehoben.
Das LRZ hat die Ressourcen, die im Rahmen früherer Sonderinvestitionen beschafft wurden, weiterbetrieben und für das D-Grid verfügbar gemacht. Im Jahr 2012 wurden auf diesen Ressourcen fast 4,5 Mio.
Jobs submittiert, die ca. 10 Mio. CPUh verbraucht haben. Der Speicherplatz im dCache-Pool belief sich
auf ca. 560 TB.
Als zentrale Dienste für D-Grid hat das LRZ Grid-Monitoring mittels der Werkzeuge RFT, MDS,
WebMDS, GridCSM, D-MON und Inca sowie den zentralen MyProxy-Server zur Authentisierung der
Nutzer betrieben. Es wurde intensiver Globus-Support für alle Communities, allen voran die AstroCommunity, geleistet.
Das LRZ arbeitete an der Weiterentwicklung des Monitoringdienstes D-MON, sowie der Durchführung
der Zertifizierung der Globus-Installation auf den D-Grid Ressourcen, die Voraussetzung für eine Integration der deutschen Ressourcen in den europäischen EGI-Verbund ist.
2.9.2.2
DGSI
Das D-Grid-Projekt „D-Grid Scheduler Interoperability“ (DGSI) entwickelte eine Interoperabilitätsschicht für Scheduling in Service Grids, die es Benutzern einer Community erlaubt, bei freien Ressourcen
Arbeitslast auf Ressourcen einer anderen Community zu verlagern.
LRZ-Mitarbeiter beteiligten sich dazu an Telefonkonferenzen und Projekttreffen und brachten so die
Sichtweise des LRZ in das Projekt ein. Das LRZ war als Leiter von Task 4 für die Anbindung lokaler
Resource Management-Systeme verantwortlich. Im Rahmen dieses Tasks installierte das LRZ die in
DGSI entwickelten Ressource-Delegation-Mechanismen der zweiten Generation sowie advance reservation Adaptoren in seinem Testbed.
DGSI wurde Mitte 2012 erfolgreich abgeschlossen.
2.9.2.3
SLA4DGRID
Das D-Grid-Projekt “Service Level Agreements for D-Grid” (SLA4D-GRID) realisierte eine Service
Level Agreement-Schicht (SLA-Schicht) für das D-Grid. Diese Schicht zur Vereinbarung einer festgelegten Dienstgüte bietet einzelnen Benutzern, ganzen D-Grid Communities, sowie den Anbietern von DGrid-Ressourcen die Gewährleistung der Ressourcennutzung unter wirtschaftlichen Bedingungen.
Das LRZ entwickelte D-MON, eine D-Grid Eigenentwicklung im Monitoring-Bereich, zu einem in
SLA4DGRID verwendbaren Werkzeug weiter. Vom LRZ wurde das Testbed mit sechs Servern den aktuellen Erfordernissen angepasst.
SLA4DGRID wurde zum ebenfalls Mitte 2012 erfolgreich abgeschlossen.
2.9.3 EGI-InSPIRE
Mit der Beteiligung an EGI-InSPIRE spielt das LRZ auch eine wesentliche Rolle in der zweiten großen
europäischen e-Infrastruktur EGI. Zusammen mit der Beteiligung an PRACE fällt damit dem LRZ eine
27
wichtige Funktion für die Integration der Infrastrukturen zu, an der auch in 2012 mit Hochdruck gearbeitet wurde. Die Anforderungen dazu kommen unter anderem aus den Nutzer-zentrierten Projekten MAPPER, VERCE und DRIHM.
Im Projekt EGI-InSPIRE beteiligt sich das LRZ an den Arbeitspaketen zum Entwurf der notwendigen
Policies und zur Definition der Grid-Management-Infrastruktur auf europäischer Ebene. Es arbeitet mit
am verlässlichen Betrieb der Grid-Dienste, die von der deutschen Grid-Infrastruktur der EGI zur Verfügung gestellt werden. Darüber hinaus leistet das LRZ den europaweiten 2nd-Level-Support für das Globus
Toolkit
2.9.4 VERCE
VERCE hat sich die Unterstützung der Seismologen in Europa zum Ziel
gesetzt. VERCE beabsichtigt, die in der Wissenschafts-Community vorhandene Dateninfrastruktur mit den Grid und HPC Infrastrukturen (vorrangig
PRACE und EGI) zu verschmelzen. Dem LRZ fällt hierbei die herausragende Rolle zu, einer der Lieferanten von VERCEs service-orientierter Infrastruktur zu sein.
Das LRZ leitet das Arbeitspaket „Integration and evaluation of the platform services“ und ist auch in den
Arbeitspaketen „Training and User Documentation“, “Management and operation of research platform“,
„Harnessing data-intensive applications“ und „VERCE Architecture and Tools for Data Analysis and
Data Modelling Applications“ beteiligt. Für die Integration der verschiedenen Software-Produkte in die
VERCE Software-Platform wurden zwei Qualitätmanagementzyklen in Anlehnung an die Vorgaben des
ISO 20000-Standards durchgeführt. Durch die Leitung einer HPC Taskforce konnte das LRZ maßgeblich
zur Erstellung eines Use cases beitragen, der erstmalig einen vollständig automatisierten seismologischen
Workflow von den Sensordaten bis zum wissenschaftlichen Endergebnis demonstrierte. Im April erhielt
das Projekt beim ersten EU-Review eine sehr gute Bewertung.
2.9.5 MAPPER
MAPPER (Multiscale Applications on European e-Infrastructures, http://www.mapper-project.eu/) konzentriert sich darauf, die für die Forschung immer wichtiger werdenden Multi-Skalen-Systeme, die mehrere wissenschaftliche Gebiete (wie etwa die Fluiddynamik, die Strukturmechanik und die Chemie der
Verbrennungsvorgänge) gemeinsam betrachten, effizient auf die europäischen Infrastrukturen wie EGI
und PRACE abzubilden. Solche interdisziplinären Multi-Skalen-Systeme erfordern zu ihrer Simulation
höchste Rechenleistung.
Das LRZ fungiert hier als Unterstützung für die LMU, einem der MAPPER Partner, und stellt in diesem
Rahmen Hardware und Software sowie weitere umfassende Unterstützung für das Projekt zur Verfügung.
So unterstützte das LRZ letztes Jahr das MAPPER-Konsortium bei der Umsetzung und Durchführung
von Multi-Skalen-Simulationen auf dem Linux-Cluster und den SuperMUC/SuperMIG HPC-Systemen.
Insgesamt wurden drei unterschiedliche Multi-Skalen-Szenarien aus den Bereichen Plasma-Physik, Hydrologie und Medizin auf den LRZ-Systemen aufgesetzt, getestet und durchgeführt. Das HydrologieSzenario wurde beim MAPPER EU Review Meeting im Novenber dazu verwendet, die Fähigkeiten und
Vorteile des Multi-Skalen-Ansatzes zu demonstrieren.
2.9.6 DRIHM
DRIHM (Distributed Research Infrastructure for Hydro-Meteorology) baut eine prototypische e-ScienceUmgebung für die Hydrometeorologie in Europaauf. Die Hydrometeorologie beschäftigt sich mit der
Wechselwirkung zwischen Wetter, insbesondere Regen, dem Boden und den Wasserabflüssen, die zu
Überschwemmungen und Erdrutschen führen können. Ziel ist, durch rechtzeitige Gefahrenvorhersage und
Evakuierungen Menschenleben retten zu können. Durch mehrere Meetings am LRZ konnte die Zusammenarbeit mit dem DRIHM-Konsortium, in dem wir bei MAPPER die LMU als Partner fungiert, intensiviert werden. Unter anderem konnte das LRZ die Schwierigkeiten beim Transfer großer Datenmengen
zwischen den Partner-Standorten durch Beratung und Unterstützung bei der Verwendung der GlobusWerkzeuge (GridFTP, Globus Online) deutlich reduzieren
28
2.9.7 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3)
Die e-Infrastructure Reflection Group (e-IRG) ist ein Beratergremium der EU, das Empfehlungen zu Best
Practices für europäische e-Infrastrukturen ausspricht. Das Gremium setzt sich aus jeweils zwei Delegierten der Regierungen aller EU-Staaten zusammen. Es erstellt Weißbücher, Fahrpläne und Empfehlungen
und analysiert die zukünftigen Grundlagen der europäischen Wissensgesellschaft.
Dieses Beratergremium wird durch das auf drei Jahre angelegte Projekt „e-Infrastructure Reflection
Group Support Programme 3 (e-IRGSP3)" in seiner Arbeit unterstützt. Das LRZ leitet in diesem Zusammenhang das Arbeitspaket "Policy Support", das unter anderem die bestehenden Policies analysiert und
die Erstellung der Policy-Dokumente (Weißbücher, Fahrpläne, etc.) vorbereitet, koordiniert und publiziert. Das LRZ leitete die Erstellung des Strategiepapiers „e-IRG Policy Paper on Scientific Software“
sowie der „e-IRG Roadmap 2012“. Weitere unter der Koordination des LRZ entstandene Strategiepapiere
waren „e-IRG e-Infrastructures in Support of the Digital Agenda“, „e-IRG Reaction on the GÉANT Expert Group Report“, „e-IRG Task Force Report on Cloud Computing“, „e-IRG Blue Paper on Data Management“ und ein Dokument über die Neuausrichtung der Stategie der e-Infrastructure Reflection
Group. Im Jahr 2012 wurde die bisher größte Anzahl von Strategiepapieren in der neunjährigen Geschichte der e-IRG veröffentlicht.
2.9.8 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG)
Bei den Experimenten der bedeutenden Wissenschaftsprojekte am CERN entstehen gewaltige Mengen an
Daten im PetaByte-Bereich. Für die Auswertung wurde von Anfang an auf verteilte Ressourcen gesetzt.
Heute sind dafür weltweit hunderte Cluster im LHC Computing Grid (LCG) vernetzt. Das LRZ betreibt
dabei zusammen mit dem MCSC-Partner RZG und dem Lehrstuhl für Hochenergiephysik der LMU ein
Tier-2-Zentrum (siehe Abbildung 12).
Abbildung 12 Tier-Struktur des LHC Computing Grids.
Speicher- und Rechenknoten des Tier-2 Zentrums wurden im Rechnerwürfel des LRZs installiert. Den
Betrieb bis zur Vermittlungsschicht, der Middleware gLite, übernimmt das LRZ, die Middleware und die
darüber liegende Experiment-Software wird von den Physikern der LMU betreut. Derzeit steht am LRZ
für die Speicherung von Experimentdaten und Auswertungsergebnissen ca. 1 PetaByte zur Verfügung.
Durch die Absicherung als RAID beträgt die Nettokapazität aber nur 777 TB, die über die dCache-
29
Speicherverwaltung bereitgestellt werden. Die LCG-Rechenknoten sind in den LRZ-Linux-Cluster integriert. Dadurch können Kapazitätsengpässe sowohl bei LCG-Aufgaben als auch bei LRZ-Aufgaben umgangen und insgesamt alle Ressourcen besser ausgelastet werden. Im Moment verwaltet das LRZ LCGRechenknoten mit 1.828 Cores.
Das LRZ stellt dem LCG-Projekt auch virtuelle Maschinen zur Verfügung. Dabei werden die speziellen
LCG-Anforderungen – etwa bezüglich des Betriebssystems „Scientific Linux“ – unterstützt.
Serverbetrieb
30
3 Serverbetrieb
3.1
Linux-Server
Das Jahr 2012 war im Großen und Ganzen durch die Aufrechterhaltung der Vielzahl bestehender Dienste,
basierend auf vermehrt virtueller und vereinzelt noch physischer Hardware geprägt.
Die zahlenmäßige Entwicklung installierter Linux-Systeme verdeutlicht folgende Abbildung:
Abbildung 13 Anzahl der Linux-Hosts im Leibniz-Rechenzentrum
Zu den anstehenden Arbeiten zählte in diesem Jahr die ServicePack-Aktualisierung der meisten Server
mit „SUSE Linux Enterprise Server 11“ von Version SP1 auf SP2.
Die Zunahme an gehosteten, virtuellen Servern für externe Kunden ließ auch die Zahl abzuarbeitender
Kunden-Tickets anwachsen. Ein spürbarer Anstieg war in der Kundenberatung für die Bayerische Staatsbibliothek (BSB) zu verzeichnen. Hier gab es die deutlichste Zunahme neuer Kunden-Server.
Eine Übersicht über den Anstieg virtueller Server verdeutlicht Abbildung 14.
Aufgrund der Fülle an Aufgaben wurde das „Team Linux-Server und -Mitarbeiter-Arbeitsplätze“ (TeamLSM) in der ersten Jahreshälfte durch Zusammenführung mit den Verantwortlichen für das „Hochschulstartsystem“ (HSS) zu einer eigenständigen „Gruppe IT-Infrastruktur Server und Dienste“ (ITS)
innerhalb der Abteilung Hochleistungssysteme.
Verstärkt mit zusätzlichem Personal erfuhr das Thema Sicherheit im Bereich der Linux-Server eine spürbare Erweiterung. Neben Arbeiten zur Umsetzung einer Passwort-Policy etablierte sich ein zentrales Systemmonitoring auf Basis der Analyse-Software „Splunk“.
Die mittels Überwachungssoftware „LRZmonitor“ erfassten hostspezifischen Daten wurden zusammen
mit den Daten virtueller Hosts aus dem „VMware vCenter“ in eine MySQL-Datenbank integriert. Auf
dieser gemeinsamen Datenstruktur können fortan Dienste, wie das in Entwicklung befindliche SelfService-Portal zum Managen virtueller Hosts, operieren.
31
Abbildung 14 Anzahl virtueller Hosts im Leibniz-Rechenzentrum
Die Virtualisierungsinfrastruktur des LRZ bestand 2012 aus 80 Blade-Systemen mit 640 Kernen, 7,6 TB
RAM und 100 TB Hintergrundspeicher unter VMware sowie einigen zusätzlichen Testsystemen. Auf
dieser Infrastruktur werden über 820 virtuelle Server unter Windows und Linux betrieben. Seit die Virtualisierung von Servern allgemein akzeptiert wurde, werden immer anspruchsvollere und größere Anwendungen auf diese Art betrieben. Aus diesem Grund werden auch große virtuelle Systeme mit mehreren
Kernen stark nachgefragt. Die organisatorischen Abläufe bei der Bereitstellung von Servern wurden optimiert und der Kundenservice konnte dank zusätzlicher Mitarbeiter verbessert werden.
Seit Mitte des Jahres wird im Hinblick auf die Ablösung der aktuellen Server-Blade-Infrastruktur neue
Hard- und Software u.a. der Fa. Cisco untersucht. Zu Testzwecken befindet sich deshalb ein Chassis:
Cisco UCS 5108 und darin eingebaut: zwei Fabric Interconnects: Cisco UCS 6248UP, zwei Blades: Cisco
UCS B200-M3 mit 16 Kernen und 126 GB RAM sowie ein Beta-Blade: Cisco UCS B420-M3 mit 32
Kernen und 256 GB RAM im Serverraum.
In der zweiten Jahreshälfte gelangte das Thema Cloud-Computing in den Fokus der Diskussion und Analyse: erste Tests verschiedener Anbietersoftware wurden durchgeführt. Im September 2012 fand eine
Life-Demo der „OpenStack-basierten Private Cloud-Suite“ durch den Anbieter SUSE statt.
3.2
Windows
Am LRZ werden zurzeit rund 100 physische oder virtuelle Windows Server betrieben. Der Anteil der
virtuellen Systeme liegt bei 80%. Es hat sich aber in den vergangenen Jahren wiederholt gezeigt, dass es
unter Umständen nicht sinnvoll ist, bestimmte Systeme zu virtualisieren. So wurden die Mailbox-Server
für die Exchange-Infrastruktur in 2012 neu mit physischer Hardware aufgebaut um den Storage direkt
anbinden zu können. Aus Performancegründen werden noch ein physisches SQL-Cluster und alle Domain
Controller des MWN-Active Directory betrieben, da die Leistungsfähigkeit der virtuellen Maschinen zu
schlecht ist. Auch verhindern bestimmte Anwendungen wie z.B. für das Gebäudemanagement am LRZ
oder Überwachungskomponenten, die möglichst unabhängig von weiterer Infrastruktur betrieben werden
müssen, eine Virtualisierung.
Die momentan unterstützten Betriebssystemversionen am LRZ reichen dabei von Windows 2000 Server
bis zur aktuellen Version Windows Server 2012. Windows Server ist dabei das Basisbetriebssystem für
verschiedene höherwertige Dienste am LRZ wie Active Directory, Exchange oder Terminalserver.
Die Installation, Pflege und Reporting der Systeme erfolgt über den zentralen Microsoft System Center
Configuration Manager 2012 (SCCM) am LRZ, der auch für die Clientsysteme Verwendung findet. Für
Monitoring und Alerting findet der Microsoft System Center Operation Manager 2012 (SCOM) von
32
Serverbetrieb
Microsoft Verwendung, der mit seinen vorgefertigten Management Packs gezielt, nicht nur das 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 DELL
Openmanage, wodurch Hardwareprobleme an den SCOM gemeldet werden.
33
4 Datenhaltung
4.1
Überblick Datenhaltung
Hinsichtlich der Art der Datenträger gliedert sich die Datenhaltung am LRZ im Wesentlichen in zwei
Bereiche,
 den Bereich der Massenspeicher der Archiv- und Backupsysteme mit ihren Bandbibliotheken
(Abschnitt 4.2), auf die sich unter anderem die Langzeitarchivierung (Abschnitt 4.2.4) abstützt,
 und in den Bereich der Online-Speicher (Abschnitt 4.3) vorwiegend auf der Basis von Network
Attached Storage (NAS).
Bezeichnend für den rasanten Datenzuwachs ist die Tatsache, dass inzwischen Petabyte als Einheit zur
Angabe größerer Datenmengen die noch im Jahresbericht 2011 benutzte Einheit Terabyte abgelöst hat
(ein Petabyte = 1.000 Terabyte =1015 Byte = 1.000.000.000.000.000 Byte).
Für Sicherungssysteme zweiter Ordnung sowie für die Archivierung von großen Datenmengen sind Bänder als Datenträger gestern wie heute unverzichtbar. Der Umfang der in den Bandbibliotheken des LRZ
gespeicherten Daten wuchs im Jahr 2012 von 20 PetaByte auf 28 PetaByte an.
Die Zusammenarbeit mit der Bayerischen Staatsbibliothek und dem Bibliotheksverbund Bayern wurde
weiter intensiviert. Dabei fungiert das LRZ als IT Service Provider in den Bereichen Serverhosting, Clusterhousing, Storagehousing einerseits und als Projekt- und Kooperationspartner in verschiedenen Projekten andererseits. Die Bayerische Staatsbibliothek verfügt über einen eigenen Online-Speicher mit 0,7
Petabyte Kapazität am LRZ, der von verschiedenen Arbeitsgruppen und Projekten genutzt wird. Dieser
Speicher ist auch Ausgangspunkt für die Übertragung der Daten ins Langzeitarchiv des LRZ, in dem sich
mittlerweile knapp 0,5 Petabyte Archivdaten befinden.
Am LRZ und an den anderen Kommissionen der Bayerischen Akademie der Wissenschaften wird gemeinsam nutzbarer, hoch verfügbarer und optimal gesicherter Speicher auf Basis der NAS-Technologie
eingesetzt. Dieser sogenannte MWN-Speicher oder „Speicher für Wissenschaft“ steht als Grundversorgungsangebot auch Mitarbeitern und Studierenden der TU München und der LMU zur Verfügung und
ersetzt dort immer häufiger lokale Lösungen.
Im Zuge der Installation des SuperMUC wurden sowohl die Online-Speichersysteme als auch die Archivund Backupsysteme erheblich erweitert. Das gesamte Jahr 2012 war geprägt von den umfangreichen Arbeiten in diesem Zusammenhang, insbesondere die Verlagerung der Daten auf die neuen Systeme.
Insgesamt ist der zur Verfügung stehende Online-Speicherplatz auf NAS-Basis auf mehr als 9 Petabyte
brutto angewachsen. Zusammen mit dem SAN-Speicherplatz beträgt die Bruttokapazität der Plattenspeicher über 12 Petabyte verteilt auf über 8.000 Festplatten. Hinzu kommen 10 PB für das parallele Filesystem des SuperMUC.
4.2
Archiv- und Backupsystem
4.2.1 Konfiguration
Das Archiv- und Backupsystem des LRZ besteht aus drei großen Systemen mit Bandrobotern:
 einem Hochleistungssystem HABS, das Anfang 2006 installiert und seitdem dreimal (Ende 2007,
2010 und Mitte 2012) erweitert wurde,
 und einem System mit LTO-Bandlaufwerken in mehreren Bibliotheken (LABS), das 2010 neu installiert wurde.
 Zusätzlich wurde mit der jüngsten HABS Erweiterung im Jahr 2012 ein Desaster Recovery System (DRABS) beschafft, das eine zweite Kopie der Archivdaten vorhält. Dieses System ist, um
die Ausfallsicherheit zu erhöhen, räumlich getrennt am Rechenzentrum Garching der Max-PlackGesellschaft installiert.
Ebenfalls aus Gründen der Ausfallsicherheit befinden sich die Komponenten der drei Systeme in getrennten Speichernetzen (SAN-Fabrics). An die SAN-Fabrics sind die Storageserver, alle Bandlaufwerke der
Libraries und alle Serversysteme mit hohem Datenverkehr, insbesondere die File- und Backupserver an-
Datenhaltung
34
geschlossen. Die SAN-Fabrics sind Grundlage für einen effizienten Transport von großen Datenmengen,
durch sie wird die Last am LAN reduziert und eine dynamische Zuordnung der Speicherkomponenten zu
den Verbrauchern ermöglicht.
Archive and Backup System, Dec 2012
IBM
SUN
Brocade
DELL
Disk Cache + DB
Brocade 6510
IBM DS3500
399 TB
Brocade 6510
Library IBM TS3500
7 tape devices IBM LTO5
19,137 slots
2 TSM Servers
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
Disk Cache
IBM DS3500
1539 TB
Library SUN SL8500
26 tape devices SUN T10K-B
10,000 slots
SAN
Brocade
DCX
8510-4
Brocade
DCX
8510-4
DB
IBM StorWize
V7000
10 TB SSD
Disk Cache + DB
TSM
SAN
3 TSM Servers
12 machines
SUNFire X4270
TSM
Disk Cache + DB
Brocade 5300
Brocade 5300
DELL PowerVault
MD36XXf
281 TB
Library IBM TS3500
17,333 slots
HABS –
High Performance Archive and Backup System
3 TSM Servers
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 15 Überblick Archiv- und Backupsysteme
Die wesentlichen Komponenten des Systems sind:
 21 Rechner (Vorwiegend Intel Nehalem EP und EX), 388 Cores, 3.952 GB Memory
 6 Fibre Channel Switches (8 Gbit/16 Gbit) und 2 Fibre Channel Direktoren (8/16 Gbit)
 56 10 GE LAN Ports mit 100 Gbit/s Uplink zum LRZ Backbone
 18 Storage Servern mit insgesamt 2.700 TB (Brutto) verteilt auf 2.424 Disks und 38 SSDs mit 70
GB/s theoretischer Gesamtdurchsatz
 5 Tape Libraries mit insgesamt 61.500 Slots
 98 Bandlaufwerke (LTO-4, LTO-5, T10K) mit 24 GB/s theoretischem Gesamtdurchsatz
Softwareseitig wird die gesamte Architektur mit dem Tivoli Storage Manager von IBM betrieben. Auf
den 21 Rechnern des Systems laufen jeweils mehrere Instanzen des Tivoli Storage Manager, insgesamt
waren Ende 2012 64 TSM-Server in Betrieb
Die Abbildungen auf den folgenden Seiten zeigen die drei Teil-Konfigurationen des HABS, LABS bzw.
DRABS im Detail.
35
High Performance Archive and Backup System 2012
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
capacity:
17.500 TB, 10.000
53.000 TB, 10.000
26 x T10K-B, 15 x
10 TB SSD, 117 TB
T10K cartridges + 5000 LTO-5 cartridges
T10K cartridges + 17.300 LTO-6 cartriges
LTO-5
SAS, 1702 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 SP2
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 SP2
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 SP2
TSM Server 6.3
72 x 8 Gbit FC
National
Supercomputer
SuperMUC
8 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
15 x 8 Gbit FC
IBM TS3500 tape library
15 FC tape drives LTO-5
Max library capacity:
Cur. library capacity:
43.000 TB uncompressed
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 V7000
SSD 5TB
IBM V7000
SSD 5TB
STK SL8500 tape library
26 FC tape drives Titanium B
1118 disks total capacity:
1830 TB
Abbildung 16 Hochleistungs-Archiv-und Backupsystem Ende 2012
Datenhaltung
36
LTO Archive and Backup System 2012
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
devices:
14.039 TB, 5.500 LTO-4 cartridges + 6426 LTO-5 cartridges
22.500 TB, 16.500 LTO-5 cartridges
26 x LTO4 + 24 LTO5 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 SP2
TSM Server 6.3
56 x 8 Gbit FC
8 GBit FC-Switch 80 Port
26 x 4 Gbit FC
24 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
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 17 LTO-Archiv-und Backupsystem Ende 2012
SUN 6780
FC-AL 61 TB
SATA 87 TB
37
Desaster Recovery Archive and Backup System 2012
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
capacity:
9.000 TB,
6.000 LTO-5 cartridges
47.800 TB, 19.137 LTO-6 cartriges
7 x LTO-5
6 TB SAS, 393 TB NL-SAS
Munich Scientific Network
Router MWN
10 Gbit
24 x 10 GbE Ports
1 x IBM X3850 X5
Worker Server
XEON X7550
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 SP2
TSM Server 6.3
16 x 8 Gbit FC
FC-Switch
24 Port 16Gb
7 x 8 Gbit FC
IBM TS3500 tape library
7 FC tape drives LTO-5
FC-Switch
24 Port 16Gb
16 x 8 Gbit FC
IBM DS3500
SAS 3 TB
NL-SAS 196 TB
IBM DS3500
SAS 3 TB
NL-SAS 196 TB
192 disks total capacity:
399 TB
Abbildung 18 Desaster Recovery Archiv- und Backupsystem Ende 2012
38
Datenhaltung
4.2.2 Aktivitäten
Beschaffung und Inbetriebnahme eines Hochleistungsarchivs für den SuperMUC
Der Schwerpunkt im Jahr 2012 lag bei den Aktivitäten rund um das neue Archiv-System für den SuperMUC, welches auch das neue Desaster Recovery Archiv- und Backupsystem (DRABS) umfasste.
An der europaweiten Ausschreibung im ersten Quartal 2012 beteiligten sich die Firmen IBM, Oracle und
SpectraLogic/SGI, vertreten jeweils durch deren Businesspartner. Den Zuschlag konnte die Firma IBM –
vertreten durch die SVA GmbH – für sich entscheiden. Das IBM-Angebot erfüllte alle Kriterien und
konnte an einigen Stellen sogar mit deutlicher Übererfüllung hinsichtlich Kapazität und Leistungsfähigkeit punkten.
Im zweiten Quartal 2012 wurde die Hardware für das SuperMUC-Archivs am LRZ und das Desaster
Recovery Archiv- und Backupsystems am RZG geliefert und aufgebaut. Es wurden 5 Server, 4 SAN
Switche, 9 Storagesysteme mit 750 Platten und zwei Libraries mit insgesamt fast 36.500 Stellplätzen
innerhalb weniger Wochen installiert und in Betrieb genommen. Der Hardwareaufbau inklusive Verkabelung (etwa 250 Kabel) und Beschriftung wurde wie in der Ausschreibung gefordert, von den Firmen IBM
und SVA übernommen. Der Aufbau verlief sehr zügig und reibungslos, so dass das System bereits im
Juni betriebsbereit erklärt wurde. Parallel dazu wurde das neue SuperMUC-Archiv und das vorhandene
HABS durch den Umzug der HABS-Server in den hochverfügbaren Rechnerraum DAR1 zu einem System zusammengeschlossen (siehe unten).
Nach Installation der Geräte durch den Lieferanten konnte die Konfiguration der Hardware wie z.B. die
Storagesysteme und SAN-Switche durch das LRZ relativ schnell bewerkstelligt werden, da fast sämtliche
Systeme bzw. deren Vorgänger bereits am LRZ im Einsatz waren und dadurch das entsprechende KnowHow bereits vorhanden war. Ebenso effizient konnte die Installation und Konfiguration der Software und
die Provisionierung der TSM Instanzen auf den neuen Servern erfolgen, da hier mittlerweile einen sehr
hohen Automatisierungsgrad durch den Einsatz von CF-Engine erreicht ist.
Die Abnahme des SuperMUC Archivs begann mit einem Fehler an einem Storagecontroller, der nur
durch den Tausch der sogenannten Midplane (ein Teil, an dem laut Hersteller äußert selten Defekte auftreten) behoben werden konnte. Da dieser Austausch sehr kompliziert und langwierig war, konnte die
Verfügbarkeitsprüfung auf Anhieb nicht bestanden werden und musste um 11 Tage verlängert werden.
Bis auf diesen Vorfall verlief die Verfügbarkeitsprüfung relativ reibungslos und ohne größere Zwischenfälle.
Während der Abnahme wurden die Archivdaten des Migrationssystems SuperMIG, sowie die Bestandsdaten des Vorgängers des SuperMUC (HLRB II) in das neue Archiv verlagert sowie die Zweitkopie der
Archive des HABS und des LABS auf dem Desaster Recovery System angelegt (siehe unten). Durch
diese Maßnahme wurde hohe Last erzeugt, so dass die Abnahme unter realen Produktionsbedingungen
stattfinden konnte.
Umzug der HABS Server in DAR1 und Zusammenschluss mit SuperMUC Archiv
Anfang 2012 hätte für die 6 SGI IS4500 Storagesysteme, auf denen die TSM-Datenbanken des HABS
lagen, der Wartungsvertrags verlängert werden müssen. Die Kosten für drei Jahre Wartung überstiegen
die Kosten für die Ersetzung durch ein neues System inkl. drei Jahren Wartung. Deshalb wurden aus
Restmitteln drei Dell PowerVault MD3620f Storagesysteme mit je 144 136TB SAS Platten als Ersatz
beschafft. Zudem musste Mitte 2012 die Wartung für die alten HABS SAN Direktoren und Storageserver
verlängert werden. Da dies ebenso unverhältnismäßig hohe Kosten verursacht hätte, wurde entschieden,
die alte Storage-Infrastruktur (SAN und Platten) des HABS komplett abzuschalten und stattdessen die
Server und die Dell-Storagesysteme mit dem SuperMUC Archiv zum HABS 2.0 zu verschmelzen. Im
Rahmen der Beschaffung des SuperMUC Archivs wurden zusätzliche SAN Ports durch das LRZ gekauft,
über die die HABS 1.0 Komponenten (Server, Dell Storagesysteme, Tapes) integriert wurden. Weiterhin
wurde das 2011 aus Eigenmitteln finanzierte SuperMIG-Backup- und Archivsystem, bestehend aus einem
IBM X3850 X5 und zwei DS3500 Storageservern mit 144 TB Kapazität in das HABS 2.0 integriert. Die
Dell Storagesysteme wurden im neuen Serverraum DAR1 aufgestellt und die neue Verkabelung vorbereitet. Danach konnte der Umzug der verbliebenen HABS 1.0 Komponenten mit weniger als 8 Stunden
Dienstausfallzeit bewerkstelligt werden.
39
Migration der Archivkopien in das neue DRABS-System
Um einen Verlust von Archivdaten im Falle eines Mediendefekts oder einer Katastrophe wie z.B. eines
Brandes zu vermeiden, wird von den Archivdaten eine Zweitkopie erstellt. In der Vergangenheit wurde
diese Zweitkopie auf Grund eines bilateralen Abkommens zwischen LRZ und RZG im TSM-System des
RZGs gespeichert. Um mehr Unabhängigkeit bei der verwendeten Software bzw. Softwarekonfiguration
zu bekommen, entschieden sich das LRZ und das RZG 2011 dafür, in Zukunft nicht mehr die Daten im
TSM-System des jeweiligen Partners zu speichern, sondern im Partnerrechenzentrum eigene Hardware zu
installieren. Seit 2012 betreibt das LRZ sein Desaster Reocvery-System am RZG und ab 2013 wird das
RZG umgekehrt ein eigenes System am LRZ installieren.
Nachdem das LRZ-eigene Desaster Recovery-System zusammen mit dem SuperMUC-Archiv im Frühjahr 2012 installiert wurde, musste die Migration der Zweitkopie in das neue System erfolgen. Dafür
mussten alle Archivdaten auf der Primärseite mit einem Gesamtumfang von etwa 6 PB erneut gelesen und
per 10 Gbit Netzwerk in das neue System kopiert werden. Danach konnte die alte Zweitkopie im RZG
TSM System gelöscht werden.
Einführung einer neuen Reporting-Software als Ersatz für DatWEB
Ende 2012 wurde die Software TSM-Reporter als Teilersatz für das vom LRZ in den 90er Jahren selbst
programmierte DatWEB eingeführt. Die neue Software stammt von der niederländischen Firma PLCS
welche sich auf Produkte und Services rund um TSM spezialisiert hat. Die Software sammelt täglich
wichtige Kenndaten aus der TSM Datenbank und erzeugt daraus Reports. Das ermöglicht den TSMAdministratoren Trends, die zu Engpässen führen, proaktiv zu Erkennen und frühzeitig darauf zu reagieren. Zudem stellt es u.a. Prognosen über das Datenwachstum an.
Durch den Einsatz dieser Software konnte der benötigte Funktionsumfang eines Nachfolgersystems für
DatWEB, das zwangsläufig wieder großteils eine Eigenentwicklung sein wird, deutlich verschlankt werden. Zudem ist die Weiterentwicklung und Support durch die Firma PLCS garantiert.
Neues Backupverfahren für Exchange-Server
Im Rahmen einer Ausschreibung wurde 2012 eine neue Storagelösung für die Microssoft ExchangeUmgebung des LRZ beschafft. Das alte System, basierend auf virtuellen Servern, stützte sich auf die
NAS-Speicher von NetApp und konnte die inhärenten Exchange Features zur Erhöhung von Redundanz
und Sicherheit nicht nutzen, jedenfalls nicht zu vertretbaren Kosten. Das neue System besteht aus physischen Servern mit Direct Attached Storage. Ein neues, effizientes Backupverfahren wurde aufgesetzt, das
die im Rahmen des Tivoli Landeslizenzvertrags vorhandenen Lizenzen nutzt. Mit TSM for Mail ist es
möglich, die Exchangedatenbanken im laufenden Betrieb in TSM zu sichern. Um einen schnellen Restore
zu gewährleisten, werden die Daten nicht nur auf Band, sondern auch auf Festplatten in TSM gespeichert.
Damit sich der benötigte Festplattenplatz aber auf ein Mindestmaß beschränkt, wurde hier zusätzlich noch
die Deduplizierungsfunktion von TSM eingesetzt. Dadurch konnte der tatsächlich belegte Platz auf den
Storagesystemen um 75% reduziert werden. Um höchste Datensicherheit des Backups zu gewährleisten,
wird zusätzlich eine Kopie auf Band im neuen DRABS am RZG gespeichert.
Tivoli Landeslizenzvetrag LL3
Der im September 2008 abgeschlossene Landeslizenzvertrag für IBM-Softwareprodukte, mit dem auch
die TSM-Lizenzen und Support beschafft wurden, wird im September 2013 auslaufen.
Im Herbst 2012 wurden in einem ersten, konkret diesem Zweck gewidmeten Treffen, der Bedarf und die
Möglichkeiten für einen weiteren Nachfolgevertrag mit den interessierten bayerischen Hochschulrechenzentren und IBM diskutiert. Danach wurde der aktuelle Bestand erfasst und basierend auf den Erfahrungen der vergangenen Jahre eine detaillierte Trendanalyse für den zu erwartenden Fünfjahresbedarf erstellt.
Erwartungsgemäß konzentrierten sich die Anforderungen auf die Tivoli-Produktsuite, durch die die Bereiche Speicher-, Netz- oder Systemmanagement abgedeckt werden. Hier ist die landesweite Synergie am
größten. Die Hinzunahme von anderen Produkten hat sich nur bedingt bewährt, da sich IBM nicht dazu
bewegen ließ, diese Produkte in der gleichen sogenannten Austauschkategorie zu platzieren und der Bedarf nicht groß war. Dadurch ging viel an Flexibilität verloren. Die Universität Regensburg war zum Bei-
Datenhaltung
40
spiel der einzige Nutzer von Informix-Lizenzen. Die Hochschule wird nun die Lizenzen in Eigenregie
verlängern, das Produkt wird aber nicht Bestandteil eines neuen Landeslizenzvertrags. Anhand der Bedarfsmeldungen der Hochschulen von Ende 2012 wurde von IBM ein Informationsangebot erstellt, das
Grundlage für einen Großgeräteantrag (LL3) werden wird, der Anfang 2013 vorbehaltlich einer gesicherten Finanzierung gestellt werden soll.
4.2.3 Statistik
Ende 2012 waren in den
5 Libraries des Archiv- und Backupsystems
28 Petabyte, verteilt auf
14 Milliarden Dateien gespeichert. Täglich wurden auf die Systeme durchschnittlich
70 Terabyte neu geschrieben. Die Daten stammten von rund
8.000 Servern des MWN aus über
400 Einrichtungen der Münchner Hochschulen.
Im Vergleich zum Vorjahr sind Last und Datenmenge im Rahmen der Erwartungen, d.h. nicht schneller
als in den Vorjahren, weiter gestiegen. Es bleibt abzuwarten, ob sich dieser Trend fortsetzt, oder ob die
Archivdaten des SuperMUC das Wachstum wieder beschleunigen.
Hauptsächlich bedingt durch die 11.000 Kassetten, die Teil der Beschaffung des SuperMUC Backup- und
Archivsystems waren, ist die Anzahl der in den Libraries nutzbaren Kassetten stark gestiegen. Ende 2012
befanden sich 37.500 Kassetten in den Slots der 5 Libraries. Die Gesamtanzahl der Kassetten ist nur bedingt als Indikator für den Zuwachs tauglich, da die Kapazitäten der Kassetten je nach Technologie stark
variieren.
Jeder Rechner oder jeder Rechnerverbund, der auf das Archiv- und Backupsystem zugreifen will, muss
unter TSM als sogenannter „Node“ registriert sein. Die Anzahl der Nodes entspricht damit in etwa der
Anzahl der Systeme, die ihre Daten im Archiv- und Backupsystem ablegen. 2012 wurden 1.400 Nodes
neu registriert und 600 alte Nodes inklusive ihrer gespeicherten Daten gelöscht. Durch das explizite Löschen von Nodes sowie durch automatische Löschprozesse nicht mehr benötigter Daten wird dafür 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 bereitgestellter Server erlaubt es den Kunden, sich direkt
umfassend über den eigenen Datenbestand zu informieren. Gleichzeitig werden die Nutzer in regelmäßigen Abständen von diesem Server über die von ihnen verbrauchten Speicherressourcen via E-Mail informiert. Integriert sind Werkzeuge, die der betrieblichen Überwachung und Analyse der Systeme dienen.
Nutzer mit besonders auffälligem Datenprofil werden direkt angesprochen. Unter anderem um diese auffälligen Profile schnell zu erfassen wurde 2012 die Software TSM-Reporter beschafft (siehe Abschnitt
4.2.2).
Alle Kontaktdaten werden zusätzlich regelmäßig auf ihre Aktualität überprüft. Entsprechend den 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 2012 zeigen Abbildung 19
und 20.
41
Abbildung 19 Datenverkehr (GB pro Monat)
Abbildung 20 Datenumfang in TB
Der Archiv-Anteil am Datenbestand ist relativ statisch, d.h. es gibt nur wenige Änderungen an den Dateien im Archiv. Archivdaten werden in der Regel einmal ins Archiv übertragen und dort sehr lange aufbewahrt, im Fall der Langzeitarchivierung für Jahrzehnte. Der „Buckel“ der Archivkurve im Zeitraum September bis Dezember wurde durch den Aufbau der Zweitkopie im neuen Desaster Recovery Archiv- und
Backupsystem verursacht. Hier gab es vorübergehend drei Kopien der Archivdaten (eine im LRZ, eine im
TSM System des RZGs und eine im LRZ System am RZG), wobei die dritte Kopie im TSM System des
RZGs nach dem erfolgreichen Verschieben in das DR System gelöscht wurde.
Datensicherungen finden regelmäßig statt. Backupdaten werden daher häufig ins System geschrieben. Die
veralteten Backup-Daten werden automatisch aus dem Bestand gelöscht. Durch diese Dynamik erklärt
sich die im Vergleich zur Archivierung deutlich höhere Dateneingangsrate bei geringerer Steigerung des
Datenumfangs.
Die Entwicklung seit der Installation des ersten unabhängigen Archiv- und Backupsystems im Jahr 1995
zeigt Abbildung 21. Das Diagramm zeigt ein kontinuierliches exponentielles Wachstum des Datenbestands über die Jahre hinweg.
Datenhaltung
42
Abbildung 21 Speicherbelegung 1995 - 2012
4.2.4 Plattform für digitale Langzeitarchivierung
Veröffentlichungen in digitaler Form nehmen im Wissenschaftsbetrieb wie auch im gesellschaftlichen
Leben einen immer höheren Stellenwert ein. Oft wird, wie z. B. bei Dissertationen und bei amtlichen
Publikationen, auf ein gedrucktes Pendant ganz verzichtet. Während die Digitalisierung für die Nutzer
den Zugang und den Umgang mit der Information beschleunigt und insgesamt erleichtert, entstehen aus
organisatorischer, rechtlicher und technischer Sicht neue Herausforderungen. Die Objekte sollen nicht nur
verwaltet und gespeichert, sondern auch langfristig zugänglich gemacht werden. Diese Aufgabe wird
erschwert durch den raschen technologischen Wandel im Bereich der Hard- und Software und der 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 LZA-Managementsystems Rosetta der Firma Ex
Libris an der BSB ausgeweitet wurde. Dabei tritt das LRZ für die BSB als Dienstleister für die Langzeitarchivierung, das Bereitstellen von Online-Speicher, das Attended Housing von Clusterknoten und
Hosting von virtuellen Servern auf. Die langfristige Speicherung der Daten übernimmt bei allen Projekten
ein NAS-System und das Archiv- und Backupsystem des LRZ mit dem Softwarepaket Tivoli Storage
Manager (TSM). TSM verfügt über alle wesentlichen Funktionalitäten, die für Langzeitarchivsysteme
Voraussetzung sind. Das Gesamtsystem deckt damit alle wichtigen Bereiche eines langfristig funktionierenden Archivs ab und folgt dem allgemeinen „Open Archival Information Systems“-Referenzmodell
(OAIS).
Abbildung 22 und 23 zeigen die Entwicklung der Anzahl der Archivobjekte und des Datenvolumens des
Langzeitarchivs von Januar 2006 bis Januar 2013. Der starke Anstieg der Dateianzahl ab März 2009 ist
durch den Produktivbeginn der Archivierung der Google-Digitalisate (siehe Abschnitt 4.2.6) zu erklären.
Bisher wurden von der BSB mehr als 975 Millionen Objekte mit einem Datenvolumen von mehr als 459
TB am LRZ archiviert. Der Datenzuwachs im Jahr 2012 betrug ca. 210 Mio. Dateien mit einem Volumen
von ca. 76 TB. Noch im ersten Quartal 2013 wird die Anzahl der Objekte die Schwelle von 1 Milliarde
Datengrenze überschreiten. In Abbildung 23 ist dieser Anstieg weniger auffällig, da die Größe der einzelnen Google-Digitalisate im Vergleich zu den übrigen Digitalisaten eher gering ist. Die aus Sicherheitsgründen erstellte Zweitkopie auf einem weiteren Magnetband verdoppelt in der Praxis die Objektanzahl
und das Datenvolumen. Sie ist in den Diagrammen nicht berücksichtigt.
43
Abbildung 22 Objektanzahl im LRZ-Archiv
Abbildung 23 Datenvolumen im LRZ-Archiv
Die gespeicherten Daten werden auf Systemen aufbereitet, archiviert und als Webpräsenz bereitgestellt,
die zum überwiegenden Teil auf der virtuellen Serverplattform des LRZ betrieben werden. Zu diesen
Systemen gehören unter anderem die Verkündungsplattform Bayern, der Web Server der Bayerischen
Landesbibliothek oder ein Server, der die Volltextindizierung der Digitalisate steuert, um nur einige Beispiele zu nennen. Die Anzahl dieser am LRZ für das Münchner Digitalisierungszetrum der Staatsbibliothek gehosteten virtuellen Linux-Server ist im Jahr 2012 von 40 auf 76 angewachsen.
Im Folgenden werden die beiden aktuell prominentesten Projekte beschrieben. Auf der LRZ-Homepage
im Bereich Projekte (http://www.lrz.de/projekte_2012/forschung-daten/) finden sich weitere Details zu
diesem Thema.
4.2.5 Projekt Rosetta
Im Frühjahr 2010 hat sich die BSB für die Einführung des Langzeitarchivsystems Rosetta der Firma Ex
Libris als neue strategische Plattform für die Langzeitarchivierung in Bayern entschieden. Diese Entscheidung wurde auch dadurch beeinflusst, dass das bislang verwendete System Digitool der Firma Ex
Libris nicht mehr weiterentwickelt wird. Eine wesentliche Anforderung an das neue Langzeitarchivsystem Rosetta war der Anspruch, dass pro Tag mindestens 1.000 Bücher in das System eingefügt werden
können. Dies entspricht einem geschätzten Zuwachs des Datenvolumens von 100 TB pro Jahr. Mittelfris-
Datenhaltung
44
tig ist geplant den bisher archivierten Datenbestand (459 TB; 975 Mio. Dateien) nach Rosetta zu migrieren. Gegenüber der bisherigen Konfiguration werden neben den Bereitstellungsdaten auch die digitalen
Masterdateien auf einem Online-Speichersystem vorgehalten. Diese ambitionierten Pläne haben dazu
beigetragen, dass der bestehende Online-Speicher (NAS-System) der BSB im Oktober 2010 durch ein
performanteres und skalierbareres NAS-System ersetzt wurde. Die Bruttokapazität des NAS-Filers wurde
von 586 TB auf 730 TB erweitert. Das LRZ betreibt für die BSB die Systeminfrastruktur des Langzeitarchivsystems Rosetta (virtuelle Server, Online-Speicher und Archivspeicher).
Abbildung 24 Rosetta-Speicherarchitektur
Das Hauptaugenmerk des LRZ bezüglich Rosetta im Jahr 2012 galt der weiteren Verfeinerung des Speicherkonzeptes und der Umsetzung der Langzeitsicherungsaufgaben. Seitens Ex Libris wurden neben der
funktionalen Systemerweiterung und Fehlerbehebung zahlreiche Versuche unternommen, die geforderte
Tagesproduktion von 1.000 Büchern zu erreichen, was bisher noch nicht gelungen ist. Aufgrund von wiederholten Verzögerungen seitens Ex Libris erfolgte der Produktivgang erst im Sommer 2012 mit ausgewählten Kollektionen.
4.2.6 Projekt Google
Im Rahmen einer im Jahr 2007 entstandenen Public-Private-Partnership digitalisiert Google über einen
Zeitraum von mehreren Jahren mehr als 1 Million urheberrechtsfreie Druckwerke aus dem Bestand der
BSB. Die BSB erhält Kopien der Digitalisate, die am LRZ gespeichert, archiviert und über den OPAC der
BSB weltweit zugänglich gemacht werden. Das LRZ unterstützt die BSB in diesem Projekt als Dienstleister und ist für die Langzeitarchivierung der Digitalisate, das Housing von Clusterknoten für die Formatmigration als Vorbereitung für die Web-Bereitstellung, das Hosting des Speichersystems und das Hosting
virtueller Server für Archivierung und Web-Bereitstellung zuständig.
Konkret stellt das LRZ als interne und externe Schnittstelle virtuelle Server bereit, die sich um den Download, die Verarbeitung, Archivierung und Bereitstellung der Daten im Internet kümmern. Die Originaldateien, die die BSB von Google erhält, werden im Archiv- und Backupsystem des LRZ abgelegt. Die Dateien, die im Internet angeboten werden, werden am LRZ auf einem NAS-System gehostet. Die Umwand-
45
lung aller originalen Bilddateien in jeweils zwei Bilddateien mit niedriger Auflösung geschieht am LRZ
auf dem Linux Cluster. In Abbildung 25 sind die Infrastruktur sowie der Workflow schematisch dargestellt.
Abbildung 25 Workflow im Google Projekt
Aufgrund der guten Erfahrungen mit der Formatkonvertierung auf dem Linux-Cluster im Google-Projekt
wurde für ein weiteres Projekt der BSB die Konvertierung von hochauflösenden TIFF-Bildern in zwei
niedriger auflösenden JPEG-Formaten auf dem Linux-Cluster produktiv genommen. Weiterhin wurden
2012 die Konvertierungsroutinen auf das neue Batch-Processing System SLURM (früher SGE) umgestellt. Bis Ende 2012 wurden rund 840.000 Bücher heruntergeladen und verarbeitet, der Bestand an Archivdaten im Google-Projekt ist so auf fast 160 TB angewachsen. Der stagnierende Datenzuwachs im
Zeitraum von Februar 2011 bis Juli 2011 wurde dadurch verursacht, dass primär keine neuen Digitalisate
in das Archiv eingepflegt, sondern eine Vielzahl an Objekten im Archiv durch überarbeitete und verbesserte Versionen (z.B. Bildqualität und OCR) ausgetauscht wurde.
Abbildung 26 Archivierte Daten in TB
Datenhaltung
46
Ab dem Jahr 2012 steht ein Teil der digitalisierten Bücher auch als Farb-Image zur Verfügung. Für diese
Exemplare verdoppelt sich der Speicherbedarf und es ist notwendig, diese Bücher erneut von Google zu
holen und in den Langzeitarchivierungsprozess einzupflegen.
4.3
Datenbanken und Web-Schnittstellen für den Betrieb der Supercomputer am LRZ
Beim Betrieb der Hochleistungsrechner (Früher SGI, jetzt SuperMIC und SuperMUC) und des VMwareClusters fallen große Mengen Leistungs- und Abrechungsdaten an, die intern ausgewertet und teilweise
auch den Nutzern zur Verfügung gestellt werden. Die zur Auswertung allein nur für diese beiden Bereiche bereitgestellte Datenbankinfrastruktur umfasst derzeit 8 eigene Datenbankserver für HPC und einen
für das VMware-Cluster. Die Arbeiten daran beinhalten den Aufbau sowie die laufende Pflege dieser
Datenbanksysteme sowie den hausinternen Support bei Fragen und Problemen mit den darauf laufenden
Anwendungen. Vier der Datenbankserver sind im aktuellen Jahr neu hinzugekommen, also eine Verdopplung der benötigten Infrastruktur.
Zur Darstellung von Übersichten wie Statistiken und Betriebszustandsdaten wurden Schnittstellen zum
Content-Management-System Fiona des LRZ-Webservers geschaffen, die es erlauben, diese Daten auch
über den Webserver des LRZ abzurufen.
4.4
Online-Speicher
4.4.1 Konfiguration und Entwicklung im Überblick
Die NAS-Systeme am LRZ haben sich als Speicherplattform aufgrund ihrer Stabilität, Ausfallsicherheit
und hohen Datensicherheit durch die Spiegelung auf ein Replikationssystem seit mehreren Jahren bewährt und als strategische Plattform etabliert. Die rapide wachsenden Datenmengen erfordern die gute
Skalierbarkeit der eingesetzten Systeme. Abbildung 27 zeigt die Entwicklung der am LRZ betriebenen
NAS-Infrastruktur seit ihrer Einführung im Jahr 2005.
Abbildung 27 Links: Entwicklung Datenvolumen und Anzahl Festplatten in den Jahren 2005 bis 2012
Rechts: Entwicklung der Anzahl an Filer-Köpfen (Storage Controller)
In der linken Abbildung ist Ende 2011 ein sehr deutlicher Zuwachs zu erkennen. Diese Steigerung wird
durch die Inbetriebnahme des Speichersystems der Home-Verzeichnisse des SuperMUC bedingt. Die
NAS-Datenkapazität steigt um einen Faktor 4,5 von 2.000 TB auf über 9.000 TB an. Die Anzahl der
Festplatten wachsen um einen Faktor 2 auf 6.000. Im Jahr 2005 betrug das Bruttospeichervolumen der
gesamten NAS-Infrastruktur überschaubare 54 TB (ca. 350 Festplatten). Die Anzahl an Filer-Köpfen
(Storage Controller) ist im Zeitraum von 2005 bis 2012 von 5 auf 42 Filer-Köpfe angestiegen (Steigerungsfaktor: 10,5). Das Personal zur Betreuung der NAS-Systeme ist im gleichen Zeitraum nur um einen
Faktor 1,5 bis 2 gestiegen.
Abbildung 28 zeigt die Konfiguration der Speicherinfrastruktur aller Primärspeichersysteme (Produktivsysteme) inklusive der Replikations- und Backupsysteme. Zwischen Primär- und Replikationsspeicher-
47
systemen werden die Daten in der Regel asynchron, im VMware-Umfeld, wo die Verfügbarkeit eine besonders große Rolle spielt, werden die Daten synchron gespiegelt. Zur weiteren Erhöhung der Datensicherheit werden die Daten von den Replikationssystemen zusätzlich über NDMP (Network Data Management Protocol) auf Magnetbänder gesichert. Die Primär- und Replikationssysteme befinden sich in
getrennten Brandabschnitten des Rechnergebäudes.
Abbildung 28 Primärsysteme, Replikation und Backup
Ein Cluster von Filerköpfen (supernasNN rechts in Abbildung 28) liefert den Speicher für die Homeverzeichnisse der Nutzer des neuen Höchstleistungsrechners. Das Cluster besteht aus 12 Storage-Controllern
(FAS 6820) der Firma NetApp und verfügt in der ersten Ausbaustufe über ein Speichervolumen von brutto 3.456 TB. Das zugehörige Replikationssystem (nasrepNN) verfügt über 4 Storage Controllern (FAS
6820), denen eine Kapazität von 1.536 TB Brutto zur Verfügung steht.
4.4.2 Hochverfügbarer Speicher für virtuelle Server
Um die notwendige hohe Verfügbarkeit bei der Speicherversorgung der VMware-Infrastruktur zu erreichen, wird ein Speichersystem eingesetzt, das seine Daten synchron spiegelt und zusätzlich repliziert
(nas3170a/b). Als nutzbarer Speicherplatz standen VMware seit Frühjahr 2010 ca. 55 TB zur Verfügung.
In einem Speicherantrag, der im Frühjahr 2011 eingereicht wurde, wurde mindestens eine Verdopplung
der aktuellen Speicherkapazität dieses System angestrebt, um der steigenden Zahl an virtuellen Maschinen gerecht zu werden. Die Beschaffung der Speichererweiterung erfolgte im Frühjahr 2012. Der virtuellen Infrastruktur steht seitdem ca. 150 TB nutzbarer Speicherplatz zur Verfügung. Das in die Jahre gekommene Replikationssystem (nas6070r), das ursprünglich für den MWN-Speicher beschafft wurde und
übergangsweise auch für das hochverfügbare VMware-Speichersystem gedient hat, wurde durch ein neues System (nas6280r2) ersetzt. Dabei wurde zunächst ein zusätzlicher Spiegel aufgebaut und im Anschluss der alte Replikationsdatenbestand gelöscht. Abbildung 29 zeigt das hochverfügbare NAS-System
inkl. Replikations- und Backupsystem, das in räumlich getrennten Brandabschnitten aufgebaut und installiert wurde.
Im Rahmen des Hostings für das Dialogorientierte Serviceverfahren der Stiftung für Hochschulzulassung
ist eine analog aufgebaute Konfiguration (2 x NetApp FAS 3170, 50 TB) mit synchroner Spiegelung in
Betrieb.
Datenhaltung
48
Abbildung 29 Hochverfügbares NAS-System für VMware inkl. Replikation und Backup
4.4.3 MWN-Speicher
Das LRZ bemüht sich um die Bereitstellung von Speicherkapazitäten für alle Studierenden und Mitarbeiter der Hochschulen und stellt seit Mitte 2008 eine einfach zu bedienende, sichere und zentral administrierte Speicherlösung bereit. Durch eine enge Kopplung mit Verzeichnisdiensten verfügen alle Mitarbeiter und Studierenden sowohl über persönlichen Speicherplatz als auch über den Zugang zu Projektablagen. Gemeinsamer Projektspeicherplatz ermöglicht eine neue Art der Kooperation zwischen verschiedenen Einheiten, die bisher wegen der dezentralen Strukturen nicht möglich war. Weiteres Ziel ist die
Versorgung anderer hochschulweiter Dienste mit sicherem, hochverfügbarem Speicherplatz. Der sogenannte Speicher für die Wissenschaft oder MWN-Speicher wird – vor allem von Seiten der TU München sehr gut angenommen, was die stetig steigende Anzahl der eindeutigen Benutzer-Kennungen (ohne Funktions- und lokale Benutzerkennungen) mit simultanen Zugriffen zeigt (siehe Abbildung 30). Die Zugriffe
haben sich innerhalb der letzten beiden Jahre (2011/12) von 1.100 auf 2.800 simultane Zugriffe fast verdreifacht. Deutlich zu erkennen sind in den Diagrammen die betriebsschwachen Zeiten an den Wochenenden und zwischen Weihnachten und Neujahr.
Wegen des schnellen Wachstums mussten die Daten des Speichers für die Wissenschaft auf ein neues
Speichersystem verlagert werden. Dabei war die Herausforderung, die Unterbrechung für die Kunden
möglichst gering zu halten. Deshalb fand die Verlagerung an einem Feiertag im August statt. Die Daten
wurden bereits im Vorfeld im Hintergrund periodisch auf das neue Speichersystem gespiegelt. Am Umschalttag wurde der letzte Abgleich durchgeführt und die Konfiguration des neuen Speicherbereiches
angepasst. Auch das Replikationssystem wurde durch ein neues System ersetzt. Nach dem Datenumzug
des Primärsystems wurde der asynchrone Spiegel neu aufgebaut.
49
Abbildung 30 Durchschnittliche Anzahl simultan zugreifender Kennungen
Abbildung 31 Infrastruktur des Speichers für die Wissenschaft
Abbildung 31 zeigt die Zugriffswege und den strukturellen Aufbau des MWN-Speichers.
Hauptnutzer des MWN-Speichers war auch 2012 die TU München. Aber auch die LMU nutzt zunehmend
den MWN-Speicher, wenn auch noch nicht in dem Maße wie die TUM. Die organisationsübergreifende
Bereitstellung von Speicherplatz ist eine Herausforderung, die weit über die Grenzen des MWNs hinausgeht. In einigen Bundesländern wird bereits landesweit Speicher bereitgestellt. Gemeinsam mit dem DFN
wurde 2012 über einen föderierten Dienst nachgedacht, der bundesweit genutzt werden kann. Die Diskussion, an der sich das LRZ im Rahmen seiner Möglichkeiten beteiligt, wird 2013 fortgesetzt.
50
Datenhaltung
4.4.4 Sonstige Aktivitäten
Hochleistungs-NAS-Systeme für HPC-Anwendungen
Im Juni 2012 wurden die Homeverzeichnisse des SuperMUC und die Bereiche SCRATCH und WORK
vom temporären Speicherort auf dem Replikationssystem auf das Hauptsystem verlagert. Abbildung 28
(rechte Seite) zeigt die schematische Konfiguration, bestehend aus 12 Filerköpfen für das Primärsystem
und 4 Filerköpfen für das Replikationssystem.
Leider hat sich gezeigt, dass die neue Controller-Generation von NetApp (FAS 6280) aufgrund eines
Hardware-Problems häufiger ohne Vorwarnung abstürzen, bzw. einfrieren. Aufgrund des HardwareDefektes mussten bei allen 20 Controllern die Mainboards, Erweiterungsboard, SAS-HBAs und NVRAM-Karten getauscht werden. Auch die Stabilität der neusten Software-Version der NetApp Cluster
Mode System ließ anfänglich zu wünschen übrig. Diese Instabilitäten haben in der zweiten Jahreshälfte
erhebliche Personalressourcen gebunden und konnten erst im Januar 2013 endgültig behoben werden.
Das Linux-Compute-Cluster des LRZ verfügt über ein NAS-Speichersystem mit 300 TB Kapazität. Aufgrund der gestiegenen Performance- und Kapazitätsanforderungen wurde entschieden, die Daten auf das
neue Speichersystem für den SuperMUC zu konsolidieren. Die Planungen und Vorbereitungen dazu fanden Ende 2012 statt, die Datenmigration der 250 TB ist für Januar 2013 geplant. Das alte Speichersystem soll noch bis Ende März 2013 parallel betrieben werden, um gegebenenfalls auf Daten noch zugreifen zu können. Danach wird das System abgeschaltet und evtl. anderweitig verwendet.
Konsolidierung verschiedener Speicherbereiche
Da das 2007 beschaffte Speichersystem, bestehend aus einem Primärspeichersystem (2 x FAS6070) und
einem Replikationssystem (FAS6070) zum Jahreswechsel außer Dienst gestellt werden sollte, mussten
die Daten verschiedener Dienste, wie z.B. Exchange, VMware-Testumgebung und die Fakultät 11 der
LMU verlagert werden. Bei dieser Gelegenheit wurden die Daten der Fakultät 11 der LMU, welche als
Pilotkunde einen eigenen, gesonderten Speicherbereich hatte, in den Speicher für die Wissenschaft integriert.
Speicher für NFS-Dateidienste und Linux-Mailsysteme
Die in die Jahre gekommene Speichersysteme für die NFS-Dateidienste und der Linux-Mailsysteme wurden durch neue Speichersysteme ersetzt. Diese Geräte sind Systeme der ersten Stunde im damaligen Neubau in Garching. Im Zeitraum von August bis September 2012 wurden daher die Speicherbereiche
schrittweise auf das neue Speichersystem (nas6280b) verlagert. Aufgrund der Individualität der Speicherbereiche musste die Verlagerung schrittweise mit den Dienste-Administratoren geplant und durchgeführt
werden. Diese individuelle Betreuung hat einen hohen zeitlichen Aufwand bedeutet. Nach gründlicher
Vorplanung verlief die Verlagerung der Speicherbereiche für die NFS-Dateidienste und der LinuxMailsysteme problemlos. Es gab jeweils eine kurze Diensteunterbrechung von ca. 2 – 5 Minuten. Nach
der Verlagerung der Daten wurde die asynchrone Spiegelung auf ein ebenfalls neues Replikationssystem
aufgesetzt. Die alten Speichersysteme nas3050a, nas3050b und das angebundene Replikationssystem
r200 wurden im Oktober außer Dienst gestellt und abgeschaltet.
Insgesamt war das Jahr 2012 geprägt durch zahlreiche aufwändige Datenverlagerungen, die sowohl während der Planung, als auch bei der Durchführung einen hohen personellen Einsatz erforderten. Ein Großteil der in diesem Abschnitt beschriebenen Aktivitäten handelt von diesen Verlagerungen. Die raschen
Innovationszyklen in der IT und die damit bedingten häufigen Ersetzungen der Hardware wirken sich hier
besonders stark aus. Anders als bei der Ersetzung eines Rechners oder Rechner-Clusters kann das zu ersetzende Speichersystem erst abgeschaltet werden, wenn alle Daten, die darauf gespeichert waren, verlagert worden sind. Die Verlagerung dieser Daten verursacht immer wieder erheblichen Aufwand und zieht
sich durch die gesamte Geschichte seit Einführung der unabhängigen Datenhaltung Anfang der Neunziger
Jahre. Auch der nächste Abschnitt ist dafür ein gutes Beispiel.
AFS
Seit 1992 wurde am LRZ das verteilte Filesystem AFS (Andrew Filesystem) eingesetzt. AFS war in den
90er Jahren das zentrale Filesystem am LRZ, das von allen Diensten genutzt wurde. Im Rahmen des
TUM-Großprojekts IntegraTUM wurden auch die Alternativen für ein hochschulübergreifendes hochver-
51
fügbares Filesystem evaluiert. Bereits 2005 fiel dann die Entscheidung zu Gunsten einer NAS-basierten
Lösung. Seitdem wird an der Ablösung von AFS gearbeitet. Die tiefe Verwurzelung von AFS in zahlreiche Teilbereiche des LRZ-Dienstespektrums machte die Ablösung zu einem langwierigen Unternehmen,
das bis heute noch nicht gänzlich abgeschlossen ist. Nach und nach wurden die Speicherbereiche verschiedener Dienste aus AFS herausgelöst, zunächst der Mailbereich, der am wenigsten mit der speziellen
Filesystemarchitektur von AFS zurechtkam, dann die Daten der Compute-Cluster.
Mitte 2010 fand eine große Bereinigungsaktion nicht mehr oder kaum genutzter AFS-Homeverzeichnisse
und damit gekoppelt der AFS-Kennungen statt. Dadurch konnte die Anzahl der AFS-Kennungen von
vormals über 30.000 auf 2.300 reduziert werden. Mit der Einstellung des Betriebs des öffentlichen und
internen SUN-Cluster sind die Restdaten in AFS nur noch über einen speziellen FTP-Zugang erreichbar.
2012 konzentrierten sich die Migrationsarbeiten auf die Verlagerung der Web-Bereiche nach NAS. Die
Vorarbeiten dazu stellten sich einmal mehr als sehr zeitaufwändig heraus. Die Verlagerung der letzten
300 Webserver wird erst 2013 abgeschlossen werden können.
Bemerkenswert ist in diesem Zusammenhang auch die Stabilität des Systems. Natürlicherweise steigt die
Stabilität zwar mit dem Rückgang der Nutzung, trotzdem ist es nicht selbstverständlich, dass die teilweise
10 Jahre alte Hardware noch ohne größere Ausfälle funktioniert. Auch wird die komplexe Software, die
zum Betrieb von AFS nötig ist, seit dem Weggang des letzten AFS-Administrators Mitte 2012 nicht mehr
gepflegt.
Diverse Stromabschaltungen
Für die gesetzlich vorgeschriebene Sachverständigenprüfung der LRZ-Brandmeldesysteme und Brandmeldebekämpfungssysteme im Rechnergebäude mussten mehrere Rechnerräume stromlos geschaltet
werden. Um den Betrieb der Speichersysteme auch während der Stromabschaltung aufrecht zu erhalten
mussten mit hohem Aufwand die Systeme über eine provisorische Stromversorgung betrieben werden.
Eine zusätzliche Stromabschaltung musste aufgrund defekter Abgangskästen und Formstücke der Stromschiene im DAR1 durchgeführt werden. Auch hier wurde der Betrieb der Speichersysteme nicht unterbrochen. Die Sicherstellung des unterbrechungsfreien Betriebs während dieser Maßnahmen band zusätzliche Personalressourcen ebenso wie die schon beschriebenen Instabilitäten und Hardware-Probleme.
Diese Herausforderungen mussten zusätzlich zu den normalen Tagesaufgaben bewältigt werden. Die
Belastung für die Mitarbeiter war während des ganzen Jahres enorm hoch.
4.5
Daten- und Archivräume
Im Rechnerwürfel des LRZ steht für die Geräte des Archiv- und Backupbereichs nahezu ein gesamtes
Stockwerk des Altbaus mit 560 m2 Nutzfläche zur Verfügung, der sogenannte DAR0 (Daten- und 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. Die Dimensionierung erlaubte bisher eine optimale Aufstellung der
Geräte. Den meisten Raum nehmen 5 Bandbibliotheken ein. Neben den Bandbibliotheken wird der Raum
allerdings zunehmend für die Aufstellung der umfangreichen NAS-Plattenbasis (Replikatsysteme) genutzt. Anders als leistungsstarke Server haben Platten eine relativ geringe Leistungsaufnahme. Die durch
die Platten verursachte Wärmeentwicklung und damit Änderung der klimatischen Verhältnisse im Archivraum wird als vertretbar erachtet. Wie an vielen anderen Stellen auch, musste hier ein vernünftiger
Kompromiss zwischen Kosten und Nutzen gefunden werden.
Mit einer durchschnittlichen Leistungsaufnahme von unter 60 KW ist der Raum DAR0 ein Aushä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.
Datenhaltung
52
Abbildung 32 Daten- und Archivraum
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 33 Brandabschnitte im Rechnerwürfel
Durch die Gebäuderweiterung wurde auch die Anzahl der Brandabschnitte insgesamt erhöht. Dadurch
wurde es möglich, die Komponenten vieler wichtiger Dienste redundant aufzustellen, was vorher nicht
immer möglich war. Hochverfügbare Datenspeicher konnten so auf die Räume verteilt werden, dass der
Dienst, für den sie benötigt werden, bei Abschaltung kompletter Brandabschnitte nicht beeinträchtigt
wird. Bei der Aufstellungsplanung wurden dabei noch weitere Faktoren berücksichtigt, wie eine redundante Einbindung in die Klimainfrastruktur oder eine unterbrechungsfreie Stromversorgung (grüne Bereiche in Abbildung 33).
53
5 Internetdienste
5.1
E-Mail
5.1.1 Ersatz des Dienstes Mailout durch Postout
Anfang August wurde ein neuer Dienst zum Versenden von Mails für den Benutzerbetrieb freigegeben.
Im Unterschied zum bisherigen Mailout-Dienst können Mails beim neuen Postout-Dienst nur nach vorheriger Authentifizierung und nur mit Absenderadressen, für die der jeweilige Nutzer nutzungsberechtigt
ist, verschickt werden. Der neue Dienst ist dadurch wesentlich besser gegen missbräuchliche Nutzung
(wie Versand von Spammails) abgesichert. Ein weiterer Vorteil gegenüber dem Mailout-Dienst ist, dass
er weltweit nutzbar ist und nicht nur innerhalb des MWN bzw. nach Aufbau einer entsprechenden VPNVerbindung – eine Einschränkung, die insbesondere für die Nutzer von mobilen Geräten unbequem war.
Der bisherige Mailout-Dienst wird noch für eine gewisse Übergangszeit parallel zum neuen PostoutDienst verfügbar bleiben. Mittelfristig wird Mailout in etwas veränderter Form nur noch für lokale
Mailserver im MWN, aber nicht mehr für einzelne Benutzer angeboten werden.
5.1.2 Neuer Webmailer Roundcube
Grund für den Wechsel auf einen neuen Webmailer war, dass das bisher eingesetzte Produkt SquirrelMail
nicht mehr in ausreichender Weise weiterentwickelt wurde. Nach Sondierung der verfügbaren (freien)
Alternativen haben wir uns für Roundcube als neuen Webmailer entschieden, ein gut gepflegtes Produkt
mit einer modernen, intuitiv zu bedienenden Benutzeroberfläche. Der Roundcube-Betrieb wurde Anfang
Mai aufgenommen und nach einem zweimonatigen Parallelbetrieb mit SquirrelMail, während dem sich
die Benutzer an die neue Umgebung gewöhnen konnten, wurde der alte Webmailer Anfang Juli abgeschaltet.
Mit Roundcube ist es jetzt auch möglich server-side Filter anzulegen. D.h. E-Mails können direkt bei der
Auslieferung in die Mailbox gefiltert werden, ohne dass ein Client aktiv werden muss. Dadurch können
entsprechend markierte Spammails unmittelbar in den Spamordner verschoben werden.
Spammails, die nicht als solche markiert wurden und sich daher weiterhin im Posteingang befinden, können mit dem Spam-Button verschoben und gleichzeitig ans LRZ gemeldet werden. Diese E-Mails werden
dann vom LRZ untersucht und dienen der Optimierung der Spamabwehr.
5.1.3 Spezielle Markierung von Newslettern
Der neue Spam-Button von Roundcube wird von den Nutzern fleißig betätigt. Es zeigte sich dabei aber,
dass
 oft korrekt markierte Spammails gemeldet wurden (d.h., es wurde vom Nutzer kein Spamfilter
konfiguriert, der die E-Mails direkt in den Spamordner befördert),
 die meisten gemeldeten E-Mails (> 90%) sich als Newsletter herausstellten,
 nur sehr wenige E-Mails nicht ausreichend als Spam markiert wurden.
Um die Masse der gemeldeten E-Mails zu ordnen, wurde ein neues Verfahren zur Markierung der
Newsletter begonnen. Bei den meisten Newslettern handelt es sich nicht um solche, die der Nutzer explizit abonniert hat, sondern um Werbung von Firmen (E-Mail-Marketing). Landet ein Nutzer in der Datenbank einer solchen Marketingfirma, erhält er oft eine Vielzahl an Newslettern. Wir haben nun die IPAdressbereiche von inzwischen 75 Marketingfirmen ermittelt und markieren ihre Newsletter beim Empfang aus dem Internet mit einer extra Headerzeile „X-Newsletter-ISP: name“ anhand dieser IPAdressbereiche. Somit können auch die Newsletter analog zu Spammails in extra Ordner ausgefiltert
werden.
54
Internetdienste
5.1.4 Snowshoe-Spam
Der größte Teil des Spamaufkommens besteht aus Botnet-Spam, d.h. infizierte PCs verschicken mit spezieller Software die Spammails. Diese Art an Spam lässt sich inzwischen mit Hilfe der DNS-basierten
Blacklists von Spamhaus zum größten Teil direkt ablehnen. Dies scheinen auch die Spammer bemerkt zu
haben. War früher der Anteil des Spams auf 95% des Gesamtvolumens an E-Mails gestiegen, so haben
wir inzwischen vor allem tagsüber Zeiten, an denen sich Spam- und Ham-Mails die Waage halten.
Probleme bereiten inzwischen die Spammails, die über gephishte Accounts verschickt werden. Da diese
E-Mails somit von regulären Mailservern verschickt werden, kann man nicht einfach den Mailserver blockieren. Oft greift auch die struktur-basierte Erkennung der E-Mails (SpamAssassin) nicht mehr, da zum
Versand reguläre Mailprogramme verwendet werden. Solche E-Mails lassen sich nur inhaltsbasiert als
Spam identifizieren und diese Art der Erkennung ist wesentlich fehleranfälliger. Daher sind wir auf die
Meldungen bzgl. falsch markierter E-Mails unserer Nutzer angewiesen (s. Spam-Button von Roundcube).
Einen anderen Weg gehen die Spammer mit dem sogenannten Snowshoe-Spam. Hierbei mietet sich der
Spammer eine größere Anzahl an IP-Adressen und verschickt über jede IP-Adresse nur eine geringe Anzahl an Spammails, um sozusagen unter dem Radar der Spamalarmierung zu bleiben. Sind die IPAdressen „verbrannt“, d.h. tauchen sie doch in Blacklists auf, so zieht der Spammer zum nächsten IPAdressbereich weiter. Die Abwehr dieser Art von Spam wird noch nicht ausreichend durch Blacklists
unterstützt, so dass hier noch viel Handarbeit notwendig ist.
Bei den oben angesprochenen Newslettern hat sich herausgestellt, dass es Firmen gibt, deren Newsletter
zwar wie normale Marketingnewsletter aussehen, die aber mit Snowshoe-Methoden verbreitet werden, es
handelt sich also um normalen Spam. Andere Newsletterversender bewegen sich in der Grauzone zwischen Snowshoe-Spam und regulären Newslettern. Man sieht das daran, dass die Newsletter solcher Firmen extrem oft als Spam gemeldet werden. Da die Firmen sich aber anscheinend noch gerade auf der
legalen Seite befinden, können wir den Versand nicht blockieren, sondern nur obige Markierung zur nutzerseitigen Filterung bereit stellen.
5.1.5 Virenabwehr
Wie aus der Statistik weiter hinten zu ersehen ist, ist die Anzahl der pro Tag ausgefilterten vireninfizierten E-Mails relativ gering verglichen mit den großen Virenausbrüchen früherer Jahre. Trotzdem machen
vireninfizierte E-Mails seit einiger Zeit ziemlich Probleme. Insbesondere ein bestimmtes Botnet versucht
neue Rechner zu infizieren, indem es entweder E-Mails verschickt, die einen Link auf eine infizierte
Webseite enthalten, oder die E-Mails enthalten den Virus direkt in einem Anhang. Damit der Virenscanner diesen Virus nicht sofort feststellen kann, wird der Virus in kurzen Zeitabständen so modifiziert, dass
der Virenscanner eine neue Signatur zur Erkennung braucht. Da das Erstellen und Aktivieren einer Signatur mehrere Stunden dauert, nutzt das Botnet diese Zeit um große Mengen an vireninfizierten E-Mails zu
verschicken, die dann nicht ausgefiltert, sondern dem Benutzer zugestellt werden.
Um dies zu verhindern, wurde am LRZ eine Reihe von Signaturen entwickelt, die nicht versuchen, den
Virus selbst zu erkennen, sondern die Software mit der der Virus verschickt wird. Mit Hilfe dieser Signaturen werden die infizierten E-Mails als Spam markiert und können somit in den Spamordner ausgefiltert
werden. Leider ist das nicht für alle Viren möglichl, so dass jeder davon ausgehen muss, dass ein Anhang
einer E-Mail einen Virus enthalten kann, der nicht vom Virenscanner erkannt wird.
5.1.6 SRS – Sender Rewriting Scheme
Sender Policy Framework (SPF) ist ein Verfahren, bei dem im DNS beschrieben wird, von welchen IPAdressen E-Mails mit einer bestimmten Absenderdomain verschickt werden dürfen und wie mit E-Mails
umzugehen ist, die von anderen Mailservern kommen, z.B. diese ablehnen. Damit soll sichergestellt werden, dass Absenderdomains nicht gefälscht werden. Dieses Verfahren hat aber einige gravierende Nachteile, so dass es von der IETF nicht als Standard akzeptiert wurde. Der größte Nachteil ist, dass E-Mails
nicht mehr wie bisher weitergeleitet werden können, da die Absenderadresse dabei nicht verändert wird
und der weiterleitende Mailserver nicht in der Liste der erlaubten Mailserver enthalten ist. Die Absenderadresse muss daher vor der Weiterleitung so verändert werden, dass die Domain zum sendenden Mailserver passt. Dies ist mit dem Sender Rewriting Scheme (SRS) möglich.
55
Da einige ISPs, z.B. GMX und Google, SPF trotz der Nachteile einsetzen und daher vom LRZ weitergeleitete E-Mails entweder abgelehnt wurden oder im Nirwana verschwanden, hat sich das LRZ trotz seiner
ablehnenden Haltung gegenüber SPF dazu entschlossen, SRS für die weitergeleiteten E-Mails einzusetzen, um die Probleme für seine Kunden zu minimieren.
5.1.7 Einsatz von Puppet mit Subversion
Um eine so komplexe Umgebung wie das Mailsystem des LRZ von einem Team administrieren zu können, ist es notwendig, jeden Service vollständig zu beschreiben und für jede einzelne Konfigurationsänderung festzuhalten:
 Was wurde geändert?
 Wann wurde etwas geändert?
 Wer hat etwas geändert?
Aus dieser Dokumentation muss dann automatisch die Konfiguration des Services generiert, installiert
und auf aktuellem Stand gehalten werden. Dazu verwenden wir das Tool Puppet, mit dessen deklarativer
Sprache ein Service beschrieben wird. Diese Beschreibung und alle Änderungen werden zentral im Versionsverwaltungssystem Subversion gespeichert. Mit Hilfe dieser Daten installiert Puppet automatisch
alle benötigten Softwarekomponenten mit zugehöriger Konfiguration und überprüft in kurzen Zeitabständen den Ist- mit dem Soll-Zustand. Dadurch wird verhindert, dass undokumentiert lokale Änderungen an
einem Service vorgenommen werden. Auch im Extremfall der physischen Zerstörung des Mailsystems ist
nach Bereitstellung neuer Hardware in kürzester Zeit ein Desaster-Recovery durch die automatische Neuinstallation des Mailsystems möglich.
In 2012 wurde mit dem Aufbau dieses Administrationssystems begonnen und bereits ein Teil der Services
migriert. Bis Ende 2013 ist geplant alle Mailservices auf Linux-Basis über Puppet zu administrieren.
5.1.8 Maximale Mailgröße erhöht
Auf vielfachen Wunsch wurde die maximale Mailgröße im Juni 2012 von 30 auf 50 MByte erhöht, um so
den Versand von noch größeren Dokumenten zu ermöglichen. Für den Austausch größerer Dateien steht
der FTP-Server des LRZ zur Verfügung.
5.1.9 Statistiken
5.1.9.1
Spam- und Virenabwehr
Das Gros der Spam- und Virenmails wird bereits von den Postrelays, die für die Annahme von E-Mails
aus dem Internet zuständig sind, durch die dort implementierten Abwehrmechanismen abgewiesen. Die
angenommenen E-Mails werden von den Postrelays über die Mailrelays an ein Cluster von ScanRechnern weitergeschickt. Dort werden Virenmails ausgefiltert (und die Empfänger darüber informiert)
und die verbleibenden E-Mails markiert, ob es sich vermutlich um Spammails handelt oder nicht. Diese
Markierung kann dann dazu verwendet werden, die betreffenden E-Mails durch Konfiguration entsprechender Regeln in Roundcube oder im eigenen Mailprogramm auszufiltern.
In der folgenden Graphik ist die Entwicklung von ausgefilterten Virenmails, markierten Spammails und
regulären erwünschten E-Mails (Ham-Mails) für die Jahre 2006 bis 2012 graphisch dargestellt. Dabei
sind nur die E-Mails berücksichtigt, die aus dem Internet angenommen wurden, also ohne die abgewiesenen Spam- und Virenmails. Wie man sieht, steigt der Anteil der Ham-Mails seit Jahren nur relativ langsam an, während der Anteil der Spammails in den letzten Jahren auf gleichem Niveau verharrt. Der Anteil
an Virenmails ist so klein, dass man ihn in der Graphik ab 2008 nicht mehr erkennen kann. Die Werte
liegen bei ca. 87 erkannten Viren pro Tag (Vorjahr: 95).
Internetdienste
56
7.000.000
6.000.000
5.000.000
4.000.000
Ham
3.000.000
Spam
Viren
2.000.000
1.000.000
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
0
Abbildung 34 Monatliches Ham-, Spam- und Virenaufkommen in den Jahren 2006 bis 2012
5.1.9.2
Relaydienst
Am Übergang vom Internet in das Münchner Wissenschaftsnetz (MWN) ist an den Routern der Port für
das SMTP-Protokoll für fast alle Rechner gesperrt. Nur einige ausgewählte Mailserver – neben den Postrelays 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 Relay-Server erledigt.
Den Relay-Service des LRZ nehmen zurzeit 170 Mailserver im MWN mit insgesamt 440 verschiedenen
Maildomains in Anspruch. Die auffällige Abnahme an Servern und Domains bei der TUM ist bedingt
durch die Migration auf den zentralen Exchange-Server.
Einrichtung
andere Hochschulen und hochschulnahe Einrichtungen
Gesamt
5.1.9.3
Mailserver
Domains
im MWN
53 (58)
81 (94)
36 (31)
115 (117)
195 (219)
130 (120)
170 (183)
440 (456)
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/IMAPServer 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 2012 waren am LRZ 216 (Vorjahr: 220) virtuelle Mailserver eingerichtet. Eine Aufteilung auf die
Hauptnutzer ist der folgenden Tabelle zu entnehmen. Auch hier ist an den Zahlen die Migration der TUM
auf den Exchange-Server zu sehen.
Einrichtung
Bayer. Akademie der Wissenschaften (inklusive LRZ)
Gesamt
5.1.9.4
57
virtuelle
Mailserver
Domains
90 (93)
44 (54)
40 (38)
42 (35)
144 (137)
99 (110)
79 (77)
46 (46)
216 (220)
368 (370)
POP/IMAP-Messagestores
Die Anzahl der Mailboxen an den POP/IMAP-Servern war aufgrund der verstärkten Nutzung des
Exchange-Dienstes etwas rückläufig. Ende 2012 gab es 108.833 Mailboxen (Vorjahr: 116.077). Nachfolgend eine Aufteilung nach Server bzw. Benutzergruppen:
Anzahl
Benutzer
POP/IMAP-Server für …
… Mitarbeiter der vom LRZ bedienten Einrichtungen (Mailserver „mailin“):
8.317
7.811
556
Hochschule München
267
andere bayerische Hochschulen
41
andere wissenschaftliche Einrichtungen
3.006
… Mitarbeiter und Studenten der TU München (Mailserver „mytum“)
… Studenten der Ludwig-Maximilians-Universität München (CampusLMU)
(inkl. Mitarbeiter, die ihre CampusLMU-Mailadresse behalten haben)
… Studenten anderer Münchner Hochschulen
Gesamt
5.1.9.5
19.998
30.532
56.274
2.029
108.833
Weiterleitungsservice
Der oben bereits erwähnte Forwarder, der für die Verteilung von E-Mails an den richtigen Messagestore
zuständig ist, übernimmt neben individuell eingerichteten Weiterleitungen auch einen 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.
Einrichtung
5.1.9.6
Weiterleitungen
26.110
5.100
Gesamt
31.210
E-Mail-Verteilerlisten
Das LRZ bietet seinen Nutzern die Möglichkeit eigene E-Mail-Verteilerlisten einzurichten (auf Basis des
Programms Mailman). Ende 2012 gab es 714 Listen (Vorjahr: 612), die sich wie folgt verteilten:
Internetdienste
58
E-MailVerteilerlisten
Einrichtung
5.2
183
363
119
49
Gesamt
714
Exchange
Beim Exchange-Dienst war auch in 2012 ein starkes Wachstum zu verzeichnen. Im Zeitraum November
2011 bis November 2012 kletterte die Nutzerzahl um ca. 8.500 auf ca. 23.500 und der NettoSpeicherbedarf hat sich von 2 auf knapp 4 TByte nahezu verdoppelt (brutto wird wegen des zusätzlichen
Bedarfs für Replikate und Snapshots sogar das 3- bis 4-Fache davon benötigt).
Um der anhaltend großen Nachfrage nach Exchange gerecht werden zu können, wurde gemeinsam mit
den für die Speichersysteme zuständigen Kollegen ein Nachfolgesystem konzipiert, ausgeschrieben, beschafft und Ende des Jahres in Betrieb genommen, inkl. Migration der Nutzer. Da sich das bisherige System – mit virtuellen Mailbox-Servern und einem über iSCSI angeschlossenen NAS-Filer – im Betrieb
leider als wenig fehlertolerant gegenüber Netzstörungen erwiesen hat, wurde nun eine Konfiguration mit
physischen Mailbox-Servern und direkt daran angeschlossenem SAS-Speicher gewählt. Das neue System
ist für bis zu 40.000 Benutzer mit einem Speicherbedarf von bis zu 20 TByte (netto) ausgelegt.
Im Jahresverlauf 2012 konnte auch eine große Erweiterung der automatischen Provisionierung für
Exchange aus den Identity-Management Systemen der Kunden in Betrieb genommen werden. Neben der
Treiberunterstützung für die Anlage von Benutzern wird jetzt auch die Anlage von Funktionsmailboxen
zusammen mit ihren Berechtigungsgruppen unterstützt. Damit ist es jetzt möglich neben den klassischen
Benutzermailboxen auch gemeinsam genutzte Mailboxen (shared Mailboxen), Raum- und Gerätemailboxen (Room- und Equipment-Mailboxen) sowie Exchange-Verteilerlisten anzulegen und zu nutzen. Die
Funktionsmailboxen und Verteilerlisten haben zudem den Vorteil, dass sie spezielle Berechtigungskonzepte aufweisen, die z.B. den Zugang und die Nutzung zu den Mailboxen begrenzen können oder den
Kalender veranlassen auf Terminanfragen automatisch zu antworten.
5.2.1 Statistik zur Nutzung des Exchange-Dienstes
Wie eben bereits erwähnt, sind die Benutzerzahlen bei Exchange im Jahr 2012 stark angestiegen. Ende
2012 gab es auf dem Exchange-Cluster 23.834 Mailboxen (Vorjahr: 15.750), die sich wie folgt verteilten:
ExchangeMailboxen
Domains
1.110
22.277
447
39
77
9
Gesamt
23.834
125
Einrichtung
5.3
Sharepoint
SharePoint ist zum einen die Ergänzung der Groupwarelösung von MS Exchange, da hier die public Folder entfallen sind und diese durch SharePoint ersetzt wurden. Zum anderen bietet SharePoint die Möglichkeit, für Gruppen die Zusammenarbeit zu verbessern, um z.B. gemeinsam an Dokumenten zu arbeiten
oder die Zusammenarbeit über Gruppenkalender, Besprechungsbereiche, Benachrichtigungen, Wikis oder
gemeinsame Aufgaben zu organisieren. Der Zugriff auf die Ressourcen erfolgt webbasiert.
59
Es gab zahlreiche Anfragen in 2012 für die Nutzung des Dienstes, es wurden auch einige Testsites aufgebaut, aber nur drei Einrichtungen waren bereit den kostenpflichtigen Dienst zu beauftragen. So werden
momentan sechs Sites für zahlende externe Kunden betrieben.
Der interne Nutzerkreis umfasste zum Ende des Jahres 2012 neben mehreren Sites für die Gruppenkoordination, Ausbildung und Hotline auch Sites zur Koordination mit externen Dienstleistern des LRZ für
den neuen Höchstleistungsrechner SuperMUC.
In 2012 wurde das Backup um den Data Protecton Manager DPM erweitert, wodurch nun auch einzelne
Objekte innerhalb der Sites wiederhergestellt werden können. Mit dem Release von MOSS 2013 im
Sommer 2012 haben die ersten Tests der neuen Version begonnen.
5.4
Webhosting
5.4.1 E-Learning
Die laufenden E-Learning-Projekte für TUM und LMU wurden mit Unterstützung und Beratung des LRZ
weiter ausgebaut. Dabei lag einer der Schwerpunkte bei der technischen Beratung und der Planungsmithilfe. Insbesondere beim Moodle-Team der TUM musste aufgrund personeller Engpässe der produktive
Betrieb der E-Learning-Plattform besonders sorgfältig erfolgen. Dank der vorsichtigen Planung kam es
im Betriebsjahr auch zu keinen größeren Störungen. Unterstützung wurde auch bei der zunächst probeweisen Bereitstellung eines Video-Konferenzsystems ("Adobe Connect") in Zusammenarbeit mit dem
DFN geleistet. Bei der LMU wurde unter anderem auch bei der Erstellung einer Verfahrensbeschreibung
zum Datenschutz für die Moodle-Instanzen mitgewirkt. Außerdem wurden die Instanzverantwortlichen
der Moodle-Server bei Upgrades durch Beratung und Bereitstellung zusätzlicher Backups unterstützt.
5.4.2 TUM-Portal
Für die TUM wurde zu dem bisherigen Typo3-Webhosting-Projekt ein auf dieses Rahmenkonzept aufsetzendes Sonderprojekt begonnen. Es handelt sich dabei um den Betrieb des zentralen Webservers der
TUM, der Zug um Zug in die Webhosting-Umgebung am LRZ migriert werden soll. In einem ersten
Schritt wurde dazu Mitte des Jahres die Betriebsumgebung am LRZ aufgesetzt, so dass bereits ein erster
Teil-Umzug der zentralen TUM-Website erfolgen konnte. Die TUM will nach und nach die bisher selbst
gehostete Portal-Lösung auf die LRZ-Systeme umziehen, einzelne Teilbereiche liegen bereits zur Entwicklung am LRZ.
5.4.3 Userweb und Research
Alle gehosteten persönlichen Homepages (ungefähr 650), die bisher über den externen Webserver des
LRZ erreichbar waren, wurden im September 2012 auf einen eigenen Webserver (userweb.mwn.de) migriert. Dabei wurden gleichzeitig auch die zugehörigen Webdaten aus dem nicht mehr unterstützten Dateisystem AFS nach NFS umgezogen. Ziel des Umzugs war insbesondere auch, eine klarer erkennbare
Trennung zwischen dem Webauftritt des LRZ und den persönlichen Seiten der Nutzer zu erreichen, die
bei der Verwendung des gleichen Domainnamens bisher nicht gegeben war.
5.4.4 Downloadbereiche zur Softwareverteilung
Für den Download von Softwarepaketen (ISO-Images, ZIP-Files, etc), die vom LRZ im MWN bereitgestellt werden, wurde ein Downloadserver bereitgestellt. Die zuvor relativ unterschiedlichen Methoden
zum Download von Software wurden durch diesen Downloadserver stark vereinheitlicht und kundenfreundlicher realisiert. Der früher viel verwendete Download per FTP war im Kontext von dezentralen
Firewalls zunehmend problematisch. Durch die Umstellung auf den Download per HTTP-Protokoll treten
für die Anwender wesentlich weniger Probleme auf. Auf der Seite der Anwendungsbetreuer am LRZ, die
Softwarepakete für den Download bereitstellen, wurde durch die Inbetriebnahme eines Gateway Servers
für diesen Zweck auch eine einheitliche Transferschnittstellen zur Verfügung gestellt.
Internetdienste
60
5.4.5 Neuauflage des Webauftritts der BAdW
Die BAdW plant für 2013 eine vollständige Neuauflage des bestehenden Webauftrittes. Dieser wird wie
auch bisher im Content-Management-System Fiona erstellt werden. Die Entwicklung innerhalb von Fiona
wurde an eine externe Firma vergeben (Oestreicher und Wagner). Der gesamte Betrieb wird am LRZ
ablaufen. Das dazu notwendige Webhosting-Konzept wurde dem Bedarf entsprechend am LRZ konzipiert
und bereitgestellt, dazu wurden u.a. drei neue Maschinen eingerichtet, die das CMS, die dazugehörige
Datenbank und eine Suchmaschine aufnehmen werden. Weiterhin gehört eine separate Datenbank der
BAdW zum System, die die Daten der Mitarbeiter, Projekt- und Pubikationslisten sowie Termine enthält
und die in die neue Website eingebunden werden soll.
Neben der serverseitigen technischen Beratung für dieses Projekt erfolgte auch eine umfangreiche Beratung zum Konzept des Webauftrittes selber, u.a. im Hinblick auf Nutzbarkeit und Bedienung sowie Barrierefreiheit.
In der folgenden Abbildung ist die Konfiguration der am LRZ betriebenen Komponenten des neuen
BAdW Webauftritts und ihre Integration in das allg. Webserverkonzept des LRZ dargestellt.
Abbildung 35 Konfiguration des BAdW Webauftritts
5.4.6 Redesign des Webauftritts des LRZ
Anlässlich der Inbetriebnahme des SuperMUC wurde auch das Layout des Webauftritts des LRZ grundlegend überarbeitet und modernisiert, wobei die bessere Erreichbarkeit der Inhalte mit mobilen Endgeräten im Fokus stand.
5.4.7 Webhosting-Statistik
Auf die zentralen Webserver am LRZ wurde im Jahr 2012 durchschnittlich ca. 86 (Vorjahr: 67) Millionen
Mal pro Monat zugegriffen. Diese Zahl ist allerdings aus mehreren Gründen nur bedingt aussagekräftig.
Zum einen ist eine echte Zählung der Zugriffe gar nicht möglich, da auf verschiedenen Ebenen CachingMechanismen eingesetzt werden (Browser, Proxy). Andererseits werden nicht Dokumente, sondern „http-
61
Requests“ gezählt. Wenn also z.B. eine HTML-Seite drei GIF-Bilder enthält, so werden insgesamt vier
Zugriffe registriert.
Die Zugriffe auf TUM-Webserver stiegen nochmals um ca 50%, nachdem sie sich bereits von 2010 auf
2011 verdoppelt hatten. Das liegt haupsächlich an TUM-Moodle, für das 2012 das erste vollständige Betriebsjahr war (Beginn war SS 2011). Hinzu kommt die Verlagerung von www.tum.de ans LRZ.
Die folgende Tabelle zeigt die durchschnittliche Zahl der Zugriffe und den durchschnittlichen Umfang
der ausgelieferten Daten pro Monat; die Daten sind nach den vom LRZ betreuten Bereichen aufgeschlüsselt. Zusätzlich wird die Zahl der Seitenaufrufe, das ist die angeforderte Zahl der „echten“ Dokumente,
genannt. Als echte Dokumente gelten dabei Textdokumente, also keine Bilder oder CGI-Skripte.
Server
Zugriffe
Seiten- Datenaufrufe umfang
Mio. GByte
11,47
4,04
2415
5,68
1,79
292,1
53,82
12,75
3346,9
Einrichtungen im Münchner Hochschulnetz
2,75
0,93
73,2
Einrichtungen im Münchner Wissenschaftsnetz
3,38
0,73
299,4
0,77
0,17
152,5
8,8
0,72
783,6
86,67
21,13
7362,7
Sonstige
Gesamt
Tabelle 8: Monatliche Zugriffe auf die Webserver am LRZ
Ende 2012 unterhielt das LRZ 18 Webserver für eigene Zwecke. Für Hochschulen und hochschulnahe
Einrichtungen wurden insgesamt 1.142 (Vorjahr: 921) Webserver betrieben.
Einrichtung
Webserver Webserver
2012
2011
18
14
105
127
863
615
28
30
Einrichtungen aus dem Münchner Hochschulnetz
(z.B. Stiftung Maximilianeum)
21
29
Einrichtungen aus dem Münchner Wissenschaftsnetz
(z.B. Zoologische Staatssammlung München)
35
35
Internetdienste
62
Andere (z.B. Bayerisches Nationalmuseum)
72
71
Gesamt
1142
921
Tabelle 9: Anzahl gehosteter Webserver
5.5
Serveradministration und Applikationsunterstützung
Der Betrieb von Serversystemen für Internetdienste erfordert eine Reihe von Arbeiten, die inhaltlich eher
zum Betriebssystem oder zur systemnahen Software gehören, die aber auf das Applikationsportfolio am
jeweiligen Serversystem zugeschnitten sind. Ob dabei das Serversystem eine physische Maschine ist oder
aber eine virtuelle, spielt auf dieser Ebene kaum eine Rolle. Zu diesen Aufgaben gehören beispielsweise
 die Auswahl und Anpassung des erforderlichen Betriebssystemumfangs, je nach den Voraussetzungen der geplanten Anwendungen,
 die Deaktivierung von nicht benötigten Netzdiensten aus Sicherheitsgründen und weitere Sicherheitsmaßnahmen wie Zugangsbeschränkungen, OS-Hardening und Security-Patches,
 die Überwachung der Verfügbarkeit, der Performance und der Funktion auf System- und Applikationsebene,
 die Messung und geeignete Aufzeichnung der Systemauslastung unter Berücksichtigung der Erfordernisse der Applikationen zum Tuning und zur proaktiven Ressourcenplanung,
 die Erstellung von Betriebs- und Notfallanleitungen für Anwender, Operateure, Dienst- und Systemadministratoren,
 die Unterstützung und Beratung der mit der Applikation betrauten Mitarbeiter, um eine optimale
Nutzung des Systems zu erreichen sowie
 die Fehlersuche an der Schnittstelle zwischen Applikation und Betriebssystem.
Da diese Systemadministration sowohl mit dem eigentlichen Rechnerbetrieb (Inbetriebnahme und sichere
Außerbetriebnahme von Systemen, Installation und Update des Betriebssystems, Firmwareupdates, Anbindung ans Rechnernetz, hardware- und netznahe Funktionsüberwachung) als auch mit der Applikationsadministration eng verwoben ist, können diese Aufgaben im einen oder im anderen Bereich angesiedelt sein, und es ist in jedem Fall eine enge Zusammenarbeit erforderlich. Die Ansiedlung beim Rechnerbetrieb bietet sich an, wenn die Applikationen von den Endbenutzern oder von den Kunden des LRZ eingebracht werden, wenn eine hohe Anzahl gleichartiger Systeme vorliegt oder wenn die Applikationsadministratoren dem Betrieb organisatorisch benachbart sind. Bei den Internetdiensten mit ihrem eher individuellen Applikationsprofil hat es sich bewährt, die Systemadministration organisatorisch im Umfeld der
Applikationen anzusiedeln.
5.5.1 Serveradministration in BDS
Der Abteilung BDS oblag Ende 2012 die Administration folgender Serversysteme:
 62 (Vorjahr 52) virtuelle Maschinen mit Linux-Betriebssystem
 33 (Vorjahr 35) physische Maschinen mit Linux-Betriebssystem
 7 (Vorjahr 11) physische Maschinen mit Solaris-Betriebssystem
 73 (Vorjahr 81) physische Serversysteme für die IT-Infrastruktur des Bibliotheksverbundes Bayern
 100 Systeme mit Windows-Betriebssystem
Diese Maschinen wirken im Umfeld der Webservices (Webserver, Content-Management, verschiedene
Backendserver), der Datenbanken, der Lizenzverwaltung und weiterer Netzdienste (FTP, Radius,
Groupware). Sie beherbergen auch einige Dienste der Rechnerüberwachung und -steuerung (Nagios, Zugangsgateways) sowie des Netzmanagements und der Netzüberwachung.
Bei den virtuellen Systemen liegt der Rechnerbetrieb bei der Betreibergruppe der VMware-Systeme in
der Abteilung HLS; bei den physischen Systemen werden die Maschinen von den Systemadministratoren
auch betrieben.
63
Im Jahr 2012 sind neben den oben erwähnten permanenten Aufgaben im Rahmen des Systemmanagement
auch viele Einzelprojekte durchgeführt worden. Im Folgenden eine Auswahl von Einzelprojekten aus dem
Jahr 2012 im Kontext des Serverbetriebs.

MySQL Server
Inbetriebnahme von weiteren virtuellen Maschinen für MySQL Server, u.a. für Content Management, Accounting und als DB-Server im LAMP Stack. Einige bereits vorhandene MySQL
Server VMs wurden grundlegend überarbeitet und an geänderte Erfordernisse angepasst.

Maßnahmen zur Außerbetriebnahme von AFS
Inbetriebnahme neuer Maschinen als Nachfolgesysteme für Maschinen die stark mit AFS verbunden sind. Bei dem Austausch der Systeme war in vielen Fällen auch eine weitgehende Änderung des Betriebskonzepts der betroffenen Dienste notwendig um den Dienst im geänderten Environment sinnvoll zu betreiben.

FTP-Server
Durch die Außerbetriebnahme von AFS gewinnt der FTP-Server des LRZ als Schnittstelle zu den
Daten auf den diversen Filesystemen wieder mehr Bedeutung. Der FTP-Server wurde deshalb
passend zu den laufend dazukommenden Anforderungen schrittweise weiter optimiert.

Server Zugangskonzept
Das Server Zugangskonzept, das zuvor hauptsächlich auf AFS gestützt war, wurde auf das LRZSIM Environment umgestellt und vereinheitlicht. Durch die Änderung des Zugangskonzepts
wurden auch einige Voraussetzungen zur Erfüllung der LRZ Sicherheitspolicies geschaffen.

Verlagerung von Diensten auf virtuelle Maschinen
Wie bereits in früheren Jahren wurden weitere Dienste von realer Hardware auf virtuelle Maschinen unter VMWare verlagert. Im Rahmen der Verlagerung fand teilweise auch ein Wechsel des
Betriebssystems von Solaris nach Linux statt.
5.6
Streamingserver
Das LRZ betreibt seit 2001 einen Streamingserver. Die Nutzung dieses Servers hat in den letzten Jahren
kontinuierlich zugenommen. Dies gilt insbesondere für die Menge des dafür speziell aufbereiteten Videomaterials. Insgesamt liegen derzeit auf dem Streamingserver mehrere tausend Filmbeiträge mit einem
kumulierten Datenvolumen von 2,3 Terabyte.
Die einzelnen Filme sind meist Aufzeichnungen von Vorlesungen oder Vorträgen mit einer Länge von
60-90 Minuten, aber auch kürzere Lehrvideos, die zum Beispiel die Ausbildung in der Medizin unterstützen. Je nach Dauer und gewählter Auflösung bzw. Bildgröße ist ein typischer Filmbeitrag zwischen
200 und 700 MByte groß.
Der ursprüngliche Streamingserver basiert auf QuickTime und für die Wiedergabe der Medieninhalte ist
das QuickTime-Plugin notwendig. Für eine spezielle Anwendung, die für das Videoonline-Angebot der
LMU entwickelt wurde und die mit Flash realisiert wurde, wird ein Flash-Streamingserver benötigt. Ende
2010 wurde deshalb zusätzlich ein Flash-Streamingserver von Wowza Media Systems aufgebaut, der seit
dem Wintersemester 2010/2011 in Produktionsbetrieb ist. Mittlerweile ist die Nutzung des FlashStreamingservers stark angewachsen. Nahezu zu jeder Tageszeit sind am Server zwischen 50 und 150
gleichzeitige Streams zu beobachten. Der Wowza-Server kann neben Flash-Videos (flv) auch MPEG-4Videos (mp4) ausliefern, die für den QuickTime-Streamingserver erstellt wurden. Dadurch brauchen
Aufzeichnungen nur einmal geeignet kodiert und können über beide Streamingserver verteilt werden.
Netzdienste für Institutionen
64
6 Netzdienste für Institutionen
Das Münchner Wissenschaftsnetz (MWN) verbindet vor allem Standorte der Ludwig-MaximiliansUniversitä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 WeihenstephanTriesdorf miteinander. Es wird aber auch von anderen wissenschaftlichen Einrichtungen (u. a. MaxPlanck-Gesellschaft, Fraunhofer-Gesellschaft, Kunst-Hochschulen, Museen) mit genutzt. Das Münchner
Wissenschaftsnetz bildet die Grundlage für die Kommunikation und Kooperation innerhalb und zwischen
den angeschlossenen Institutionen sowie mit Kooperationspartnern in Deutschland, Europa und auch
international.
Auf Basis der Infrastruktur des MWN werden Dienste sowohl für Institutionen als auch für Endanwender
erbracht. In diesem Kapitel werden neben der Struktur und den wesentlichen Änderungen im MWN die
Netzdienste für Institutionen (DNS, DHCP, Radius, Netzkomponenten-Beratuung) sowie unterstützende
Infrastrukturdienste (Netzmanagement, Telefonie, SLB, IPv6, Multiplexer, etc.) sowie wissenschaftliche
Projekte im Bereich KOM vorgestellt.
Die Netzdienste für Endanwender werden im nächsten Kapitel präsentiert.
6.1
Struktur und Betrieb des Münchner Wissenschaftsnetzes (MWN)
Die Standorte der angeschlossenen Institutionen sind insbesondere über die gesamte Münchner Region (i.
W. Münchner Stadtgebiet, Garching, Großhadern/Martinsried und Weihenstephan) verteilt, es gibt aber
auch weitere Standorte in Bayern. Abbildung 36 gibt einen Überblick über die räumliche Ausdehnung des
MWN. Die Lage von Standorten, die außerhalb des Münchner Stadtgebietes liegen, ist in der Abbildung
nicht maßstabsgetreu dargestellt, sondern lediglich schematisch (Himmelsrichtung) angedeutet.
Derzeit sind an das MWN mehr als 440 als Unterbezirke bezeichnete Gebäudegruppen angebunden und
es werden mehr als 100.000 Geräte über das MWN versorgt, wobei während des Semesters die Anzahl
der mobilen Geräte überwiegt. Die Größe der zu versorgenden Areale ist sehr unterschiedlich; sie reicht
von einem einzelnen Gebäude bis zu einem gesamten „Campusbereich“ (z.B. Garching, Weihenstephan)
mit mehr als 30 Gebäuden und mehr als 12.500 angeschlossenen Endgeräten. Derzeit sind bereits 57 Studentenwohnheime mit insgesamt mehr als 12.600 Wohnheimplätzen am MWN angeschlossen.
Abbildung 37 zeigt die Ausdehnung und Größe des MWN auf einer Karte. Die Nadeln repräsentieren
dabei die Unterbezirke. Sind mehere Unterbezirke an einem Ort so werden diese in einem Kreis zusammengefasst und die Zahl gibt an wie viele Unterbezirke zusammengefasst wurden. Weitere Informationen
zu dieser Darstellung finden sich in Abschnitt 6.9.2.1.
Das LRZ ist für das gesamte Backbone-Netz und einen Großteil der angeschlossenen Institutsnetze 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.
65
Abbildung 36 Räumliche Ausdehnung des Münchner Wissenschaftsnetzes (nicht maßstabsgerecht)
Etwas genauer lässt sich diese Realisierung wie folgt beschreiben:
 Die Router werden über das Backbone-Netz miteinander verbunden und bilden den inneren Kern
des MWN. Die Verbindungsstrecken des Backbone-Netzes sind je nach Nutzungsgrad verschieden ausgeführt. Im Normalfall sind die Strecken Glasfaserverbindungen, die langfristig von der
Deutschen Telekom und M-net angemietet sind. Auf den Glasfaserstrecken wird mit 10 Gbit/s
übertragen. Die Verbindung der Strecken übernehmen fünf Backbone-Router, die untereinander
aus Redundanzgründen mehrere Ringe bilden (vgl. Abbildung 40). Netze mit einer geringen Zahl
von Endgeräten werden überwiegend mit SDSL-Verbindungen (bis zu 20 Mbit/s) von M-net oder
der Telekom oder über WLAN-Verbindungen auf Basis von IEEE 802.11a, g oder n (bis zu 150
Mbit/s) angebunden. Das Backbone-Netz wird genauer im folgenden Abschnitt beschrieben.
66

Die Switches eines Gebäudes oder einer Gebäudegruppe werden mittels Glasfaser zum allergrößten Teil mit 1 Gbit/s, aber auch mit 10 Gbit/s an die Router herangeführt.
Abbildung 37 MWN Unterbezirke und Ausdehnung

In den Gebäuden geschieht die Anbindung von Datenendgeräten über Ethernet. Die Anbindung
wird entweder über „Twisted-Pair“-Kupferkabel (100/1.000 Mbit/s) und Lichtwellenleiter (100
Mbit/s oder zum Teil 1.000 Mbit/s) oder zu einem sehr geringen Teil noch über Koaxial-Kabel
(10 Mbit/s) realisiert. Server-Rechner werden in der Regel mit 1 Gbit/s zum Teil auch mit 10
Gbit/s angeschlossen. Die Gebäudenetze werden in Abschnitt 6.1.3 erläutert.
 Die zentralen Rechner im LRZ (der Höchstleistungsrechner SuperMUC, die Linux-Cluster, die
Server des Backup- und Archivsystems und die zahlreichen Server-Systeme) sind untereinander
mit mehrfach 10 Gbit/s mittels Switches verbunden. Diese Netzstruktur der zentralen Rechner ist
über einen Router (10 Gbit/s) mit dem MWN-Backbone verbunden. Die Struktur des Rechenzentrumsnetzes beschreibt Abschnitt 6.1.4.
 Im MWN wird ausschließlich das Protokoll IP benutzt.
Abbildung 38 und 39 zeigen die für das Backbone-Netz verwendeten Strecken, deren Ü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).
Abbildung 38 Standorte und Verbindungen im MWN
67
68
Abbildung 39 Standorte und Verbindungen (Fortsetzung)
69
6.1.1 Struktur des Backbone Netzes
Während die Abbildungen 38 und 39 die topologische Struktur, die Standorte und deren Verbindungen
zeigen, stellt Abbildung 40 die technische Struktur des Kernnetzes dar. Den Kern des Backbones bilden
Cisco Catalyst 6509 Switch/Router, die untereinander mit 10 GBit/s verbunden sind. Die Anbindung der
Standorte erfolgt über LWL (Lichtwellenleiter). Das LRZ selbst ist über einen virtuellen Router (bestehend aus zwei Cisco Catalyst 6509) an das Backbone angebunden. Die meisten Telekom-Glasfasern enden im zentralen Netz Raum des TUM-Stammgeländes. Die M-net Glasfasern enden im zentralen Netzraum des LMU-Stammgeländes.
Abbildung 40 Struktur des Kernnetzes
Das Router-Backbone bildet mehrere Zyklen, die der Redundanz dienen. Bis auf den Router an der Hochschule München haben alle eine mindestens doppelte Anbindung an das Backbone. Im Jahr 2012 konnte
auch der Standort Weihenstephan über eine Glasfaser redundant erschlossen werden. Diese Anbindung
konnte nur durch eine enge Kooperation mit dem Deutschen Forschungsnetz (DFN) und Gasline realisiert
werden. Gasline baute in Freising für die wegeredundante Faser eine neue Trasse von insgesamt 9 km
Länge zu einem Verstärkerstandort des DFN, von dort konnte die Faserinfrastruktur des DFN mitgenutzt
werden. Die redundante Faser endet in Garching. Mit einer Gesamtlänge von 52 km ist dies die längste
LWL-Verbindung im MWN. Im Jahr 2013 ist geplant auch die Hochschule München redundant ans
MWN anzubinden.
Die Router unterhalten sich über Punkt-zu-Punkt Verbindungen mittels OSPF (Open Shortest Path First).
Der Verkehr fließt von der Quelle zum Ziel über die Leitungen mit der kleinsten „Hop“-Anzahl (Weg, der
über die wenigsten Router führt).
Ausnahmen zu dieser generellen Regel bilden der über „Policy-Based-Routing“ geführte Verkehr, der in
einem eigenen VLAN (Virtual LAN) fließt, und spezielle VLANs, die über das gesamte MWN gezogen
wurden. Dies ist nötig, um die besonderen Anforderungen von MWN-Mitnutzern (MPG-Institute, Staatsbibliothek, etc.) zu erfüllen.
70
Auch die Internet-Anbindung ist redundant ausgelegt. Es gibt eine Anbindung an das X-WiN über einen
sog. Port-Trunk mit zweimal 10 GBit/s (vom DFN beschränkt auf zweimal 5,5 Gbit/s) und eine an M-net
mit 1 GBit/s. Dabei ist die Hierarchie so gewählt, dass die höchste Priorität die Internet-Anbindung zum
DFN X-WiN (siehe Abbildung 40) hat. Fällt diese aus, so wird der Weg über M-net gewählt. Die Umschaltung zwischen den Internet-Anbindungen wird automatisch über ein Routing-Protokoll (BGP, Border Gateway Protocol) gesteuert.
6.1.2 Router Auswahl
Das MWN zeichnet sich aus durch ein erhebliches Wachstum sowohl bei den versorgten Geräten, bei den
Nutzern, den angebotenen Diensten und damit auch bei den Bandbreiten und übertragenen Datenvolumina. Um künftig weiter steigende Anforderungen insbesodere auch im Hinblick auf die Bandbreite erfüllen
zu können, bedarf es einer Erneuerung der Backbone-Router.
Die bestehenden Backbone-Router im MWN (Cisco Catalyst 6509) wurden im Jahr 2000 beschafft und in
mehreren Aktualisierungsrunden technologisch modernisiert. Die Supervisor-Engines, die die eigentliche
Verarbeitung der Pakete durchführen, wurden 2004 und die Policy Forwarding Cards (PFC), die TODO,
2007 aktualisiert. Allerdings ist die Plattform technologisch auf 10 bzw. 20 Gbit/s beschränkt und stößt
damit aber in immer mehr Bereichen sichtlich an ihre Grenzen. Ein Migrationspfad zu Bandbreiten von
40 Gbit/s oder gar 100 Gbit/s ist mit dieser Harware-Plattform nicht möglich. Gleichzeitig steigt der
Bandbreitenbedarf im MWN kontinuierlich an. Deshalb wurden bereits im Jahr 2011 erste Überlegungen
getroffen, wie die bestehende Router-Generation durch moderne und leistungsfähigere Systeme abgelöst
werden kann.
Zur Bestimmung und Bewertung geeigneter Komponenten für die neue Router-Plattform wurde von August 2011 bis Februar 2012 ein vierstufiges Auswahlverfahren durchgeführt:
1.
2.
3.
4.
Auswahl potentieller Hersteller
Auswahl konkreter Testkandidaten
Durchführung von Tests
Auswahlentscheidung
Zu Beginn des Verfahrens wurde eine für das MWN spezifische Anforderungsmatrix erstellt und potentielle Lieferanten auf Basis eines Fragebogens, um konkrete Produktvorschläge aus ihrem Portfolio gebeten, mit dem nach Meinung der Hersteller die Anforderungen umgesetzt werden könnten. Die Firmen
mußten ihre Vorschläge mit technischen Spezifikationen und Datenblättern belegen. Acht Firmen gaben
entsprechende Vorschläge und Unterlagen ab.
Auf Basis der von den Herstellern gelieferten technischen Dokumentation wurden die Produkte im Hinblick auf die Anforderungsmatrix analysiert und bewertet. Da die wichtigste Anforderung bei der RouterAuswahl die Migrationsfähigkeit auf 40 bzw. 100 Gbit/s war, ist vor allem eine hohe Bandbreite zwischen den verschiedenen Slots der Geräte (> 300 Gbit/s) entscheidend für die Auswahl der Testkandidaten gewesen und es wurden Alcatel, Cisco und HP gebeten, Geräte zum Test zur Verfügung zu stellen.
Nach Auswahl der Testkandidaten wurde im Herbst 2011 ein Testplan erstellt und die von den Herstellern
gelieferten Geräte (Testkandidaten) wurden von November 2011 bis Februar 2012 gemäß diesem Testplan evaluiert. Jeder Testkandidat wurde sowohl im Testlabor untersucht als auch im Münchner Wissenschaftsnetz am Standort Garching produktiv über eine Woche eingesetzt. Dabei wurden jeweils der Testplan abgearbeitet und die erreichten Ergebnisse dokumentiert und bewertet. Für den Feldtest (Live-Test)
im MWN wurden von den Herstellern jeweils vergleichbare Hardware-Konfigurationen zum Test angefordert. Die Geräte sollten jeweils einen repräsentativen MWN-Kern-Router am Campus Garching ersetzen. Von Alcatel wurde der OmniSwitch 10k und von Cisco der Nexus 7009 und von HP der A12508
getestet.
Die Tests wurden zu Gruppen zusammengefasst und diese Gruppen relativ zueinander bewertet. Konnte
eine Anforderung mit dem entsprechenden Gerät umgesetzt werden, wurde dieses Gerät mit „0“ bewertet,
falls dies nicht möglich war mit „-1“. Im Falle dass ein Gerät die Anforderung besser als die Konkurenz
71
erfüllt wurde eine „+1“ vergeben. Die Berwertungen wurden am Ende für jedes Gerät aufaddiert. Der
klare Gewinner dieser Auswahl waren die Geräte von Cisco.
Parallel zu den Tests wurde ein Antrag nach Art. 143 c Grundgesetz, ein sogenannter „Großgeräte der
Länder“-Antrag für den Ausbau des Münchner Wissenschaftsnetzes gestellt. Der Antrag konnte im Mai
bei der DFG eingereicht werden und wurde Anfang August 2012 ohne Einschränkungen bewilligt. Daraufhin wurde am 24. August eine EU-weite Ausschreibung für die Ersetzung der Backbone-Router im
MWN veröffentlicht und am 5.11.2012 wurde der Zuschlag an den Gewinner der Ausschreibung, die
Firma T-Systems, erteilt.
6.1.3 Struktur der Gebäude-Netze im MWN
In den Gebäuden, die durch das MWN verbunden werden, existiert grundsätzlich eine strukturierte Verkabelung, bestehend aus Kupferkabeln (Kategorie 5/6, Twisted Pair (TP)) oder MultimodeLichtwellenleiter-Kabeln (50/125µm). In einigen Bereichen ist allerdings nur eine alte Vier-DrahtVerkabelung verfügbar, welche keine Verbindungen mit Gigabit-Ethernet gestattet und beim Betrieb mit
modernen Switches Probleme bereitet. Inzwischen wurden Mittel zur Ersetzung durch eine Verkabelung
nach Kategorie 6a genehmigt. Zu einem sehr geringen Anteil ist in sehr wenigen Gebäuden auch noch
Ethernet-Koax-Kabel (yellow cable) verlegt.
Als aktive Komponenten zur Verbindung mit den Endgeräten werden (Layer-2-) Switches eingesetzt.
Derzeit sind vor allem Switches der Serien HP ProCurve 4200 und 5400 im Einsatz. Andere stackable
HP-Switches vom Typ HP ProCurve 2610 sind in kleineren Netzanschlussbereichen, vom Typ HP ProCurve 2910 für Serveranschlüsse bei Instituten und im Rechnerwürfel des LRZ in Betrieb. Auch 2012
wurden HP ProCurve-Switches der Serie 5400 aufgebaut. Kennzeichen dieser Netzkomponenten sind
10GE-Ports und Features wie QoS und Meshing. Alle diese Geräte sind modular aufgebaut und bieten
über einzubauende Schnittstellenkarten Anschluss von bis zu 288 Geräten.
Im Jahr 2012 wurden 54 HP 4100 mit ca. 5.000 Ports ersetzt.
Zum Jahresende 2012 wurden vom LRZ insgesamt 1.310 Switches betrieben. Einen Vergleich zu den
Vorjahren zeigt Tabelle 10:
Anzahl Switches
davon HP-Switches
davon Cisco-Switches
Anzahl TP-Ports
Anzahl Glasfaser-Ports
Ende 2012
1.310
1.309
1
81.090
7.687
Ende 2011
1.247
1.246
1
77.562
7.599
Ende 2010 Ende 2009
1.126
990
1.125
1
67.040
6.842
Ende 2008
914
Ende 2007
843
914
53.591
6.245
843
47.212
5.302
989
1
60.363
6.493
Tabelle 10: Anzahl der im MWN eingesetzten Switches
Die Verteilung nach Switch-Typen ist im Kapitel 17 „Technische Ausstattung“ des LRZ zu finden.
Abbildung 41 Entwicklung bei der Anzahl der Switchports
72
6.1.4 Struktur des Rechenzentrumsnetzes (RZ-Netz)
Ein wichtiger Punkt für eine möglichst nahtlose und störungsfreie Diensterbringung durch das LRZ sind
geeignete Redundanzmechanismen, die sich natürlich auch im zugrundeliegenden Netz widerspiegeln
müssen.
Abbildung 42 stellt die Struktur des Kernnetzes im Rechnerwürfel des LRZ dar. Das Grundprinzip hierbei
ist, dass jede kritische Komponente und jede Verbindung doppelt vorhanden sind. Über geeignete 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.
Abbildung 42 Struktur des RZ-Netzes
Das Zentrum des Rechenzentrums-Netzes bilden eine Reihe von Switches (HP) mit einer Bandbreite von
2x10 GBit/s (2x10 GE) und ein VSS (Virtual Switching System) von Cisco. Das VSS besteht aus zwei
Cisco Catalyst 6509 die, räumlich getrennt, in zwei verschiedenen Brandabschnitten des Rechnergebäudes untergebracht wurden. Das VSS 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. Über das VSS wird in dieser Technik eine redundante Anbindung ans
MWN-Backbone und ans Internet realisiert. Auch Sicherheitssysteme wie z.B. Firewalls sind doppelt
ausgelegt.
Die Anbindung der Systeme und Dienste erfolgt über den Verbund von Zentralswitches. Das VSS und die
zentralen HP Switches sind mehrfach redundant miteinander verbunden (siehe Abbildung 42). Die
dadurch entstehenden Schleifen werden durch den Einsatz des Spanning-Tree-Protokols (STP) verhindert.
STP schaltet beim Ausfall einer Verbindung automatisch im Bereich von Millisekunden auf eine andere
Leitung um. Die verschiedenen physischen, aber auch die virtualisierten Server sind dann auch wieder
73
jeweils redundant über zwei verschiedenen Zentralswitches und über zwei auch räumlich getrennte Verbindungen am Netz angeschlossen.
Der SuperMUC und das SuperNAS sind über zwei dedizierte Cisco Catalyst 6509 redundant angebunden
(siehe Abbildung 42). Das Linux-Cluster und das Migrationssystem SuperMIG sind über einen Cisco
Nexus 7018 Switch angebunden. Für diese Systeme ist derzeit keine netztechnische Redundanz erforderlich bzw. wäre in der Realisierung zu teuer.
6.2
Anschluss ans MWN; Wesentliche Änderungen im Netz
Das MWN zeichnet sich, ebenso wie die angeschlossenen Institutionen, durch eine recht hohe Dynamik
aus. Neue Gebäude und Anmietungen müssen ans MWN angeschlossen werden und mit neuen Gebäudenetzen versorgt werden. Aber auch Sanierungen und Umbaumaßnahmen erfordern eine Anpassung auch
der Datennetze. Steigende Anforderungen führen oft zu gestiegenem Bandbreitenbedarf aber auch die
Aufgabe von Gebäuden oder Gebäudeteilen hat Auswirkungen auf das Netz. Der folgende Abschnitt beschreibt diese Netzänderungen.
Besonders erwähnenswert ist hier die im letzten Jahr realisierte redundante Anbindung des Campus Weihenstephan. Diese Anbindung konnte nur durch eine enge Kooperation mit dem Deutschen Forschungsnetz (DFN) und Gasline realisiert werden. Gasline baute in Freising für die wegeredundante Faser eine
neue Trasse von insgesamt 9 km Länge zu einem Verstärkerstandort des DFN, von dort konnte die Faserinfrastruktur des DFN mitgenutzt werden. Die redundante Faser endet in Garching. Mit einer Gesamtlänge von 52 km ist dies die längste LWL-Verbindung im MWN.
An beiden Universitäten gibt es Investitionsprogramme zur Erneuerung der passiven Netzinfrastruktur,
dies wird in Abschnitt 6.2.2 beschrieben. Auch Studentenwohnheime sind in erheblicher Zahl über das
MWN angebunden und mit Netzdiensten versorgt. Abschnitt 6.2.3 gibt einen Überblick über die angebundenen Wohnheime.
6.2.1 Wesentliche Netzänderungen im Jahr 2012
Im Jahr 2012 gab es folgende in chronologischer Reihenfolge aufgeführte wesentliche Netzveränderungen:
09.01.12
Neuanschluss des Studentenwohnheims Garching Living Center (GLC) in Garching per privat
verlegter LWL
11.01.12
Rückbau der Netzkomponenten der Hochschule für Fernsehen und Film in der Frankentalstraße
wegen Aufgabe des Standortes
30.01.12
Neuanschluss des Neubaus Dachauer Str. 100 a der Hochschule München per LWL
09.02.12
Neuanschluss der Forschungsstation Mülverstedt, Türingen der TUM per LTE
28.02.12
Rückbau der Netzkomponenten am Olympiagelände, ZHS wegen Generalsanierung
01.04.12
Erhöhung der Bandbreite für das Gate in Garching auf 1 Gbit/s
11.04.12
Erhöhung der Bandbreite des Wohnheims Freising II auf 1 Gbit/s
12.04.12
Redundante Anbindung des Campus Freising-Weihenstephan über eine zweite LWL
30.04.12
Neuanschluss des Center for Advanced Laser Applications (CALA) der TUM am Campus
Garching per LWL
04.05.12
Änderung der Anbindung der TUM Geodäsie Außenstelle Eichenau von WiNShuttle auf DSL
mit gleichzeitiger Bandbreitenerhöhung auf 16 Mbit/s
15.05.12
Umstellung der Anbindung Thalhausen von Satelliten-DSL auf DSL mit gleichzeitiger Bandbreitenerhöhung auf 6 Mbit/s
05.06.12
Neuanschluss des Wohnheims Enzianstr. 3-5 in Garching per privat verlegter LWL
11.06.12
Aufgabe des Versuchsgutes Hirschau der TUM
10.07.12
Neuanschluss des Neubaus der Reptilienklinik in Oberschleißheim
74
13.07.12
Neuanschluss des Erweiterungsbaus des Zentrums für angewandte Energieforschung (ZAE) in
Garching
01.09.12
Mitnutzung des MWN durch den Verein Munich Creative Networks (Spin-Offs der Hochschule
München)
24.09.12
Neuanschluss der Containerburg der Hochschule Weihenstephan-Triesdorf in FreisingWeihenstephan per LWL
24.09.12
Studentenwohnheim Georg-Lanzenstiel-Haus nicht mehr über MWN angebunden
25.09.12
Studentenwohnheim Geschwister-Scholl nicht mehr über MWN angebunden
28.09.12
Redundante Anbindung der TUM Informatik / Mathematik in Garching per LWL
02.10.12
Umstellung der Anbindung des LMU Seniorenstudiums von DSL auf FibreDSL mit gleichzeitiger Bandbreitenerhöhung auf 10 Mbit/s
08.10.12
Neuanschluss des Business Campus Garching II der TUM per LWL
11.10.12
Bandbreitenerhöhung der Staatsbibliothek auf 10 Gbit/s
22.10.12
Aufgabe des Studentenwohnheims im Maschinenwesen; ehemalige Hausmeisterwohnung
13.11.12
Datennetzsanierung im 2. OG im Flügel 6 im Maschinenwesen in Garching
16.11.12
Erhöhung der Bandbreite des FRM II auf 1 Gbit/s
20.11.12
Anbindung des Business Campus in Garching mittels LWL
22.11.12
Neuanschluss des Studentenwohnheims Freimann (Josef-Wirth-Weg 21)
28.11.12
Bandbreitenerhöhung des Wohnheims Studentenstadt auf 2 Gbit/s
05.12.12
Erhöhung der Funkbrücke des Staatsinstitut für Schulqualität und Bildungsforschung auf 150
Mbit/s
31.12.12
Aufgabe des Gutshofes Grünschweige der TUM
6.2.2 Netzausbau (Verkabelung); Netzinvestitionsprogramm
Mit NIP (Netzinvestitionsprogramm in Bayern) wurde zwar eine flächendeckende Vernetzung erreicht,
diese ist jedoch an der TUM in München und Garching noch zu einem sehr geringen Teil in Koax 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 sein wird.
6.2.2.1
TU München
Im Bereich der TU München (ohne Weihenstephan) konnten die im Folgenden aufgeführten Gebäude im
Jahr 2012 mit einer strukturierten Verkabelung versehen werden.
Innenstadt
Stammgelände Gebäude 0505 - 2.Bauabschnitt
Gabelsbergerstraße 49
Cam
Derzeit gibt es noch Koax in Bau 0503, 0106 (N6) und zum Teil in Gebäude 5402 (CH2); hier soll aber
Koax im Rahmen anderer Maßnahmen ersetzt werden.
6.2.2.2
LMU
Im Bereich der LMU München sind alle Gebäude mit einer strukturierten Verkabelung versehen. Es gibt
jedoch teilweise Defizite in der Verwendung der installierten Medien (nur vier-drahtiger Anschluss
(Cable-sharing) oder Installation von Kategorie 5 - Kabeln bzw. Anschlusskomponenten). Dies betrifft
noch 20 Gebäude (NIP V–2.Bauabschnitt). Die Kosten für die Sanierung dieser Gebäude in Höhe von 6,6
Mio. € wurden vom Landtag freigegeben. Im Rahmen des Konjunkturprogramms wurden im 1. Bauabschnitt bis Anfang 2012 nachgerüstet:
75
M-Bogenhausen
Universitäts-Sternwarte (Neuverkabelung bereits 2009 abgeschlossen)
M-Lehel
Oettingenstr. 67 (Informatik, Kommunikationswissenschaft, etc.)
M-Schwabing
Leopoldstr. 13 - Haus 1 – 3 (Psychologie+Pädagogik)
M-Maxvorstadt
Theresienstr. 37 (Physik, Meteorologie)
Theresienstr. 39 (Mathematik)
Theresienstr. 41 (Geo- und Umweltwissenschaften)
Die verbleibenden 20 Gebäude werden ab 2013 im Rahmen des 2. Bauabschnittes der
NIP V-Maßnahme mit einer Verkabelung der Kategorie 6a modernisiert.
Außerhalb der NIP V-Maßnahme wird seit Ende 2012 eine Neuanmietung der LMU mit einer strukturierten Verkabelung der Kategorie 6a ertüchtigt:
M-Schwabing
6.2.2.3
Leopoldstraße 44
Weihenstephan (TU München)
Im Campus Weihenstephan der TU München sind alle Gebäude mit einer strukturierten Verkabelung
versehen, entweder Kupfer (Kategorie 6-Kabel) oder Glasfaser (Multimode).
6.2.2.4
LWL-Netze auf den Campus-Geländen
Auf den Campusgelände TUM-Stamm/Nordgelände, LMU-Stammgelände, TUM-Garching, TUMWeihenstephan und LMU Großhadern/Martinsried sind privat verlegte Glasfaserstrecken installiert, die
teilweise schon über 15 Jahre existieren. Hier muss in den nächsten Jahren nachgerüstet werden, da bei
einem Teil der Strecken die heute benötigten Glasfasertypen (OM3/OM4, Monomode) nicht vorhanden
sind, diese aber aufgrund der gestiegenen Übertragungsraten notwendig sind.
6.2.3 Anbindung Studentenwohnheime
Das LRZ ermöglicht Wohnheimen eine feste Anbindung über Standleitung, DSL-Technik oder WLAN
an das MWN und damit an das Internet. Die Kosten der Anbindung hat der Heimträger zu übernehmen,
für die Netznutzung werden aber keine Gebühren verlangt.
Drei Heime sind nicht mehr am MWN angeschlossen (Georg-Lanzenstiel-Haus, Geschwister-Scholl und
Maschinenwesen), die Träger wechselten zu einem kommerziellen Internetanbieter.
Zum Jahresende 2012 sind 12.642 Wohnheimplätze in 57 Heimen an das MWN angeschlossen, davon 39
über eine Glasfaserleitung (LWL) mit 100 Mbit/s oder 1 Gbit/s, 10 über Funkstrecken, 5 über DSL, 2
über Mikrowellenfunk und 1 Heim über 100 MBit/s Laserlink.
Die nachfolgende Tabelle zeigt die Wohnheime, die Ende 2012 am MWN angeschlossen sind:
Name
Adresse
Träger
Plätze
Anschluss
Studentenstadt
Freimann
Christoph-ProbstStraße 10
Studentenwerk
2.440
LWL zu MPI Freimann
Studentenviertel auf dem Oberwiesenfeld
Helene-Mayer-Ring 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
301
LWL zu TUM
John-Mott-Haus
Theo-Prosel-Weg 16
CVJM München e.V.
Oberschleißheim
Oberschleißheim
Studentenwerk
67
Funk zu Winzererstr.
171
LWL zu Rinderklinik
76
Am Schäferanger 9-15
Öekumenisches Studentenheim
Steinickeweg 4
Verein evangelischer
Studentenwohnheime
78
Funk zu TUM-Uhrenturm
Hugo-Maser-Haus
Arcisstr. 31
Verein evangelischer
Studentenwohnheime
72
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
Hedwig Dransfeld Allee
Hedwig Dransfeld
Allee 7
Studentenwerk
109
100 MBit/s Mikrowellenfunk
Stettenkaserne
Schwere Reiter Str. 35
Studentenwerk
242
M-net LWL
Heidemannstraße
Paul-Hindemith-Allee 4
Studentenwerk
310
M-net LWL
Felsennelkenanger
Felsennelkenanger 7-21
Studentenwerk
531
M-net LWL
Heiglhofstraße
Heiglhofstraße 64/66
Studentenwerk
415
Telekom LWL
Sauerbruchstraße
Sauerbruchstraße
Studentenwerk
259
M-net LWL
Garching 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 FH Heizhaus
Weihenstephan IV
Giggenhauserstraße 2733
Studentenwerk
237
LWL zur Telefonzentrale
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-Wagner-Str. 16
Ingeborg van-Calker Stiftung
33
LWL zu Richard WagnerStr. 18
Hochschulhaus Garching
Enzianstr. 5
Evangelische Studentenwohnheime
95
Funk zu TU-Feuerwehr
Spanisches Kolleg
Dachauerstraße 145
Katholische Kirche
34
Funk 802.11a zur HM
Chiemgaustraße
Traunsteiner Straße 1-13
Studentenwerk
Am Anger I
Unterer Anger 2
Orden der Armen Schulschwestern
50
M-net SDSL
Am Anger II
Unterer Anger 17
Orden der Armen Schulschwestern
85
M-net SDSL
Wohnheim Stiftsbogen
Schröfelhofstraße 4
Studentenwerk
436
588
über Adelheidstr. 13
angeschlossen
Telekom-LWL zu TUM
LWL zu Campus Großhadern
77
Priesterseminar St. Johannes der
Täufer
Georgenstraße 14
Katholisches Ordinariat
28
Johannes-Hanselmann-Haus
Kaulbachstr. 25
Ev. Waisenhausverein
117
Marie-Antonie-Haus
Kaulbachstr. 49
Studentenwerk
96
LWL zu Ludwigstr. 28
Student Living Center 1
Freisinger Landstraße 47
Garching
Fa. Melampus
93
LWL zu TUM Heizhaus
Freisinger Landstr. 47a
Garching
Fa. Melampus
107
LWL zu TUM Heizhaus
Freisinger Landstr. 45a
Garching
Fa. Melampus
72
LWL zu TUM Heizhaus
Garching Living Center
Schleißheimer Str.
Garching
GLC GmbH
70
LWL zu TUM Heizhaus
Studentenwohnanlage
Biederstein
Biedersteiner Str. 24-30a
Studentenwerk
168
LWL zu Amalienstr. 17
Sophie-Barat-Haus
Franz-Josef-Str. 4
106
LWL zu Ordinariat
Johann-Michael-Sailer-Haus
Preysingstr. 93a
26
LWL zu Ordinariat
Heinrich-Groh-Str.
Heinrich-Groh-Str. 17
Studentenwerk
59
LML zu Amalienstr. 17
Moosacher Straße
Moosacher Str. 81
Studentenwerk
160
100 MBit/s Laserlink
Josef-Wirth-Weg 19
Josef-Wirth-Weg 19
Studentenwerk
190
100 MBit/s Mikrowellenfunk
Gästeappartment
Musikhochschule
Barer Str. 34
Hochschule für
Musik und Theater
Oskar von Miller Forum
Oskar von Miller Ring
25
Herzogliches Georgianum
Funk zu Georgenstr. 11
LWL zu Staatsbibliothek
1
ADSL mit VPN-Tunnel
Oskar von Miller Forum
80
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. 19-23
Studentenwerk
137
Lothstraße
Lothstr. 62
Studentenwerk
62
Studentenwohnheim Freimann
Josef-Wirth-Weg 21
Grammer Immobilien
57 Wohnheime
6.3
Summe insgesamt
449
LWL zu Dachauer Str. 98b
LWL zu Amalien 17
12.642
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 zu erbringen. Daneben betreiben einige Fakultäten und Institute für ihre Bereiche auch eigene Nameserver.
Ziel ist aber die weitgehende Zentralisierung des Dienstes über die hochverfügbaren und gut gepflegten
Server des LRZ. Der DNS-Dienst wird Mandanten-fähig angeboten. Über eine Webschnittstelle
(Webdns) können Netzverantwortliche die Ihnen zugewiesenen Namensräume selbstständig verwalten.
78
Der Webdns-Dienst wird inzwischen von 306 Nutzern zur Pflege der DNS-Einträge verwendet. Die Anzahl der über Webdns verwalteten DNS-Zonen stieg von 2.054 auf 2.339. Es wurden 67 neue Domains
unter verschiedenen Toplevel-Domains (z.B. de, org, eu) für Institute und Organisationen registriert, 23
wurden von anderen Providern transferiert.
Die folgenden Bilder zeigen die Frequenz der Anfragen für den authoritativen und den Resolving-Dienst.
Abbildung 43 Statistik für alle DNS-Server (Autoritativ)
Abbildung 44 Statistik für alle DNS-Resolver
Eine Übersicht aufgeteilt nach Domains im MWN zeigt die folgende Tabelle. Die reale Anzahl der Zonen
und Einträge ist um einiges höher, kann aber nicht ermittelt werden, da manche Instituts-Server keine
Auflistungs-Abfragen beantworten. Die Spalte A-Records bezeichnet die IPv4 Einträge, AAAA-Records
die für IPv6 und MX-Records beinhaltet die Mail-Server.
SubAAAAAMXMailWWWZone
Zonen Domains Records Records Aliase Records Domains Records
uni-muenchen.de
376
2.011
30.127
2.117 4.889
3.464
1.557
1.081
lmu.de
112
1.084
4.528
898 2.071
2.852
1.337
816
tu-muenchen.de
274
1.951
20.498
1.204 1.936
7.219
6.763
289
tum.de
343
4.883
15.456
2.423 3.445
2.077
1.648
991
fh-muenchen.de
49
115
3.681
0
232
547
225
30
hm.edu
73
317
9.234
0
254
256
95
77
fh-weihenstephan.de
2
29
64
0
37
2
2
5
hswt.de
0
32
113
0
62
2
2
7
badw-muenchen.de
24
69
38
0
27
104
48
57
badw.de
24
79
1
0
87
88
43
32
lrz-muenchen.de
24
253
747
53
260
44
27
8
lrz.de
74
193
28.050
2.770 1.404
30
17
10
mhn.de
mwn.de
Sonstige (637 Zonen)
Gesamt
63
49
12
1.499
989
92.175
613
32.720
427
2.636
13.045 240.068
79
65 1.259
153
574
79
981
9.762 17.518
24.873
31
593
42.182
12.404
16
335
24.519
154
266
638
4.461
In den WLAN-Netzen mit öffentlichen IP-Adressen (eduroam- und Konferenznetz) wurde von dynamischen aus der MAC-Adresse abgeleiteten DNS-Einträgen auf statische Einträge der Form dhcp-138-24647-12.dynamic.eduroam.mwn.de (Beispiel für den Client mit der IP-Adresse 138.246.47.12) umgestellt,
wodurch einerseits die Anonymität der Clients erhöht, und andererseits die Fehleranfälligkeit stark verringert wurde.
6.3.1 DNS-Amplifikation-Attacks und offene Resolver
Eine sogenannte DNS-Reflection-Attack bzw. DNS-Amplification-Attack (Reflection-Attack mit 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 Rechner (einem sog. Botnet) aus die Anfragen mit der gefälschten Absenderadresse startet. Abbildung 45 stellt das Prinzip des Angriffs dar. Selbst wenn Heuristiken zur Angriffserkennung greifen, kann
der Angreifer den Angriff verfeinern (mehr unterschiedliche Records, mehr offene Resolver etc.).
Abbildung 45 Funktionsweise der DNS-Amplification-Attack
Solange IP-Spoofing nicht verhindert wird, gibt es keine grundsätzliche Lösung für das Problem, die
Wirkung von Gegenmaßnahmen beschränkt sich darauf, den Angriff abzuschwächen oder den Aufwand
für den Angreifer zu erhöhen. Offene Resolver sind ein essentieller Bestandteil des Angriffs, gleichzeitig
gibt es fast nie gute Gründe für den Betrieb eines offenen Resolvers, verständlicherweise sind offene Resolver daher nicht gern gesehen.
80
Die Zunahme der DNS-Amplification-Attacks im letzten Jahr war für das LRZ Anlass, Maßnahmen zur
Verringerung der Anzahl der offenen Resolver im MWN zu ergreifen. Als Teil der Maßnahmen wurde
auch der (bis Mitte Dezember offene) Resolver resolver2.lrz.de auf Anfragen aus dem MWN eingeschränkt. Auf Anfragen aus dem Internet antwortet der resolver nicht mehr. Gleichzeitig wurde versucht,
durch Verkehrsanalyse und Scans offene Resolver im MWN zu finden und sie, in Zusammenarbeit mit
deren Betreibern, nach Möglichkeit zu schließen. Die Bemühungen werden 2013 fortgesetzt.
6.4
DHCP
Seit ca. 9 Jahren betreibt das LRZ einen DHCP-Dienst, der von allen Münchner Hochschulen für die automatische IP-Konfiguration von institutseigenen Rechnern genutzt werden kann. Außerdem wird dieser
Dienst für einige zentrale Anwendungen verwendet, wie z.B. für die WLAN-Zugänge im MWN oder die
Netzanschlüsse in Hörsälen und Seminarräumen. Insgesamt wird der DHCP-Dienst von 184 Instituten
genutzt und verwaltet dabei 825 Subnetze mit über 150.000 IP-Adressen. Falls gewünscht, tragen die
DHCP-Server die Namen der Clients auch automatisch in die zugeordnete Zone auf den zuständigen
DNS-Servern ein (Dynamic DNS).
In diesem Jahr wurde der DHCP-Dienst von alten physischen Servern auf vier DNS-Server migriert
(Standorte: LMU-Stammgelände, TU-Stammgelände, LRZ Garching und Weihenstephan). Gleichzeitig
wurde eine neue Architektur eingeführt: Jeden größeren Router-Standort bedient ein eigenes FailoverPaar, wobei die Paare je auf 2 DNS-Server verteilt werden. Die DNS-Server sind räumlich getrennt und
über mehrere Routen erreichbar, sollte also einer der Server oder eine Route zum Server ausfallen, übernimmt ein anderer Server bzw. eine andere Route. Die Konfiguration der Server wird zentral in einem
Subversion-Repository verwaltet und automatisch auf Fehler überprüft und auf die Server übertragen. Das
Monitoring wurde dahingehend erweitert, dass nicht nur Ausfälle eines Servers erkannt werden, sondern
u.a. auch ein Synchronisationsausfall der Failover-Peers und Netze ohne verfügbare IP-Adressen.
Abbildung 46 DHCP-Infrastrkutur auf den DNS-Servern
Der DHCPv6-Dienst wurde ebenfalls auf die DNS-Server migriert. Da das LRZ den DHCPv6-Dienst
stateless betreibt, kann der Dienst über Anycast erreicht werden. Fällt einer der Server aus, schwenkt die
Anycast-Route automatisch zu einem anderen Server, der DHCP-Dienst ist also mehrfach redundant.
6.5
Radius
Über Radiuszonen können einzelne Institutionen für ihre Beschäftigten bzw. Studierenden die 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 die folgende Abbildung.
Die Funktionsweise ist folgende:
81
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 eigentlichen 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 abgeleht.
Die von uns eingsetzte RADIUS Software (FreeRADIUS) unterscheidet zwischen Authorisierung und
Authentifizierung. So hat nicht jeder Nutzer der authentifiziert wird auch automatisch Zugang zu allen
RAS Geräten.
Abbildung 47 Radius-Strukur im MWN
Zum Jahresende 2012 waren 49 Radiuszonen konfiguriert.
Eine Auflistung der Radiuszonen zeigt folgende Tabelle:
Zonenbezeichnung
Zonenbezeichnung
aci.ch.tum
binfo.wzw.tum.de
bl.lmu
bmo.lmu
campus.lmu.de
cicum.lmu
cip.informatik.lmu
Lehrstuhl für Anorganische Chemie TUM
Genome oriented Bioinformatics
Beschleunigerlabor der TU und der LMU München
Lehrstuhl für BioMolekulare Optik, LMU
Internet und virtuelle Hochschule (LMU)
Department Chemie LMU
Institut für Informatik der LMU
82
cipmath.lmu
cipmath.lmu.de
eduroam.mwn.de
edv.agrar.tum
fhm.de
fhm.edu
fh-weihenstephan.de
forst.tum
frm2.tum
fsei.tum
fsmpi.tum
hm.edu
hswt.de
ibe.lmu
ikom.tum
info.tum
lkn.tum
lmu.de
lpr.tum
lrz.de
math.lmu
math.lmu.de
math.tum
med.lmu
med.lmu.de
meteo.lmu
mytum.de
phy.lmu
physik.lmu.de
radius.wzw.tum
rcs.tum
rz.fhm
sec.in.tum.de
sec.in.tum.gaeste
staff.fhm
studext
studlmu
tum.de
usm
usm.lmu
vm08.fhm
wzw.tum
6.6
Mathematisches Institut LMU
Eduroam-Nutzer
Datenverarbeitungsstelle der TU in Weihenstephan
Hochschule München
Hochschule München
Hochschule Weihenstephan-Triesdorf
Forstwissenschaftliche Fakultät
Forschungsreaktor
Fachschaft Elektro- & Informationstechnik
Fachschaften MPI
Hochschule München
Hochschule Weihenstephan-Triesdorf
Institut für med. Informationsverarbeitung, Biometrie und Epidemiologie
Fachschaft Elektro- & Informationstechnik
Informatik TUM
Lehrstuhl für Kommunikationsnetze
Verwaltung LMU
Lehrstuhl für Prozessrechner
LRZ-Mitarbeiter
Zentrum Mathematik TU München
Medizin der LMU, Großhadern
Medizin der LMU, Großhadern
Meteorologisches Institut LMU
Mitarbeiter und Studenten der TUM
Fakultät für Physik der LMU
Fakultät für Physik der LMU
Informationstechnologie Weihenstephan (ITW)
Lehrstuhl für Realzeit-Computersysteme
Rechenzentrum der FH München (Studenten)
Chair for IT Security, TUM
Chair for IT Security, TUM
Rechenzentrum der FH München (Mitarbeiter)
Studentenrechner LRZ (andere)
Studentenrechner LRZ (LMU)
Mitarbeiter und Studenten der TUM
LMU Sternwarte
LMU Sternwarte
Fachbereich 08, FH München
Informations-Technologie Weihenstephan
Netzkomponenten-Beratung
Im Edge- und Distribution-Bereich werden seit dem Jahr 2000 Switches der Firma HP eingesetzt. Da der
Markt in diesem Gerätebereich sehr dynamisch ist, werden in regelmäßigen Abständen (ca. alle 3 Jahre)
83
Marktuntersuchungen durchgeführt, um die getroffene Switch-Auswahl zu überprüfen. Nachdem die
letzte Auswahl im Jahr 2009 stattgefunden hat, war es 2012 an der Zeit, diese zu wiederholen. Ein weiterer Grund für die neue Switch-Auswahl war der Umstand, dass der bestehende Rahmenvertrag zur Beschaffung von Netzkomponenten im April 2013 ausläuft und daher neu ausgeschrieben werden muss.
Über diesen Rahmenvertrag, an dem auch andere bayerischen Hochschulen teilnehmen, können HPNetzkomponenten zu besonders günstigen Konditionen beschafft werden.
6.6.1 Switch-Auswahl
Für die neue Switch-Auswahl wurde zunächst ein Anforderungskatalog erstellt, in dem die Mindestvoraussetzungen hinsichtlich Hard- und Software definiert sind. Anhand dieser Kriterien wurden dann die
Produkte der in Frage kommenden Hersteller auf Basis der Papierform beurteilt. Schließlich wurden daraus 3 Hersteller ausgewählt, deren Switches dann in einem Labortest und einem anschließenden Praxistest genauer untersucht wurden. Auf Grund dieser Ergebnisse wurde dann entschieden, dass auch weiterhin Switches der Firma HP zum Einsatz kommen sollen, da diese bei gleicher Funktionalität deutlich
kostengünstiger und energieeffizienter sind als die Geräte der Mitbewerber.
6.7
Telefonie
Die seit dem Umzug des LRZ nach Garching installierte VoIP-Telekommunikations-Anlage auf Basis der
offenen Software Asterisk unter Linux arbeitet weiterhin zufriedenstellend.
Der erneute Test der verschlüsselten Kommunikation zum DFN hat aus Zeitmangel leider nicht stattgefunden. Langfristig soll die Verschlüsselung für Gespräche innerhalb der VoIP-Anlage und zum DFN
aktiviert werden. Durch die Ergebnisse des Tests aus 2011 ist zuerst die Einrichtung eines Gateways geplant, um damit langfristige Erfahrungen sammeln zu können.
Insgesamt wurden durch die VoIP-Telefonanlage 2012 ca. 180.000 (2. Halbjahr 2011 ca. 121.000) Gespräche mit einer durchschnittlichen Länge von 3:24 Minuten oder insgesamt ca. 610.000 (2. Halbjahr
2011 ca. 270.000, 2010 ca. 590.000) Gesprächsminuten vermittelt.
Es konnten ca. 400 Gesprächsminuten direkt über SIP zu externen Teilnehmern abgewickelt werden. Der
Wert hat sich damit wieder auf das Niveau von 2010 erhöht. Zu den über SIP erreichbaren Zielen gehören
die Universitäten Eichstätt, Regensburg, Würzburg, Ulm, Chemnitz, Wien und Innsbruck.
Weitere Informationen zur VoIP-Telefonanlage, wie z.B. Aufbau und Vermittlungsstatistik, können den
Jahresberichten ab 2006 entnommen werden.
6.7.1 Zugang über UMTS
Nach dem Ende des Sponsorings durch Vodafone wurde die Finanzierung des UMTS Zugangspunkts
durch das LRZ übernommen, wodurch die Nutzer der migrierten Verträge weiterhin den gewohnten Weg
ins Internet mit MWN IP-Adressen nutzen können.
Eine Statistik über das übertragene Datenvolumen liegt leider nicht vor.
6.8
Unterstützende Infrastruktur-Dienste
Im Folgenden werden die Infrastrukturdienste beschrieben, die mittels Service Load Balancer, für IPv6
und auf Basis von Multiplexern erbracht werden.
6.8.1 Service Load Balancer (SLB)
Zur Zeit verarbeitet der Server Load Balancer mehr als 35.000 Verbindungen (diese entspricht gegenüber
dem Vorjahr einer Steigerung von 40 %). Daneben wird das System auch als IPv6 to IPv4 Gateway genutzt.
84
Übersicht über den Loadbalancer:
2013
2012
Virtuelle Server
280
212
Gruppen (Pools )
177
182
Pool members
482
292
Virtuelle Server stellen Dienste nach außen bereit, die Anzahl der konfigurierten Server ist angegeben,
die Anzahl der aktiven Server ist deutlich kleiner. Bei den Pools handelt es sich um Zusammenfassungen
von Rechnern zu einem Pool. Da die Rechner auf verschiedenen Ports mehrere Dienste anbieten können,
weicht diese Zahl deutlich von der Anzahl der konfigurierten Nodes (insgesamt 124) ab.
Als eines der zentralen Geräte stellt der Loadbalancer Dienste für das gesamte MWN und darüber hinaus
bereit. Insbesondere wird dieser für den Mail, Webserver und andere Dienste LRZ-intern, MWN-weit und
weltweit genutzt. Dienststörungen sind extrem selten und im gesamten letzten Jahr nur auf geplante Wartung zurückzuführen (ca. 4 Minuten). Der Server Load Balancer wurde im Jahr 2012 auf zwei seperate
Brandabschnitte verteilt, um die Redundanz zu erhöhen.
85
Abbildung 48 Anzahl der Verbindungen am Server Load Balancer 1
6.8.2 IPv6
Die Aktivitäten im Bereich IPv6 waren auch im Jahr 2012 vielfältig. So wird das TSM Backup-System
seit Februar 2012 auch über IPv6 angeboten. Seit Mai des Jahres 2012 haben die Nutzer bei Einwahl über
das VPN-System neben den IPv4-Adressen die Möglichkeit IPv6-Adressen zu beziehen. Im WLAN ist
ein erfolgreicher Testbetrieb mit einer SSID "eduroam-IPv6only", die ausschließlich IPv6 Adressen verwendet, durchgeführt worden. An mehreren Außenstandorten (Wendelstein, Triesdorf, Straubing) wurde
IPv6 ebenfalls verfügbar gemacht. Viele Dienste aller Abteilungen wurden ebenfalls IPv6-fähig gemacht,
ohne sie hier spezifisch zu erwähnen.
Die Endsystemanzahl mit nativem IPv6 in der Datenbank von Nyx, kumulativ über eine Woche, stieg
deutlich von 16.500 auf 25.100.
Jahr
2010
2011
2012
Anzahl der IPv6 Endgeräte in der Nyx-Datenbank
4.800
16.500
25.100
86
Das LRZ hat am World-IPv6 Day als Netz-Operator teilgenommen. Die Messdaten
von
http://www.worldipv6launch.org/measurements/ (abgerufen am 22.02.2013) zeigen, dass das LRZ auch
im internationalen Vergleich bereits anteilsmäßig viel IPv6 Verkehr hat und weltweit auf Platz 13 liegt.
Im Jahr 2013 ist geplant, die Sicherheitsfunktionen des Secomat-Systems (vgl. Abschnitt 14.4.1) auch für
IPv6 bereitzustellen. Dies dient vor allem dazu, den Nutzern von privaten IPv4-Adressen ohne den aufwändigen Einsatz von virtuellen Firewalls ein analoges Schutzniveau bieten zu können. Der bereits in den
letzten Jahren begonnene forcierte Rollout von IPv6 auf den Institutsnetzen wird damit in diesem Jahr
abgeschlossen werden können, so dass nur noch Netze mit einem expliziten Einspruch des Netzverantwortlichen kein IPv6 haben werden. Dabei können nach einer erfolgreichen Testphase auch die über
SDSL angebundenen Standorte bedacht werden.
Des Weiteren werden in Kooperation mit den anderen Abteilungen im LRZ die verbleibenden nicht IPv6fähigen Dienste untersucht und migriert. Bereits umgesetzt wurde der Flash-Medienserver, in der näheren
Untersuchung befinden sich die verbleibenden großen Verkehrsverursacher SuperMUC und MWNSpeicher.
6.8.3 Wellenlängenmultiplexer
Das LRZ setzt seit 1997 Wellenlängenmultiplexer (Wavelength-Division-Multiplexer, WDM) auf den
angemieteten Glasfaserleitungen der lokalen Provider (Telekom und M-net) ein. Hierdurch lassen sich auf
Leitungsebene getrennte Strukturen aufbauen. WDM-Systeme werden derzeit im MWN dazu verwendet,
um die verfügbaren Glasfaserleitungen parallel zum Produktionsnetz für folgende Dienste zu nutzen:
 Kopplung von Nebenstellenanlagen (TK-Kopplung)
 Realisierung von standortübergreifenden Intranets (z.B. Max-Planck-Gesellschaft, Verwaltung)
87
 Realisierung von Testnetzen parallel (ATM-Pilotprojekte, Fiber-Channel-Kopplung von Speichernetzen usw.)
Im MWN werden vom LRZ aktuell auf 4 Verbindungen WDM-Systeme eingesetzt (vgl. Tabelle 11).
Verbindung
WDM-Typ
Zweck
TU-Nordgelände
LMU-Stammgelände
–
MRV
800
LambdaDriver
Verbindung der Backbone-Router (1 x 10
Gbit/s)
ATM-Testnetz Erlangen -- IRT (1 x 2,4 Gbit/s
(OC48))
TU-Nordgelände
Garching
–
MRV
800
LambdaDriver
Gbit/s)
Intranet der Max-Planck-Gesellschaft (1 x 10
Gbit/s)
TU-Nordgelände
Großhadern
–
MRV
800
LambdaDriver
Gbit/s)
Intranet der Max-Planck-Gesellschaft (1 x 10
Gbit/s)
LMU-Stammgelände
Martiusstraße 4
–
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
LMUVerwaltung ( 2 x 4 Gbit/s)
Tabelle 11: WDM-Verbindungen
Die Hochschule München setzt darüber hinaus noch auf einigen internen Verbindungen WDMs zur
Kopplung von TK-Anlagen ein. Die Telefonanlagen sowie deren abgesetzten Telefonanlagenteile der
Technischen Universität und der Ludwig-Maximilians-Universität werden zum größten Teil mittels IP,
d.h. über das Standardprotokoll im MWN, miteinander gekoppelt.
6.8.4 IP-Multiplexer
IP-Multiplexer dienen zur Verbindung von Telefonanlagen über ein LAN. Sie wandeln die Daten einer
S2m-Schnittstelle (30 Sprachkanäle) in einen konstanten Strom von IP-Paketen und schicken diese an
einen anderen IP-Multiplexer, der die Rückumwandlung in S2m-Signale übernimmt. Auf diese Art und
Weise kann ein bestehendes Datennetz für die Telefonie mitverwendet werden und erbringt somit eine
deutliche Kostenersparnis, da keine dedizierten Leitungen mehr für die Kopplung von Telefonanlagen
angemietet werden müssen.
Im Münchner Wissenschaftsnetz (MWN) werden IP-Multiplexer seit dem Jahr 2005 eingesetzt. Zu-nächst
wurden sie dazu verwendet Unteranlagen innerhalb der TU und der LMU mit den zentralen Telefonanlagen zu verbinden. Im Zuge der Ersetzung bzw. der Erneuerung der Telefonanlagen wurden IPMultiplexer dort aber weitgehend überflüssig, da die neuen Anlagen selbst eine direkte Kopplung über
das IP-Protokoll ermöglichen. Lediglich die Backup-Verbindung der Telefonanlagen in Großhadern und
Oberschleißheim wird auch weiterhin mit IP-Multiplexern realisiert.
Die freigewordenen IP-Multiplexer wurden im Jahr 2006 dazu verwendet, um das sog. Querverbindungsnetz aufzubauen. Dieses verbindet die Telefonanlagen der verschiedenen Münchner Universitäten untereinander, so dass Telefongespräche zwischen den Hochschulen nicht mehr über das öffentliche Telefonnetz geführt werden müssen, sondern hierfür das MWN genutzt werden kann und damit Kosten eingespart werden. Eine direkte Kopplung der Anlagen über das IP-Protokoll (ohne IP-Multiplexer) ist nicht
möglich, da in den Universitäten Telefonanlagen verschiedener Hersteller eingesetzt werden und diese
keine einheitliche IP-Schnittstelle zur Verfügung stellen. Die Struktur der Querverbindungsnetzes zeigt
die folgende Abbildung:
88
Abbildung 49 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.
6.9
Netzmanagement und –monitoring
Zur Verwaltung und zum Betrieb des Münchner Wissenschaftsnetzes und seiner Subnetze setzt das LRZ
eine Reihe von Standard-Softwaresystemen und komplementäre Eigenentwicklungen ein. In den folgenden Abschnitten wird auf die Werkzeuge zum Netzmanagement, die LRZ-Netzdokumentation und das
mandantenfähige Netz-Performancemanagement eingegangen.
6.9.1 Netzmanagement
Das Netzmanagement bildet die Basis für die Qualität der Netzdienstleistungen des LRZ im MWN. 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 und der auf dem Server eingesetzten Netzmanagement-Software erfüllt. Die Aufgaben des Performance-Managements werden im Service Level Management Werkzeug
InfoVista umgesetzt (siehe Abschnitt Überwachung der Dienstqualität).
6.9.1.1
Netzmanagement-Software und Netzmanagement-Server
Im Jahr 2008 wurde der IBM Tivoli Network Manager IP (ITNM) als neue Netzmanagement-Software
ausgewählt. Der Auswahlprozess und die Gründe für die Wahl von ITNM sind im Jahresbericht 2008
zusammengefasst. Anfang 2009 war die Version 3.8 des IBM Tivoli Network Manager verfügbar. Mit
dieser Version wurde mit der Einführung des Tools am LRZ begonnen. Die Produktivführung des IBM
Tivoli Network Manager wurde 2010 durchgeführt. Seitdem übernimmt ITNM die Überwachung des
MWN und wird laufend an Änderungen im MWN angepasst.
Die wichtigsten in 2012 an ITNM durchgeführten Arbeiten sind:
 Mehrere Fixpacks wurden eingespielt, die viele kleinere Fehler behoben haben.
89

Das "Out of Memory" Problem bei der Discovery, das schon Ende 2011 aufgetreten ist, ist Ende
2012 wieder aufgetreten. Durch die stark gestiegene Zahl von MAC Adressen in den Forwarding
Tabellen der Switches bei Semesterbeginn (viele neue Studenten mit Notebooks und/oder Smartphones und WLAN Verbindung) stürzt der Discovery-Prozess mit einem "Out of Memory"Fehler ab. Das Problem ließ sich durch eine Vorverlegung des Starts der Discovery von 9:15 auf
8:15 vorerst beheben. Zukünftig kann es notwendig werden die Discovery komplett in die Nacht
zu verschieben.
 Zusätzlich zur CPU Auslastung (siehe 2011) wird jetzt auch noch die Last aller WLANAccesspoints überwacht und eine E-Mail an die WLAN Administratoren verschickt, wenn ein
WLAN-AP über längere Zeit eine erhöhte Last hat.
 Webcams am Rechnerwürfel und am Wetterturm wurden in die Überwachung mit aufgenommen.
 Die Regeln für das Eventmanagement der USVs wurden aktualisiert. Außerdem wird die Batterie
Restlaufzeit der USVs überwacht. Alle USVs mit einer Batterie Restlaufzeit von kleiner einer
Stunde können abgerufen werden.
 Das Erstellen und Einspielen von Zertifikaten für den Web-Server von ITNM wurde am Testsystem erprobt. Auf dem Produktionssystem wird ein Zertifikat in 2013 eingespielt.
 Verschiedene kleinere Fehler in den SNMP-MIBs der Geräte machen es immer wieder nötig, die
von ITNM nicht vollständig richtig erkannte Layer 2 Netz-Topologie des MWN durch manuelle
Eingriffe zu korrigieren.
 Die Router-, Switch- und WLAN-Accesspoint-Auswahl wurde durch begleitende Tests bzgl.
Konformität zu den IETF SNMP Standards unterstützt.
Ende 2012 wurden vom IBM Tivoli Network Manager ca. 3.700 Netzkomponenten und Server (mit netzrelevanten Diensten) überwacht. Das ist eine Steigerung von ca. 350 Geräten gegenüber 2011.
Der Netzmanagement-Server (nm2.netz.lrz.de), auf dem der IBM Tivoli Network Manager installiert ist,
hat außerdem noch folgende Funktionen:
 Arbeitsserver für die Geräteadministratoren
 Zentrales Repository für die Gerätekonfigurationen
 Notfallzugriff auf Geräte über serielle Verbindungen und analoge Modems
 Server für diverse Skripte, die für den Betrieb und das Management des MWN benötigt werden.
6.9.1.2
WWW-Server zum Netzmanagement
Auf einem separaten Webserver sind seit 2002 aktuelle Informationen über die Topologie für die Nutzer
des Münchner Wissenschaftsnetzes und die Performance des MWN-Backbone abrufbar. Unter
http://wwwmwn.lrz.de/ werden Performance-Daten zu den wichtigsten Elementen des MWN (Backbone,
X-WiN Anbindung, IPv6 Verkehr, Secomat, Demilitarisierte Zone (DMZ) des LRZ, Modem- und ISDNZugang, usw.) dargestellt. Die Performance-Daten werden dazu jeweils in Form von MRTG-Statistiken
bereitgestellt. MRTG (siehe http://www.mrtg.org) ist ein Werkzeug zur Überwachung des Verkehrs auf
Netzwerkverbindungen, kann aber auch zur Überwachung anderer Kennzahlen eingesetzt werden. Der
WWW-Server zum Netzmanagement dient als Schnittstelle zu den Kunden im MWN, um die NetzDienstleistung MWN des LRZ transparenter zu machen. 2012 gab es hier keine wesentlichen Änderungen.
6.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.
2012 wurde die Netzdokumentation auf die zum damaligen Zeitpunkt aktuellste Version 2.13.13 des zugrunde liegenden Anwendungsservers Zope migriert. Im Zuge der Migration wurden außerdem alle Zope
Datenbank-Treiber (für die Oracle-, Postgres- und ODBC-Datenbank-Schnittstellen) auf den Datenbank
Treiber SQLAlchemy umgestellt. SQLAlchemy ist Open Source und wird (im Gegensatz zu den alten
Datenbank Treibern) aktiv von einer Community gepflegt.
Daneben wurde noch die Subnetz- und Subnetzbereichsverwaltung erweitert. Bisher konnte zu jedem
Subnetzbereich nur ein zugehöriger Unterbezirk gespeichert werden. In manchen Fällen erstreckt sich ein
90
Subnetzbereich aber über mehrere Unterbezirke. Das konnte aber nicht adäquat in der Netzdokumentation
abgebildet werden. Deshalb wurden die Datenbank und das Web-Interface der Netzdokumentation so
erweitert, dass zu jedem Subnetzbereich jetzt mehrere Unterbezirke abgespeichert werden können.
6.9.2.1
MWN Visualisierung mit OpenStreetMap und Google Earth
Die Unterbezirke des MWN wurden bereits vor einigen Jahren in die Karten von Google Maps mittels
Icon integriert und aus der Netzdokumentation wird auf den jeweiligen Kartenausschnitt in Google Maps
verlinkt. Eine direkte Integration der Google-Maps-Karten in die Netzdokumentation ist aus LizenzGründen nicht möglich bzw. würde eine kostenpflichtige Lizenz für die Google Maps API von Google
erfordern.
Deshalb ist es ein Ziel, die Visualisierung der Unterbezirke im MWN von Google Maps auf OpenStreetMap umzustellen. In einem ersten Schritt wurden in 2012 die Standort-Koordinaten (Längen- und Breitengrad) und die Art des Unterbezirk (das Icon in Google Maps) per Skript aus Google Maps ausgelesen,
auf unterschiedliche Arten aufbereitet und in verschiedenen KML (Keyhole Markup Language) Files
abgespeichert. Mittels dieser KML Files kann dann eine direkte Visualisierung des MWN in der Netzdokumentation mit den Karten von OpenStreetMap erfolgen. Die technische Umsetzung dieser Visualisierung beruht wesentlich auf der Javascript Bibliothek OpenLayers (http://openlayers.org/). OpenLayers
erlaubt die Visualisierung von beliebigen Overlays über den Kartendaten von OpenStreetMap (wobei
auch andere Kartenquellen benutzt werden können, unter anderem auch Google Maps). Mit einem Plugin
bzw. einer Ergänzung zu OpenLayers konnte auch eine animierte Cluster Darstellung realisiert werden.
Neben der Visualisierung der Unterbezirke wurde auch noch eine Visualisierung der Verbindungen zwischen den Unterbezirken realisiert, indem aus der Netzdokumentation die Verbindungsdaten (Anfang,
Ende, Bandbreite, ...) ausgelesen werden und zu den KML Files hinzugefügt werden. Außerdem wurde
noch eine Darstellung der WLAN Standorte erstellt. Diese soll auch außerhalb der Netzdokumentation für
alle Nutzer im MWN zugänglich gemacht werden, so dass die Standorte mit WLAN Zugang im MWN
einfach ersichtlich sind.
In den folgenden Abbildungen werden die verschiedenen Ansichten der Visualisierung des MWN in
OpenStreetMap dargestellt. In der Abbildung "Visualisierung des MWN in OpenStreetMap" ist eine
Übersicht über das MWN zu sehen. Die meisten Unterbezirke sind hier zu Clustern (gelbe Kreise) zusammengefasst. Die Cluster Darstellung hat dann Vorteile, wenn zu viele einzelne Icons zu unübersichtlich wären. Die Zahlen in den Clustern entsprechen der Anzahl der Unterbezirke die durch das Cluster
repräsentiert werden. Es ist möglich auf die Cluster-Icons zu klicken, dann wird ein Fenster mit allen
Standorten des Clusters angezeigt.
In dem Auswahlfenster rechts oben kann sowohl die Grundkarte als auch das gewünschte Overlay ausgewählt werden, wobei auch mehrere Overlays gleichzeitig dargestellt werden können.
91
Abbildung 50 Visualisierung des MWN in OpenStreetMap
In der Abbildung "Unterbezirke und Verbindungen am Campus Garching" ist ein Ausschnitt zu sehen,
der den Campus in Garching zeigt. Hier sind alle Cluster aufgrund des höheren Zoom-Faktors aufgelöst.
Die Farben der Icons repräsentieren die Organisations-Zugehörigkeit der Standorte (blau für TU München, grün für LMU München, andere Farben für sonstige Standorte z.B. rot für Max-Planck-Institute).
Die LRZ-Standorte sind mit dem LRZ-Logo versehen. Verbindungen können auch angeklickt werden,
dann wird eine Information zu der Verbindung angezeigt. Die Farben der Verbindungen repräsentieren
die Bandbreite der Verbindung, blau steht z.B. für Verbindungen mit größer gleich 10 Gbit/s und rot für
Verbindungen mit größer gleich 1 Gbit/s und kleiner 10 Gbit/s. Alle anderen Farben von Verbindungen
repräsentieren Verbindungen mit kleineren Bandbreiten.
92
Abbildung 51 Unterbezirke und Verbindungen am Campus Garching
In der Abbildung "WLAN Standorte in der Münchner Innenstadt" ist eine Übersicht der WLANStandorte in der Innenstadt von München zu sehen. Eng zusammen liegende Standorte werden hier ebenfalls zu Clustern (blaue Kreise) zusammengefasst. Die Zahlen in den Clustern entsprechen hier aber nicht
der Zahl der Standorte, sondern der Anzahl der WLAN-Accesspoints. Die Zahlen über den ungeclusterten
WLAN-Symbolen entsprechen ebenso der Anzahl der WLAN-Accesspoints an diesem Standort. Ein
Cluster kann wieder angeklickt werden, dann erscheint ein Fenster mit einer Übersicht der Standorte des
Clusters und der WLAN-APs pro Standort.
93
Abbildung 52 WLAN-Standorte in der Münchner Innenstadt
Im Gegensatz zu obiger Abbildung entspricht die Abbildung "WLAN-Standorte im MWN (BenutzerSicht)" einer Ansicht, wie sie für Benutzer im MWN angeboten werden soll. Hier wird ein anderes
WLAN-Symbol mit Schattenzeichnung verwendet und die Zahlen entsprechen der Zahl der Standorte und
nicht der Zahl der WLAN-APs. Ein einzelner Standort kann auch angeklickt werden, dann erscheinen
genauere Information zu diesem Standort.
94
Abbildung 53 WLAN-Standorte im MWN in OpenStreetMap (Benutzer-Sicht)
In allen Overlays kann über eine Eingabezeile nach beliebigen Informationen eines Unterbezirks gesucht
werden, z.B. nach dem Unterbezirkskürzel oder der Straße. Bei einem Treffer wird der entsprechende
Unterbezirk automatisch in der Karte angezeigt. Bei mehreren Treffern kann mit den Cursortasten oder
der Returntaste durch die Treffer geblättert werden.
Zusätzlich zu der Visualisierung des MWN in OpenStreetMap wurden auch noch KML-Files zu Visualisierung des MWN in Google Earth erstellt. Die KML-Files für Google Earth unterscheiden sich nur sehr
geringfügig von denen für OpenStreetMap. Der Hauptunterschied ist, dass hier mehrere KML-Files zu
einem KMZ-File zusammengefasst wurden, so dass die Nutzung mit Google Earth einfacher ist. Ein Vorteil von Google Earth ist flexiblere Auswahl der dargestellten Informationen. Z.B. können nur alle Standorte der TU München angezeigt werden oder nur alle 10 Gbit/s Verbindungen.
Die KML-Files für OpenStreetMap und das KMZ-File für Google Earth werden zweimal am Tag per
Skript aktualisiert.
Bis jetzt erfolgt die Pflege der Längen- und Breitengrade der Unterbezirke aber immer noch in Google
Maps, da eine Editier-Schnittstelle für diese in der Netzdokumentation noch nicht existiert. Das muss erst
noch in einem weiteren Schritt implementiert werden. Bis dahin wird weiterhin die Editier-Schnittstelle
von Google Maps genutzt, die Daten per Skript ausgelesen und dann in KML Files abgespeichert.
6.9.2.2
Inhaltliche Aktualisierung der Netzdokumentation
Um die Aktualität der Informationen zu den Netzverantwortlichen zu sichern, wurde 2012 wieder eine
Benachrichtigung und Überprüfung der Kontaktinformationen durchgeführt. Jeder der 898 Netzverantwortlichen erhielt per E-Mail die Liste der Subnetze und Subnetzbereiche für die er zuständig ist und die
95
in der Netzdokumentation gespeicherten persönlichen Daten. Diese Daten sollten entweder bestätigt oder
eventuelle Fehler korrigiert werden. In der E-Mail wurde auch wieder auf das neue NeSSI-Interface für
Netzverantwortliche hingewiesen. An die Netzverantwortlichen, die auch nach drei Monaten noch nicht
geantwortet hatten, wurde per Skript automatisiert eine E-Mail zur Erinnerung geschickt.
Bei rund 260 Einträgen zu Netzverantwortlichen waren kleinere oder größere Änderungen während der
Aktualisierung notwendig. Bei allen anderen Netzverantwortlichen blieben die Einträge unverändert.
Neben dieser jährlichen Aktualisierung werden aktuelle Änderungen im MWN laufend in die Netzdokumentation übernommen.
6.9.3 Ü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 2012 wurde der InfoVista-Server auf die neue Version 4.2 und Windows 2008 (64 bit) migriert
(bisher 4.0 bzw. Windows 2003). Die Migration wurde durchgeführt, indem der neue Server parallel aufgesetzt wurde und anschließend die InfoVista-Datenbank auf den neuen Server kopiert wurde. Als Nebeneffekt dieser Migration konnte die InfoVista-Datenbank durch das dazu notwendige Backup und Restore von über 35 GB auf ca. 23 GB verkleinert werden. Die Verringerung des Platzbedarfs beruht darauf,
dass der schon in 2011 durch eine Aufräumaktion als frei in der Datenbank markierte Platz, nun durch das
Backup und Restore tatsächlich nicht mehr belegt wird. Durch die Umstellung auf Windows 2008 und der
darin enthalten Firewall war außerdem eine bessere Absicherung des InfoVista-Servers möglich.
Damit die Datenbankgröße der InfoVista-Datenbank weiter in etwa gleich bleibt, wurden die bestehenden
InfoVista Reports bzgl. ihres Platzbedarfs in der Datenbank untersucht. Dabei wurde der "Switch Device
Report" als der Report mit dem mit Abstand größtem Platzbedarf identifiziert. Um hier die Situation zu
entschärfen und die Instantiierung weiterer Switch Reports zu ermöglichen, wurde in diesem Report das
Abfrage Intervall für die Konfiguration des Switches von 5 Minuten auf eine Stunde erhöht und ein Teil
der Konfigurations-Abfrage weggelassen, dadurch sinkt der Platzbedarf des Reports deutlich.
Ein wesentlicher Teil der Überwachung der Dienstqualität mit InfoVista sind die stündlichen Mittelwerte
der Verkehrsauslastung auf den Interfaces der Backbone-Router. Dabei wird eine wöchentliche Übersicht
aller Router-Interfaces erstellt, deren Auslastung im Stundenmittel über 30 Prozent liegt. Um hier eine
noch zuverlässigere Erkennung von Engpässen zu ermöglichen wurde schon in 2011 damit begonnen
zusätzlich noch eine Überwachung der 15-Minuten-Mittelwerte der Router-Interfaces aufzubauen. In
2012 wurde die Überwachung der Router-Interfaces vollständig auf 15-Minuten-Mittelwerte umgestellt
und die Überwachung der stündlichen Mittelwerte beendet.
Desweiteren wurde die Router- und Switch-Auswahl in 2012 durch parallele Tests mit InfoVista unterstützt.
6.9.4 Evaluation VistaFoundation Kit 4.3
Das VistaFoundation Kit (VFK) ist eine Erweiterung des im MWN eingesetzten InfoVista-Server um die
Komponenten automatische Discovery des Netzes, eine (Last-)Verteilung der Statistik Abfrage auf mehrere Server, eine Administrations-Konsole und ein erweitertes Web-Interface. Das VistaFoundation Kit
basiert dabei auf einer zentralen Oracle-Datenbank zusätzlich zu den ObjectStore Datenbanken auf den
InfoVista-Servern (beim VFK können mehrere InfoVista Server zur Last-Verteilung betrieben werden).
Die Entwicklung bei der Firma InfoVista scheint in die Richtung zu gehen, nur noch das VFK als Produkt
anzubieten und zu unterstützen. Das kann bedeuten, dass in Zukunft kein Support mehr für die im MWN
eingesetzte Lösung erhältlich ist (derzeit wird sie aber noch unterstützt). Insbesondere aus diesem Grund
wurde in 2012 das VistaFoundation Kit in Version 4.3 getestet.
Die Evaluation hat aber ergeben, dass der Einsatz des VFK im MWN derzeit viele Nachteile und Probleme mit sich bringen würde. Diese Nachteile und Probleme sind:
96

Die weiteren Komponenten des VFK (Discovery, Last-Verteilung, erweitertes Web-Interface und
zentrale Oracle Datenbank) bringen einen erheblichen Mehraufwand bei der Administration mit
sich, der durch die spezielle Administrations-Konsole nicht ausgeglichen wird. Speziell die Anpassung von Reports an das MWN bzw. die Neuentwicklung von Reports wird durch die neuen
Komponenten erheblich komplexer.
 Die Unterstützung der im MWN eingesetzten Netz-Geräte ist eher schlecht. Speziell die HP LAN
Switches wurden während des Tests nur unzureichend erkannt und es konnten keinerlei Reports
darauf aufgesetzt werden. Eine einfache Lösung dieses Problems war auch mit Unterstützung seitens der Firma InfoVista nicht möglich.
 Eine Migration der bisher bestehenden selbst entwickelten Reports auf die neue Plattform müsste
manuell gemacht werden und wäre wahrscheinlich relativ aufwendig.
 Ein Migration der bisher gesammelten Daten auf die Plattform wäre wahrscheinlich gar nicht
möglich oder nur mit unverhältnismäßig großem Aufwand.
 Das erweiterte Web-Interface des VFK ist ziemlich unübersichtlich und nicht intuitiv benutzbar,
da es aus verschiedenen und jeweils etwas anders zu benutzenden Teilen besteht. Z.B. ist ein Teil
in Java und Javascript implementiert und ein anderer komplett mit der Flash-Technologie.
 Die Lizenzkosten für das VFK wären deutlich höher als bisher (ca. 5 - 10 mal so hoch), insbesondere weil auf eine Device Anzahl basierte Lizenz umgestellt werden müsste (bisher ist die Lizenz
unabhängig von der Anzahl der Devices).
Aus diesen Gründen wird das VFK im MWN vorerst nicht eingesetzt. Eventuell wird es nochmals getestet, falls eine Konsolidierung beim Web-Interface erfolgt.
6.9.5 Reporting für Netzverantwortliche
Die Institute im MWN haben mit den Switch-Reports für Netzverantwortliche über die WWWSchnittstelle VistaPortal (http://vistaportal.lrz.de) zu InfoVista eine Übersicht über das Gerät und auch
über die Port-Auslastung der Switche, an denen sie angeschlossen sind. Durch die Reports wird die
Diensterbringung des LRZ transparenter, außerdem kann die Fehlersuche im Institut dadurch erleichtert
werden. Die Reports können in HTML-, GIF-, PNG-, PDF-, Text- oder Excel-Format abgerufen werden.
Zu den bereits in den Jahren 2003 – 2011 instantiierten Reports für Netzverantwortliche kamen 2012
noch Reports für das Department für Geo- und Umweltwissenschaften und die Rechtsinformatik an der
LMU hinzu. Die Überwachung des Verkehrsvolumens der Firmen im Garchinger Gründerzentrum GATE
wurde eingestellt, weil kein Bedarf mehr dafür bestand.
Um die Aktualität der hier bereitgestellten Daten sicherzustellen wurden alle konfigurierten Reports und
Instanzen für Switche überprüft und falls notwendig korrigiert bzw. durch neue Reports und Switch Instanzen ersetzt.
Beim Web-Interface VistaPortal selbst gab es 2012 keine Änderungen. Es wurde aber die Version 4.2 von
VistaPortal (derzeit 4.0) in einer Testumgebung aufgesetzt, um speziell die Anbindung an LRZ-SIM zur
Benutzer-Authentifizierung zu erproben.
6.10 Projekte im Bereich Netze
Auch 2012 wurden die Projektarbeiten im Bereich Netze erfolgreich fortgesetzt. In den folgenden Abschnitten werden die aktuellen Arbeiten am D-Grid-Projekt GIDS, am CELTIC-BMBF-Projekt SASER,
am Customer Network Management und im Rahmen des europäischen Forschungsnetzverbunds Géant
beschrieben.
6.10.1 D-Grid GIDS
Zur Sicherung der Nachhaltigkeit der deutschlandweiten Grid-Infrastruktur ist insbesondere der Bereich
des Sicherheitsmanagements zu berücksichtigen. Das GIDS-Projekt hat die Entwicklung, Projektierung
und Inbetriebnahme eines Grid-basierten, föderierten Intrusion Detection Systems (GIDS) sowie die
Überführung des GIDS in den D-Grid-Produktionsbetrieb zum Ziel. Die Vision von GIDS ist es, einzelne
Sicherheitssysteme, die von Ressourcenanbietern betrieben werden, zu kombinieren, um eine globale
Sicht auf Sicherheitsvorfälle im Grid zu erhalten.
97
Das Projekt, das zum 01.07.2009 begonnen und planmäßig zum 30.06.2012 abgeschlossen wurde, wurde
als GAP-Projekt im Rahmen des D-Grids vom Bundesministerium für Bildung und Forschung gefördert.
Die Projektlaufzeit betrug 36 Monate und wurde neben dem LRZ vom Regionalen Rechenzentrum für
Niedersachsen (RRZN) und der DFN-CERT Services GmbH durchgeführt, mit den assoziierten Partnern
Stonesoft GmbH und Fujitsu Technology Solutions GmbH, wobei die Konsortialführung beim LRZ lag.
Details zur Problemstellung, zu den Zielen und den bisher abgeschlossenen Arbeitspaketen des Projektes
sind in den Jahresberichten 2009, 2010 und 2011 zu finden.
Im Projekt wurden im Jahr 2012 folgende Arbeitspakete bearbeitet, deren Ergebnisse nachfolgend näher
beschrieben werden:
 Kalibrierung des GIDS in Bezug auf das D-Grid Umfeld
 Tragfähigkeitsnachweis / Tests der Leistungsfähigkeit
 Produktivführung des GIDS
6.10.1.1
Kalibrierung des GIDS in Bezug auf das D-Grid Umfeld
Die Aufgabe in diesem Arbeitspaket bestand darin, die Angriffserkennung an die im D-Grid vorherschenden Gegebenheiten anzupassen. Dafür wurden die bereits im LRZ betriebenen Regelsätze des netzbasierten IDS Snort um Grid-spezifische Programme und Protokolle erweitert (z.B. GSISSH statt SSH,
GridFTP statt FTP). Diese Anpassung ist nötig, da die herkömmlichen Erkennungsmuster bei Gridspezifischen Programmen nicht mehr greifen, da beispielsweise durch Nutzung von GSISSH nicht der
Standard-SSH-Port 22 verwendet wird. Diese Regelsätze wurden im praktischen Einsatz getestet, evaluiert und stetig verbessert, um die Erkennungsrate zu maximieren und die False-Positiv-Rate zu minimieren. Dabei hat sich gezeigt, dass die Erweiterung der Regelsätze in produktiven Umgebungen ohne Seiteneffekte durchgeführt werden konnte. Zusätzlich wurde mit der Integration von OSSEC in die GIDSSensorikstruktur eine Host-basierte Erkennung von Rootkits realisiert, die auf Gridknoten lauffähig ist.
6.10.1.2
Tragfähigkeitsnachweis / Tests der Leistungsfähigkeit
In diesem Arbeitspaket bestand die Aufgabe darin, einen Nachweis für die Leistungsfähigkeit des GIDSSystems zu erbringen, wobei neben dem Nachweis, dass die zu erwartende Grundlast für die Komponenten zu bewältigen ist, auch ein Nachweis für die Erkennungsleistung des Gesamtsystems zu führen war.
Für die D-Grid-Ergebniskonferenz wurde von allen Projektpartnern die Realisierung einer vollständigen
GIDS-Instanz durchgeführt, die mit Interaktion der Workshop-Teilnehmer auf dem dortigen GIDSWorkshop vorgestellt und nach und nach in Betrieb genommen wurde. Insbesondere für die Vorbereitung
der Ergebniskonferenz wurden die mitgebrachten virtuellen Maschinen vom LRZ konfiguriert und die
benötigte Hardware organisiert. In diesem Zuge wurde die vorhandene Dokumentation deutlich erweitert
und präzisiert, um den Aufwand für die nötigen Schulungen und den Betrieb der Komponenten zu reduzieren. Insbesondere wurde eine detailierte Installationsanleitung erstellt, die auch in den Anhang von
Meilenstein 36 (http://www.grid-ids.de/documents/GIDS_MS36.pdf ; Juni 2012) mit eingeflossen ist.
Um die Erkennungsraten von GIDS reproduzierbar nachzuweisen, wurden in enger Kooperation mit den
anderen Projektpartnern diverse Wurmausbreitungen wohlerforschter Wurminstanzen simuliert, unter
anderem
 Scalper
 Code Red v2
 Code Red II
Dabei waren die Ziele die Bewertung der Qualität des kooperativen GIDS-Ansatzes und die empirische
Beurteilung der Skalierbarkeit von GIDS. Ergebnis dieser Simulationen war, dass auch das Verarbeiten
großer Datenmengen von der Infrastruktur ohne Probleme bewältigt wird.
Die Leistungsfähigkeit wurde durch mehrere Lasttests mit künstlich erzeugten Events geprüft. Dadurch
wurde zum einen die Leistungsfähigkeit der GIDS-Bus-Kommunikationsinfrastruktur gezeigt; zum anderen wurde nachgewiesen, dass zur Teilnahme an GIDS keine besonders leistungsfähige Hardware eingesetzt werden muss: Im Gegenteil wurde z.B. beim Hands-On-Workshop im Rahmen der Abschlusskonferenz gezeigt, dass eine einzige physische Maschine mehr als eine Handvoll virtuelle Maschinen hosten
kann, die D-Grid-Ressourcen mit installierten GIDS-Sensoren und den weiteren GIDS-Komponenten
betreiben.
98
6.10.1.3
Produktivführung des GIDS
Neben der am RRZN, den am DFN-CERT vorhandenen Sensoriken und den aus der prototypischen Entwicklung noch vorhandenen Senoriken am LRZ sind nun mehrere Standorte produktiv mit dem GIDS
verbunden. Die Meldungen, die innerhalb von GIDS ausgetauscht werden, können über das GIDS-Portal,
das unter https://www.grid-ids.de/index.php?id=3 bzw. unter https://gidsportal.dfn-cert.de/ zur Verfügung
steht, eingesehen werden.
Es wurde während der Projektlaufzeit ein Konzept zum Betrieb und zur Pflege der GIDS-Komponenten
über die Laufzeit von GIDS hinaus erarbeitet, das als Anhang zum Meilenstein 36 (http://www.gridids.de/documents/GIDS_MS36.pdf ; Juni 2012) veröffentlicht wurde. Weiterhin wurden innerhalb von
diesem eine Anleitung zur Benutzung des Portals und eine Anleitung zum Anbinden einer administrativen
Domäne an das GIDS fertiggestellt.
Übergabe des Produktivsystems ans DFN-CERT. Dabei wurde die Portalsoftware, die während der Projektlaufzeit zu Entwicklungszwecken auf einem virtuellen Server am LRZ gehostet wurde, für die DFNCERT-Infrastruktur angepasst und die Übertragung der nötigen Daten durchgeführt. Der Betrieb der Korrelationsinfrastruktur wird weiterhin über die Projektförderphase hinaus durch das LRZ aufrechterhalten.
6.10.2 SASER
Das Verbundprojekt Safe and Secure European Routing (SASER-SIEGFRIED), das zum 01.08.2012
begonnen wurde, wird vom Bundesministerium für Bildung und Forschung gefördert. Die Projektlaufzeit
beträgt 36 Monate und wird neben dem LRZ von der Nokia Siemens Networks Management International
GmbH (NSN), von der Nokia Siemens Networks Optical GmbH, der Technischen Universität München,
der Technischen Universität Berlin, der Fraunhofer Gesellschaft HHI, der Ruhr-Universität Bochum, dem
Zuse Institut Berlin (ZIB), der Technischen Universität Braunschweig, der Universität Tübingen, der
Universität Würzburg, der FH Potsdam (IxDS GmbH), dem Fraunhofer AISEC und der Technischen
Universität Dortmund durchgeführt.
Das Internet wurde zu einem unverzichtbaren Teil der Infrastruktur für die meisten Aspekte des täglichen
Lebens und hat sich zu einer grundlegenden Infrastruktur für Europa entwickelt. Der ununterbrochene,
zuverlässige und sichere Zugriff auf das Internet wird als ein Grundbedürfnis für alle Bürger und als ein
signifikanter wirtschaftlicher Faktor gesehen.
Der heutigen Infrastruktur Internet fehlen im aktuellen Zustand viele der Merkmale, die ein vertrauenswürdiges, sicheres und geschütztes Kommunikationsmedium in Verbindung gebracht werden. Die Anzahl
der Angriffe auf Internet-verbundenen Systemen wachsen und die Angriffe werden im Laufe der Zeit
immer technisch komplexer als in der Vergangenheit, so dass die Erkennung und Verhinderung von
Schadensfällen immer schwerer ist. Mit der zunehmenden Anzahl von Anwendungen in sensiblen Bereichen, wie beispielsweise E-Government oder E-Commerce, gewinnen insbesondere die folgenden kritischen Fragen und Problemstellungen an Bedeutung: Sicherheit und Datenschutz, Service-Qualität und
Zuverlässigkeit, sofortiger und geschützter Zugang zu Systemen und Diensten und Skalierbarkeit.
Innerhalb des BMBF-geförderten CELTIC-Projekts SASER-SIEGFRIED werden von allen Projektpartnern in enger Zusammenarbeit Netz-Architekturen und Technologien für sichere zukünftige Netze entwickelt. Das Ziel ist es, Sicherheitslücken der heutigen IP-Schicht-Netze im Zeitrahmen bis etwa 2020 zu
korrigieren. Zur Erreichung des Ziels werden die folgenden Aktivitäten durchgeführt:
Zum einen wird die Datenübertragung so weit wie möglich in die tieferen Netzwerk-Layer (Physical Layer und Data Layer) zu verlagern, um die Notwendigkeit von IP-Routern zu reduzieren, die in der Vergangenheit als sicherheitskritisch aufgefallen sind. Dies kann erreicht werden, wenn Technologien wie beispielsweise die Netz-Virtualisierung und effiziente Redundanzkonzepte umgesetzt werden, die auf flexiblen und hoch verfügbaren optischen Systemen basiert realisiert werden.
Zweitens werden Mechanismen der Sicherheit für zukünftige Netze entwickelt, die auf einer Analyse der
verbleibenden Sicherheitsprobleme in der IP-Schicht (zum Beispiel Backdoor- und Anomalie-Detection)
basieren.
Im Jahr 2012 wurde das Teilprojekt TP-1 („Komponentenkopplung an Netzmanagementsysteme“) durchgeführt, welches noch planmäßig in Arbeit ist. TP-1 umfasst die Abstimmung der zusätzlichen technischen Schnittstellen in Zusammenarbeit mit den anderen Projektpartnern, die Modellierung der neu zu
verwaltenden sicherheitsspezifischen Informationen in einem auf die Aufgaben von Managementsyste-
99
men abgestimmten Datenformat, die Festlegung der Kommunikation, die zum Auslesen und zum Schreiben über diese zusätzlichen Schnittstellen erforderlich ist, und eine Implementierung dieser Konzepte. Im
Jahr 2012 lag der Schwerpunkt der Arbeiten auf Seiten des Monitoring, das heißt auf dem Auslesen sicherheitsrelevanter Kennzahlen aus aktiven Netzkomponenten durch Netzmanagementsysteme; die Rückrichtung, das heißt die Steuerung und Beeinflussung einzelner Netzkomponenten durch zentrale Netzmanagementsysteme, ist Gegenstand der weiteren Arbeiten.
Bei der Analyse der möglichen technischen Schnittstellen zur Übertragung sicherheitsrelevanter Informationen zwischen Netzkomponenten und -managementsystemen wurde zunächst die Problematik identifiziert, dass sich eine allgemeinverbindliche Definition von Sicherheitskennzahlen (engl. meist als security
metrics bezeichnet) bisher noch weder in der Praxis noch in wissenschaftlichen Abhandlungen hinreichend durchgesetzt hat. Die Ermittlung und Auswertung von Sicherheitskennzahlen ist für SASERSIEGFRIED jedoch essentiell, da auf diesen basierend Routingentscheidungen getroffen werden sollen.
Somit ist eine allgemeinverbindliche Definition von Sicherheitskennzahlen für die weiteren Schritte in
diesem Teilprojekt nötig, da sowohl die Modellierung der Informationen als auch die Implementierung
von der Definition dieser abhängen.
Um Sicherheitskennzahlen unter Berücksichtigung des State-of-the-Art exakt definieren zu können, wurde im Jahr 2012 eingangs eine breite Literaturrecherche durchgeführt, deren Ziel es war, die aktuellen
wissenschaftlichen Arbeiten und praktischen Umsetzungen zu diesem Thema zusammenzusuchen und zu
bewerten. Dabei wurden in einem ersten Schritt die Zielsetzungen und Herausforderungen beim Einsatz
von Sicherheitskennzahlen herausgestellt; dabei wurde gezeigt, dass einige weit verbreitete sog. „Sicherheitsmetriken“ die mathematischen Grundanforderungen an Metriken, insbesondere die Dreiecksungleichung, nicht erfüllen, so dass der unmittelbare Einbezug derart quantifizierter Sicherheitseigenschaften
zum Beispiel in Routingprotokollen zwangsweise zu verfälschten Ergebnissen führen würde. Auf dieser
Basis wurden Kriterien erstellt, die Sicherheitskennzahlen erfüllen müssen, um im Rahmen von SASERSIEGFRIED eingesetzt werden zu können.
Neben der Spezifikation eines automatisierenden Messverfahrens zur regelmäßigen Akquisition der Sicherheitskennzahlen wurde damit begonnen, eine Reihe von Sicherheitskennzahlen zu definieren, die
projektweit zur Diskussion gestellt werden sollen. Die Koordination mit den Projektpartnern in diesem
Bereich ist etwas verzögert, da das SASER-Gesamtarchitektur-Referenzmodell, in das auch die Sicherheitskennzahlen eingebettet werden müssen, erst später als erwartet zur Verfügung stand. Ein Teilziel von
TP-1 besteht darin, aus den entwickelten Sicherheitskennzahlen auch einige sog. Security Key Performance Indicators (SKPIs) auszuwählen, die bei der weiteren Konzeption projektpartner-übergreifend
immer berücksichtigt werden sollen. Zudem ist noch abzustimmen, wie die in anderen Teilprojektenvon
SASER-SIEGFRIED ermittelten Ergebnisse quantitativ in den Netzmanagementsystemen ausgewertet
werden sollen.
Weiterhin wurde eine Zusammenarbeit mit der Fachhochschule Potsdam (IxDS GmbH) angestoßen. Die
Fachhochschule Potsdam ist innerhalb von SASER-SIEGFRIED für das Design und graphische Interface
einer Benutzeroberfläche zur Angriffserkennung beteiligt. Das LRZ stand im Rahmen von Interviews und
Ideenaustausch auf Basis der langjährigen betrieblichen Erfahrung im Netzmanagement und dem Betrieb
großer Netze beratend zur Seite. Auf dieser Basis wurde auch eine im Jahr 2012 noch nicht abgeschlossene Diskussion mit der Universität Würzburg und NSN angestoßen, in der es um die Wahl des Protokolls
zum Ansteuern des Netzmanagements geht. Da die zu entwickelnde Lösung auf Software defined networking (SDN) basieren soll, wird voraussichtlich OpenFlow das Mittel der Wahl sein; für LegacyUmgebungen, in denen unsere Prototypen evaluiert werden sollen, ist jedoch auch das langjährig bewährte SNMP (Simple Network Management Protocol) zu unterstützen. Die vom zum Netzmanagement eingesetzten Protokoll unabhängige Integration in die Control Plane der Netzkomponenten wird parallel
dazu mit den Projektpartnern diskutiert.
6.10.3 Customer Network Management (CNM)
Das Customer Network Management (CNM) wurde ursprünglich für das MWN (Münchner Wissenschaftsnetz) entwickelt, dann innerhalb mehrerer DFN-Projekte für das B-WiN, G-WiN und schließlich
das X-WiN erweitert.
Customer Network Management (CNM) bezeichnet allgemein die kontrollierte Weitergabe von Managementinformationen durch den Anbieter eines Kommunikationsdienstes an die Dienstnehmer sowie
100
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. CNM trägt dem Paradigmenwechsel
vom komponentenorientierten zum dienstorientierten Management dadurch Rechnung, dass nicht mehr
ausschließlich Low-level-Daten - wie z.B. Management Information Base (MIB)-Variablen der Komponenten - betrachtet werden, sondern kundenorientiert aufbereiteten Informationen über die Einhaltung der
vertraglich ausgehandelten Dienstvereinbarungen.
Die CNM-Anwendung für das X-WiN ist unterteilt in die zwei Anwendungen Topologie und Datenvolumen:
 Die CNM-Anwendung Topologie dient der Visualisierung der X-WiN-Topologie/des Zustands
der IP-Infrastruktur (siehe Abbildung 54).
Abbildung 54 Die CNM-Anwendung "Topologie"

Anhand dieser Anwendung wird den DFN-Kunden (Anwendern) ein Überblick über den aktuellen und historischen Zustand und Qualität der IP-Infrastruktur gegeben. Für jede im X-WiN bestehende Verbindung werden Bandbreite, Auslastung und Durchsatz graphisch dargestellt; für jeden Knoten (Router) die Rate der weitergeleiteten Pakete. Auf der Netzebene gibt es derzeit 57
Standorte, die jeweils einen Router enthalten. Diese Router sind direkt mit den Kundeninfrastrukturen verbunden und enthalten auch verschiedene Verbindungen zu kommerziellen Netzbetreibern sowie dem europäischen Wissenschaftsnetz Géant. Die mit hierarchischen Karten arbeitende
Anwendung wurde im April 2004 für alle X-WiN-Anwender freigegeben und ist seitdem im Betrieb.
Die Topologie-Anwendung gibt es zusätzlich auch für das MWN und für Géant, jeweils als getrennte CNM-Server-Instanzen laufend.
Die CNM-Anwendung Datenvolumen dient der Bereitstellung von dienstorientierten IPInterfacestatistiken für die DFN-Anwender.
Die DFN-Anwender können mit Hilfe der CNM-Anwendung Datenvolumen die Verkehrsvolumina, die sie aus dem X-WiN empfangen bzw. gesendet haben, abrufen. Für jeden bestellten IPDienst wird für den Anwender ein eigenes CNM-Auswahlfenster für IP-Interfacestatistiken bereitgestellt. Es werden Tages-, Wochen-, Monats- und Jahresstatistiken bereitgestellt.
101
Bei der CNM-Anwendung handelt es sich um eine verteilte Client/Server-Architektur. Der Client ist als
Java-Applet erhältlich. Der Server ist in C++ implementiert. Der Server bedient sich einer XMLDatenbank, GIS2 (Globale X-WiN-Informationssystem), die alle X-WiN-Kunden/Dienst-Daten verwaltet. Als Kommunikationsmiddleware sowohl zwischen dem Client und dem Server als auch zwischen
dem Server und GIS2 dient CORBA.
Da am LRZ alle Server nach Möglichkeit als virtuelle Server in der VMware-Infrastruktur laufen sollen
und diese unter der vorherigen Sparc-Solaris Architektur mit VMware nicht virtualisiert werden konnten,
wurde eine Portierung des CNM-Systems auf Linux-x86 gewünscht. 2010 wurde bereits ein Portierungsplan erstellt für die schrittweise Portierung des kompletten CNM von Sparc-Solaris mit dem kommerziellen CORBA ORB auf Linux-x86 mit einem auszuwählenden frei verfügbaren ORB.
Die 2012 auf Intel x86-Linux portierte CNM-Architektur wurde seit Anfang des Jahres vom DFN und
von den Anwendern pilotiert. Durch kontinuierliche Verbesserungen konnte die Architektur im Juli 2012
vollständig umgeschaltet werden.
6.10.4 Projekte im Rahmen von Géant
Das LRZ ist im GN3-Projekt des europäischen Forschungsnetzverbunds Géant an zwei Tasks der Service
Activity 2 beteiligt, in denen drei Software-Werkzeuge für das länderübergreifende Netzmanagement
erarbeitet werden. Neben der Implementierung von WebCNM umfasst dies das Design des Planungswerkzeugs I-SHARe und die Entwicklung des End-to-End-Link-Monitoringwerkzeugs E2EMon.
6.10.4.1
Géant-Visualisierungswerkzeuge und Performance Monitoring
Das bereits aus dem MWN und X-WiN bekannte CNM wird seit 2004 im europäischen Forschungsumfeld als Visualisierungswerkzeug eingesetzt, im Géant2-Projekt von 2004 bis 2009 und in dessen Nachfolger Géant3 seit 04/2009. Mit der CNM-Anwendung Topologie werden die Topologie und aktuelle
bzw. historische Kennzahlen vom Géant-Kernnetz sowie einigen der 34 angeschlossenen nationalen Forschungsnetze in hierarchischen Netzkarten visualisiert.
Auf Basis des im MWN prototypisch entwickelten WebCNM und der LHCOPN-Wetterkarte, wurde 2011
mit der Entwicklung eines allgemeinen WebCNM-Konzepts begonnen (siehe LRZ-Jahresbericht 2011).
Das Ziel dabei war eine flexible, integrierbare, anpassbare Web-Anwendung, die die vollständige Funktionalität der bisherigen JavaWebStart-Applikation und darüber hinausgehende Features bietet. Das CGIBackend, das auf dem CNM-Server läuft und den Zugriff auf Topologie- und Metrikdaten mit Autorisierung bereitstellt, ist in Perl geschrieben. Das Front-End ist in Java-GWT programmiert und wird mittels
Java GWT-Compiler in eine JavaScript-Webseite übersetzt.
2012 wurden weitere Funktionen hinzugefügt und die Anwendung verbessert. Beispielsweise wurde die
Statistikgraphenfunktionalität entwickelt, das GUI flexibler und generischer gestaltet sowie diverse spezielle Karten und Datenquellen angebunden.
102
Abbildung 55 Darstellung der perfSONAR BUOY OWAMP Daten in WebCNM
Abbildung 55 zeigt perfSONAR BUOY OWAMP Daten, die 2012 in WebCNM angebunden wurden.
Abbildung 56 Management-Interface
Ferner wurde mit der Implementierung des Management-Interfaces (siehe Abbildung 56) begonnen, um
WebCNM per Web-Interface zu konfigurieren. Neu eingebaute graphdateibasierte Karten können online
editiert werden (siehe Abbildung 57). Zusätzlich wurden die interne Hilfe und Tooltips testweise implementiert.
103
Abbildung 57 Editiermöglichkeit der graphdateibasierten Karten
Für weitere Informationen zum Géant-Projekt siehe http://www.geant.net .
6.10.5 Projekte im Rahmen von Geant3
Auch 2012 wurden die beiden GN3-Teilprojekt I-SHARe und E2EMon bearbeitet; die aktuellen Projektergebnisse werden nachfolgend dargelegt.
6.10.5.1
I-SHARe
Beim Betrieb von Netzdiensten, die die Zusammenarbeit mehrerer unabhängiger Provider erfordern, ergeben sich neuartige Herausforderungen, die von etablierten IT Service Management Frameworks nicht
adressiert werden. In GN3 werden diese insbesondere im Zusammenhang mit den Ende-zu-EndeVerbindungen deutlich, bei denen es sich um dedizierte optische Multi-Gigabit Verbindungen - i.A. jeweils über mehrere heterogene optische Netze - handelt. Die Arbeitsabläufe für die Einrichtung und den
Betrieb dieser Verbindungen erfordern ein koordiniertes Vorgehen der beteiligten nationalen Wissenschaftsnetze.
Das Ziel der GN-Aktivität I-SHARe ist die Tool-Unterstützung der Multi-Domain-Betriebsprozesse, die
alle Phasen des Lebenszyklus von E2E Links abdecken. Der Fokus liegt dabei auf dem erforderlichen
Informationsaustausch, der von der Planung einer neuen E2E Link Instanz über deren Betrieb bis hin zu
ihrer Abbestellung notwendig ist. Die Aktivität wurde Mitte 2007 mit einer umfangreichen, fundierten
Anforderungsanalyse gestartet. Details dazu können im Jahresbericht 2008 nachgelesen werden. Ergebnis
dieser Analyse war die Spezifikation und Entwicklung eines Prototyps, der Anfang 2009 im Rahmen
eines Piloteinsatzes durch das Betriebspersonal evaluiert wurde. Die Anmerkungen und Wünsche wurden
vom I-SHARe-Team erfasst und bildeten die Grundlage für eine Anpassung der Anforderungen. Mitte bis
Ende 2009 floss die mit dem Prototyp gesammelte Erfahrung in die Erstellung einer Spezifikation für die
Entwicklung einer ersten produktiven Version des I-SHARe Tools ein. Diese Entwicklung wurde Mitte
2010 abgeschlossen, woraufhin eine fundierte und detaillierte Qualitätssicherungsphase folgte, die auf
Basis der Spezifikation durchgeführt wurde. Nach erfolgreichem Test konnte das Release für die Pilotphase freigegeben werden. Während der letzten Vorbereitungen für die Pilotphase wurde I-SHARe
allen beteiligten und interessierten Partnern auf der TERENA-Konferenz vorgestellt. Die Pilotphase wurde dann mit einer Benutzerschulung eingeleitet, die federführend vom LRZ vorbereitet und durchgeführt
wurde. I-SHARe wird derzeit von mehreren NRENs für die Planung neuer End-to-End Links genutzt
(siehe Abbildung 58).
104
Abbildung 58 I-SHARe
Das ISHARe-Team am LRZ bereitet derzeit die Integration der Anwendung in ein standardisiertes Netzmanagement-Framework vor, wie es die GEANT Network Management Architecture (NMA) vorsieht.
Dazu wurden die in I-SHARe implementierten Prozesse 2012 als eTOM-konformes GeschäftsprozessModell abgebildet und somit die Voraussetzung für die Zusammenführung mit verwandten Netzwerkmanagement-Anwendungen geschaffen.
6.10.5.2
E2E-Link und Dynamisches Circuit-Monitoring mit CMon
Neben klassischen IP-Verbindungen können im Rahmen des Géant-Verbundes auch End-to-End (E2E)
Links statisch sowie dynamisch eingerichtet werden. Das LRZ arbeitet seit Jahren aktiv in Projektteilen
mit, die Konzepte, Verfahren und Tools zum Management dieser Ende-zu-Ende Links bereitzustellen. Ein
wesentlicher Bestandteil dieses Projekts ist das E2E Link Monitoring System (E2Emon), das unter Federführung des LRZ konzipiert und entwickelt wurde. Nach jahrelang erfolgreichem Betrieb des E2EmonSystems im Projekt werden nun neue Anforderungen aufgenommen und das System wird in einer neuen
Projektphase unter der Projektname CMon (Circuit Monitoring) weiter entwickelt.
Das CMon-System soll dazu in der Lage sein, nicht nur statisch eingerichtete Links, sondern auch dynamisch angelegte Verbindungen zu überwachen. Verglichen mit statischen Links haben die dynamisch
eingerichteten Links i.A. kürzere Lebensdauer und sind mit häufigen Veränderungen verbunden. Deshalb
ist es notwendig, für das zukünftige CMon-System diese Dynamik eines Links bei Monitoring zu berücksichtigen. Da das Einrichten dynamischer Verbindungen in Géant durch AutoBAHN (Automated Bandwidth Allocation across Heterogeneous Networks) realisiert wird, ist eine Kooperation auf Systemebene
zwischen CMon und AutoBAHN vorgesehen.
105
Abbildung 59 Hauptanwendungsfall des CMon-Systems als UML Use Case
Abbildung 59 zeigt den primären Use Case von CMon. Design und Entwicklung des Systems werden in
einer Kooperation zwischen LRZ und NORDUNET durchgeführt, wobei das LRZ die federführende Rolle übernimmt. Ein Prototyp ist in der Endphase der Entwicklung und wird bereits für Tests eingesetzt.
Das betriebsbereite System wird in der nachfolgenden Projektphase Géant 3+ entwickelt werden und
letztendlich das bisjetzige E2Emon ablösen.
Netzdienste für Endanwender
106
7 Netzdienste für Endanwender
Für die Endanwender (Studenten und Mitarbeiter der verschiedenen Institutionen) steht der Zugang zum
MWN und damit zum Internet im Vordergrund. Die Netzdienste richten sich nach diesen Anforderungen
aus. Im Jahr 2012 hat die Zahl der Endanwender weiter zugenommen. Insbesondere die mobile Nutzung
von Netzdiensten zeichnete sich durch exteme Wachstumsraten aus. Dies wirkt sich insbesondere auf
WLAN und Eduroam aus (vgl. Kap. 7.2). Um einen sicheren Zugang ins MWN über unsichere Netze zu
ermöglichen, betreibt das LRZ VPN-Dienste die im Kap. 7.3 beschrieben werden.
7.1
Internetzugang und LAN
Der Zugang zum weltweiten Internet wird über das Deutsche Wissenschaftsnetz (WiN) realisiert. Im Jahr
2012 war das MWN technisch mit einem Trunk aus zwei 10 Gbit/s-Schnittstellen am WiN angeschlossen.
Dieser Zugang wird vom DFN auf eine Bandbreite von 11 Gbit/s (zweimal 5,5 Gbit/s) beschränkt. Derzeit ist ein zweistufiges Ausfallkonzept mit Backups für den Internetzugang umgesetzt (s.u).
Die monatliche Nutzung (übertragene Datenmenge) des WiN-Anschlusses seit Januar 2000 zeigt Abbildung 60. Die Datenmenge pro Monat nähert sich einem Petabyte.
Abbildung 60 Entwicklung der Nutzung des WiN-Anschlusses des Münchner Wissenschaftsnetzes
Die Steigerungsraten - bezogen auf die jeweils im Vorjahr transportierte Datenmenge - sind in Abbildung
61 graphisch dargestellt. Seit dem Jahr 2000 hat die Datenmenge auf die 100-fache Menge zugenommen
107
Abbildung 61 Steigerungsraten beim übertragenen Datenvolumen
Seit September 2003 ist der X-WiN-Anschluss vertragstechnisch ein so genannter Clusteranschluss, bei
dem die vom MWN versorgten teilnehmenden Institutionen als eigenständige Partner mit eigenem Tarif
bezogen auf den eingehenden Datenverkehr aufgefasst werden. Zu diesem Zweck wurden die laufenden
Messungen kumuliert, um eine Verteilung des Datenverkehrs zu bekommen. Die prozentuale Verteilung
des Datenvolumens am WiN-Zugang (Messzeitraum Dezember 2012) zeigt Tabelle 12:
Institution
LRZ und BAdW
TUM
LMU
Hochschule München
Sonstige
Total Bytes %
75,6%
6,3%
5,6%
0,9%
11,4%
Hochschule Weihenstephan
0,1%
Gate
0,1%
Tabelle 12: Prozentuale Verteilung des Datenverkehrs am WiN-Zugang
Die prozentuale Verteilung des gesamten Verkehrs gegenüber den Werten des Vorjahres hat beim LRZ
um 5% zugenommen abgenommen. In etwa im gleichen Verhältnis hat der Verkehr bei LMU und TUM
abgenommen.
Die technische Realisierung der Anbindung des MWN an das Internet zeigt Abbildung 62.
Der Standardzugang zum Internet ist über das vom DFN betriebene Wissenschaftsnetz (WiN) realisiert.
Der WiN-Anschluss des LRZ erfolgt über das IPP (Max-Planck-Institut für Plasmaphysik) in Garching
mit einer Anschlußbanbreite von 11 Gbit/s. Dort wurde vom DFN der zugehörige WiN-Kernnetz-Router
installiert. Im Jahr 2011 wurde die beiden Glasfasern zum X-WiN Router zu einem Trunk zusammengefasst. Damit ließ sich eine höhere Bandbreite (2 x 5,5 Gbit/s) realisieren. Derzeit ist ein zweistufiges
Ausfallkonzept für den Internetzugang umgesetzt.
1. Falls eine Glasfaser zwischen dem LRZ-Router und IPP oder eines der entsprechenden Interfaces
an den beiden Routern ausfallen sollte, funktioniert der Trunk zwischen Maschinenwesen und
IPP weiterhin, allerdings nur mit halber Bandbreite.
108
Abbildung 62 Anbindung des MWN ans Internet
2. Sollten beide Leitungen oder aber der Kernnetzrouter des DFN oder der Router des LRZ in Garching ausfallen, wird ohne merkliche Unterbrechungen für den Benutzer auf eine über M-net realisierte Backup-Verbindung umgeschaltet. Die Backup-Verbindung zum Internet wird über eine
LWL-Strecke mit 1 Gbit/s zum nächsten Anschlusspunkt von M-net geführt. Die LWL-Strecke
kostet einen monatlichen Grundbetrag, das Datenvolumen wird nach Verbrauch berechnet.
Die Backup-Konzepte funktionieren für alle Systeme mit Provider-unabhängigen IP-Adressen (Standardfall im MWN). Das LRZ-Netz kann nämlich mit einem Großteil seiner IP-Adressen als autonomes System im Internet agieren. Einige Standorte (Rechts der Isar, Hochschule München, Beschleunigerlabor,
Zoologische Staaatsammlung, kath. Stiftungsfachhochschule) bzw. Systeme (Bibliotheksverbund Bayern), die aus historischen Gründen noch providerabhängig IP-Adressen (i.d.R. vom DFN vergeben) verwenden, können die Backup-Strecken nicht nutzen.
Im Jahr 2012 wurde die Backup-Strecke in 12 Fällen aktiv. In der Regel handelte es sich dabei um sehr
kleine Störungen (z.B. im Routing oder bei IPv6) und der Backup war nur für wenige Minuten aktiv. Am
11.11.2012 und am 29.11.11 kam es Probleme mit dem DFN-Router im X-WiN. Bei diesen Vorfällen,
wäre es ohne den Backup zu einer Unterbrechung der Internet-Konnektivität gekommen.
7.2
WLAN und Eduroam
Das LRZ versorgt primär öffentliche Bereiche (Seminarräume, Hörsäle, Bibliotheken, Foyers, UniLounges) mit Wireless LAN, eine Flächendeckung für Bürobereiche kann bis auf weiteres nicht realisiert
werden. Trotzdem sind Ende 2012 bereits 2.053 Accesspoints in Betrieb. Im Berichtsjahr 2012 wurden
mit 312 noch mehr Accesspoints als 2011 installiert.
350
300
250
200
150
100
50
0
2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012
Abbildung 63 Anzahl der jährlich installierten Accesspoints
109
Die Nutzung stieg rasant an, insbesondere bedingt durch die stark zunehmende Anzahl von Smartphones
und Tablets. Die im letzten Jahr gemessene Zahl von 7.064 gleichzeitigen Verbindungen stieg 2012 auf
maximal 11.732 an, insgesamt wurden dabei über 300.000 verschiedene Geräte beobachtet. Sehr nachgefragt wurde das WLAN auch bei 348 Kongressen und Tagungen innerhalb des Jahres 2012.
Abbildung 64 Anzahl aktiver WLAN-Verbindungen am 27.11.2012 (5-Minuten-Mittel)
Abbildung 65 Entwicklung der Belegung über das Jahr 2012 (Tagesmittel)
In den Bildern zeigt der blaue bzw. dunklere Bereich den Anteil von Verbindungen mit IEEE 802.11g
(54 Mbit/s).
Die am stärksten frequentierten Accesspoints waren mit bis zu 234 gleichzeitigen Verbindungen belegt.
Ältere hoch belastete Accesspoints wurden durch die aktuellste Geräte-Generation ersetzt.
Als Zugangskomponenten werden Accesspoints der Typen MSM310, MSM320, MSM422, MSM460 und
MSM466 der Firma HP eingesetzt. Bei den ab 2011 eingesetzten MSM460 und MSM466 werden Datenraten bis zu 450 Mbit/s (IEEE802.11n) unterstützt. Bei geschickter Wahl der Frequenzen und Verzicht
auf die Unterstützung des veralteten Standards 802.11b kann diese Übertragungsgeschwindigkeit auch im
2,4 GHz-Band erreicht werden. Aus diesem Grund wurde 802.11b auf allen Accesspoints abgeschaltet.
Durch den Anstieg der Benutzerzahlen wurden die Adressen für die verschiedenen SSIDs an manchen
Router-Standorten knapp. Bei einer einfachen Vergrößerung des Adressbereichs wären dabei die
Broadcast-Domains so groß geworden, dass die Teilnetze keinen guten Durchsatz mehr geboten hätten.
Deshalb wurde bereits 2011 damit begonnen, für jede SSID/Router mehrere Teilnetze einzurichten. Wegen der Roaming-Problematik (gleiche SSID über unterschiedliche Accesspoints) kann die NetzZuordnung dabei nicht automatisch erfolgen, durch den hohen Konfigurationsaufwand wird die Umstellung erst im Laufe des Jahres 2013 abgeschlossen werden.
110
Im Laufe des Jahre 2012 wurden folgende Bereiche neu mit WLAN ausgestattet:
Hochschule Weihenstephan-Triesdorf, 3 neue Gebäude
HM Dachauer Str. 100b, Bau T
LMU Garching, Laserhalle
LMU Leopoldstraße 13a, Mensa
Musikhochschule, Wilhelmstr. 19
Studentenstadt Freimann, Christoph-Probst-Str. 10
TUM Arcisstr. 19
TUM Augustenstr. 44
TUM Gabelsberger Str. 43
TUM Garching Hochschulreferat 6, Geb. 5203
TUM Garching Physikdepartment Containerbau
TUM Ingolstadt, Marie-Curie-Str. 8
TUM Nordgelände N6, Bauingenieur und Vermessungswesen
TUM Stammgelände Elektrische Antriebssysteme
TUM Stammgelände Elektrotechnik und Informationstechnik
TUM Stammgelände Gebäude 0505
TUM Stammgelände Holzbau
TUM Stammgelände Informatik 6
TUM Stammgelände Ingenieurgeologie
TUM Stammgelände IT-Service-Zentrum
TUM Stammgelände Zentrale Verwaltung
TUM Weihenstephan Alte Akademie, Geb. 4108
TUM Weihenstephan Gebäude 4309
TUM Weihenstephan Verwaltung, Geb. 4321
TUM ZHS Ausweichquartier Campus C
Die nachfolgenden Bereiche sind weggefallen bzw. werden nicht mehr vom LRZ betreut:
Hochschule für Fernsehen und Film (Altbau)
Pinakotheken Freifläche Nord
TUM Nymphenburger Str. 39
TUM Versuchsgut Grünschwaige
TUM Weihenstephan Altes Molkereigebäude
7.2.1 WLAN-Ausbau im Gebäude der Fakultät Maschinenwesen
Die Studienbeitragskommission der Fakultät Maschinenwesen der TU München hat knapp 70.000 Euro
für die Verbesserung der WLAN-Versorgung bereitgestellt. Gemeinsam mit dem LRZ wurde ein entsprechendes Konzept erarbeitet und in sehr kurzer Zeit auch umgesetzt.
Da die Zahl der Studierenden und der mobilen Geräte stark gestiegen ist, reichte sowohl die Bandbreite
der bestehenden WLAN-Accesspoints als auch die Zahl der gleichzeitig unterstützten Nutzer pro Accesspoint im Gebäude der Fakultät Maschinenwesen in Garching nicht mehr aus. In einem ersten Schritt
wurden deshalb in allen öffentlichen Bereichen die bestehenden Accesspoints durch neueste Modelle mit
einer Bandbreite von bis zu 450 Mbit/s ersetzt. In den Hörsälen, in denen die Anzahl gleichzeitiger Nutzer naturgemäß noch höher ist, wurden zusätzliche Accesspoints zur Verstärkung installiert. Insgesamt
wurden im Rahmen dieser Maßnahme 67 Accesspoints verbaut.
111
Damit sich alle Nutzer mit ihren Geräten auch weiterhin anmelden können und ihr Gerät eine Adresse
zugewiesen bekommt, mussten außerdem zusätzliche Netze zur Verfügung gestellt werden. Da die Switches in den Gebäudehauptverteilern nur eine begrenzte Anzahl verschiedener Netze unterstützen, wurden
in den acht Gebäudehauptverteilern die Zentralswitches erneuert.
Aus Brandschutzgründen dürfen in der Magistrale des Maschinenwesens keine zusätzlichen Accesspoints
installiert werden, daher ist die Versorgung dort noch nicht optimal. Das LRZ hat jedoch, in enger Abstimmung mit dem zuständigen Bauamt, eine Lösung erarbeitet, die nur passive Antennen im Fluchtwegbereich vorsieht. Wegen aufwändiger Leitungsinstallationen ist die Umsetzung aber erst 2013 möglich.
Der Zeitplan für das Projekt war sehr ambitioniert. Die Mittel wurden Mitte Februar bewilligt, die Arbeiten konnten komplett in der vorlesungsfreien Zeit bis zum 15. April abgewickelt werden. Dies war auch
nur deshalb möglich, weil neben den verantwortlichen Mitarbeitern drei Auszubildende maßgeblich für
das Projekt gearbeitet haben. Einer von ihnen entwickelte auch seine praktische Abschlussarbeit aus dem
Projekt.
7.2.2 WLAN-Auswahl
Zur Überprüfung der für das MWN optimalen WLAN-Lösung wurde von Juni bis Oktober 2012 eine
ausführliche Auswahl von in Frage kommenden Produkten durchgeführt.
Nach einer Marktuntersuchung wurde 15 Herstellern eine 50 Fragen umfassende Anforderungsliste zugesandt, welche von 11 Firmen beantwortet wurde. Die essentiellen Kernanforderungen konnten nur von
Aruba, Cisco und Hewlett Packard erfüllt werden. Von August bis Oktober wurden die Lösungen von
Aruba und Cisco durch Testinstallationen ausführlich geprüft, die Lösung von HP war durch den produktiven Einsatz bereits bekannt.
Aufgrund der vorgelegten Angebote und der Testergebnisse wurde entschieden, dass für den künftigen
Ausbau des WLANs im MWN die Lösung von Aruba eingesetzt werden soll. Nur Aruba bietet beim Einsatz von Controllern die notwendige Flexibilität, eine Weiterführung bzw. sanfte Migration der eingeführten Prozesse beim Betrieb des WLANs im MWN zu ermöglichen.
7.2.3 Eduroam
Das LRZ nimmt seit Anfang 2005 am Eduroam (früher DFN-Roaming) teil. Damit ist es 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 fast allen Accesspoints im MWN zur Verfügung gestellt. Nur an zwei Standorten mit je einem Accesspoint, die über DSL-Leitungen angeschlossen sind, ist es aus technischen Gründen nicht möglich, Eduroam anzubieten.
Die frühere SSID 802.1X wurde 2012 abgeschaltet.
Da einige Clients Probleme haben, wenn eine SSID sowohl im 2.4GHz-Band als auch im 5GHz-Band
angeboten wird und dann ständig zwischen beiden Bändern wechseln, wurde eine spezielle SSID eduroam-a eingeführt, die dann von solchen Clients verwendet werden kann.
Abbildung 66 Benutzungs-Statistik für die SSID eduroam
112
Da die SSID eduroam als Standard-SSID für die Nutzung im MWN angeboten wird, sind die BenutzerZahlen sehr stark gestiegen. Aus diesem Grund wurde noch im Jahre 2012 mit der Implementierung der
SSID eduroam-IPv6only begonnen. Verbindungen zu dieser SSID bekommen keine offizielle IPv4Adresse mehr, sondern arbeiten nur mit IPv6.
7.2.4 Unterstützung von Veranstaltungen
Das LRZ richtet für Veranstaltungen im Münchner Wissenschaftsnetz (MWN) bei Bedarf ein spezielles
Netz ein, welches die Tagungsteilnehmer ohne besondere Authentifizierung nutzen können. Hierbei wird
davon ausgegangen, dass die Nutzer dieses Netzes nicht immer aus dem Wissenschaftbereich stammen,
sondern auch Mitarbeiter von Firmen und anderer Organisationen Netzdienste ohne spezielle Vorkehrungen (ohne VPN-Client-Installation, ohne Validierung) nutzen wollen. Eine Anmeldung und die bei frei
zugänglichen Netzanschlüssen ansonsten obligatorische Verwendung eines VPN-Zugangs werden hier
nicht gefordert.
Diese "offene" Konfiguration bleibt auf den Zeitraum und den Ort der Veranstaltung begrenzt. Der Zugang ist drahtlos (WLAN nach IEEE 802.11a/g/n) möglich. Nur in Ausnahmefällen werden feste Netzanschlussdosen (100 Mbit/s oder 1 Gbit/s LAN) zur Verfügung gestellt. Für Geräte, die keine eingebaute
Funkschnittstelle haben, werden vom LRZ Wireless-Client-Bridges (WCB) bereitgestellt. Die 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.
Der Netzname (SSID) ist dabei con. Es wird keine Verschlüsselung verwendet, um Probleme mit der
Weitergabe und Einstellung der Schlüssel zu vermeiden. Für länger dauernde Kurse oder auf Wunsch des
Veranstalters werden aber auch verschlüsselte Netze eingerichtet. Mitarbeiter von wissenschaftlichen
Einrichtungen, die am Eduroam teilnehmen, kommen mit diesem Netz aber nicht in Berührung, da sich
deren Geräte automatisch mit der SSID eduroam verbinden.
2012 wurden 348 Veranstaltungen (+44 gegenüber dem Vorjahr) unterstützt.
Auch im Jahr 2012 wurden für die Unterstützung der Konferenzen teilweise schon vorhandene Accesspoints gegen neuere ausgetauscht, um den erhöhten Bedarf abdecken zu können. Damit können Konferenz-Teilnehmer mit neueren Laptops Transfer-Raten bis zu 450Mbit/s erreichen und geben dadurch den
Funkkanal schneller wieder für andere Teilnehmer frei.
Außerdem wurden öfters Accesspoints anlässlich einer Veranstaltung neu aufgebaut, die ansonsten erst zu
einem späteren Zeitpunkt eingerichtet worden wären.
Eine Verteilung der Konferenzen auf die einzelnen Monate zeigt die folgende Statistik. Erwartungsgemäß
werden die Hörsäle vor allem in vorlesungsfreien Zeiten für Konferenzen genutzt.
Abbildung 67 WLAN-Freischaltungen für Veranstaltungen 2012
Betrachtet man die Anzahl der freigeschalteten Accesspoints multipliziert mit der Anzahl der Tage (APTage), dann ergibt sich die folgende Verteilung auf die einzelnen Institutionen:
113
TUM
LMU
HM
BadW
LRZ
Sonstige
Gesamt
1.221
651
384
52
212
70
2.590
7.3
VPN
Im MWN werden Virtual-Private-Networks in folgenden Szenarien eingesetzt:




Zugang über vom LRZ betreute WLANs.
Zugang über öffentliche Anschlussdosen für mobile Rechner.
Zugang zu internen MWN-Diensten (z.B. Online-Zeitschriftenangebot der Universitätsbibliotheken)
für Bewohner von Studentenwohnheimen.
Zugang zu internen MWN-Diensten über das Internet.
7.3.1 Technik
Die VPN-Hardware besteht aus zwei Appliances vom Typ „Adaptive Security Appliance ASA5585-X“,
vier Appliances vom Typ „Adaptive Security Appliance ASA5540“ und einer Appliance vom Typ „VPNConcentrator 3030“ der Firma Cisco. Der VPN-Concentrator 3030 dient für die Anbindung von einigen
externen Einrichtungen außerhalb des MWN über IPsec LAN-to-LAN Tunnel. Die vier der sechs ASAAppliances 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-VPNClients unter der Adresse asa-cluster.lrz.de angesprochen. Die Nutzer werden beim Anmelden mit der am
geringsten ausgelasteten Appliance verbunden. Der VPN-Concentrator 3030 ist über zwei 100 MBit/s
Anschlüsse (öffentlich und privat) angeschlossen. Die zwei ASA5585-X sind mit jeweils 10GBits/s angeschlossen, die vier ASA5540 mit jeweils 1GBit/s. Die verfügbare Bandbreite für verschlüsselte Verbindungen (AES/3DES) beträgt 50MBit/s beim VPN-Concentrator 3030 350MBit/s pro ASA5540 und
1GBit/s bei den ASA5585-X. Authentifizierung, Autorisierung der Nutzer sowie Accounting werden über
das RADIUS-Protokoll abgehandelt.
7.3.2 VPN-Software
Berechtigte Nutzer können die aktuellen Versionen der VPN-Software vom Web- oder VPN-Server des
LRZ herunterladen. Für Linux und Mac OS X stehen neben den Cisco-IPsec und AnyConnect-Client der
„Open Source“ VPN-Client vpnc (IPsec) und openconnect (SSL-VPN) zur Verfügung, der erfahrenen
Nutzern erweiterte Möglichkeiten bietet. Diese Clients sind inzwischen in den Standarddistributionen wie
z.B. Debian, SuSE und Ubuntu enthalten.
7.3.3 Telearbeitsplätze von LRZ-Mitarbeitern
Mitarbeiter, die Telearbeit machen, nutzen die internen Ressourcen des LRZ während ihrer Arbeit zu
Hause. Dazu erhalten sie einen VPN-Router, an den sie Rechner und VoIP-Telefon anschließen können.
Der VPN-Router ist so konfiguriert, dass er automatisch eine Verbindung zum VPN-Server im LRZ 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.
7.3.4 Entwicklung des Datenverkehrs über die VPN-Server
Im Mittel stieg der Durchsatz im Vergleich zum Vorjahr um 33%. In Spitzenzeiten waren bis zu 5.500
Nutzer parallel angemeldet. Im Monat November, dem Monat mit dem höchsten Datenaufkommen wur-
114
den 700.000 Verbindungen aufgebaut. Der im Jahr 2009 eingeführte SSL-VPN Client (Cisco
AnyConnect) hat inwischen einen Anteil von 75% aller Verbindungen erreicht.
Jahr
Ausgehend
Eingehend
Gesamt
2005
0,7
3,2
3,9
2006
1,7
6,2
7,9
2007
3,1
11,4
14,5
2008
3,8
12,7
16,5
2009
4,6
20,7
25,3
2010
8,0
28,8
36,7
2011
11,4
44,9
56,3
2012
12,0
51,6
63,6
Tabelle 13: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November
70
60
50
40
Ausgehend
Eingehend
Gesamt
30
20
10
0
2005 2006 2007 2008 2009 2010 2011 2012
Abbildung 68 Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November
115
6000
5000
4000
3000
2000
1000
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 69 Anzahl der gleichzeitig an den VPN-Servern angemeldeten Nutzer
70.000
Eingehend
60.000
Ausgehend
Summe
50.000
40.000
30.000
20.000
10.000
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 70 VPN-Datenverkehr pro Monat
7.4
Modem / ISDN
Die Anzahl der Wählverbindungen hat sich im Laufe des Jahres 2012 weiter verringert. Die Anzahl der
Telekom-Kunden ging auf ca. 20 (2011: 40), die der M-net-Kunden auf ca. 25 (2011: 35) zurück.
Da für den Dienst so gut wie keine Arbeit anfällt, wird er trotz der geringen Nutzung weiter zur Verfügung gestellt. Unterstützung bei Problemen wird aber keine mehr angeboten.
Das folgende Diagramm zeigt für das 2. Halbjahr 2012 die maximale Anzahl gleichzeitig aktiver Verbindungen pro Woche, aufgeschlüsselt nach den jeweiligen Rufnummern.
116
Abbildung 71 Maximale Anzahl von Verbindungen pro Rufnummer
Abbildung 72 Verteilung der Modem/ISDN-Verbindungen im Wochenverlauf
117
8 Virtual Reality und Visualisierung
Im Januar 2012 wurde mit den Baumaßnahmen zum Innenausbau und der Medientechnik des Zentrums
für Virtuelle Realität und Visualisierung (V2C) begonnen. Das Gerüst für die 5-seitige Projektionsinstallation und der Zwischenboden wurden zuerst eingebracht. Somit konnte parallel in dem nun entstandenen
Untergeschoss und Obergeschoss gearbeitet werden. Der Innenausbau konnte im Mai fertiggestellt werden und die Installation frühzeitig am 20.07. geladenen Gästen demonstriert werden.
Abbildung 73 Das V2C mit seinen einzelnen Komponenten
Am 25. Oktober fand die feierliche Einweihung des V2C statt. Hierüber berichteten die Süddeutsche
(27.10.2012) und das Linux Magazin (26.10.2012). Deutschlandradio Kultur strahlte in der Sendereihe
Elektronische Welten am 10.12.2012 einen Bericht zum V2C aus.
8.1
Sichtbarkeit und Öffentlichkeitsarbeit
Es wurde ein geladener Vortrag mit dem Thema „Developing Immersive Games with the inVRs Framework“ an der FH Hagenberg in Österreich sowie ein Vortrag mit dem Titel „Virtual Reality and Visualisation at the Leibniz Supercomputing Centre“ an der Ho Chi Minh City University of Technology in Vietnam gehalten.
Das V2C beteiligte sich an zwei größeren Veranstaltungen, der Feier zum 50-jährigen Bestehen des LRZ
und dem Tag der offenen Tür mit Führungen. Im Rahmen dieser beiden Veranstaltungen bekamen ca. 400
Gäste einen ersten Eindruck des Zentrums für virtuelle Realität und Visualisierung. Insgesamt fanden in
der zweiten Jahreshälfte 27 Führungstermine statt, an denen ca. 800 Besucher das V2C besichtigten.
Es wurde eine hochwertige Broschüre von 24 Seiten erstellt (Auflage 1.000 Stück), welche den Hintergrund, die Technologien und die ersten erfolgreichen Projekte vorstellt.
Virtual Reality und Visualisierung
118
Die Onlinepräsenz des VR und Visualisierungsteams (V2T) wurde konstant mit Informationen zum Zentrum aktualisiert und hat während der Bauphase mit dem Produktionstagebuch einen Überblick über den
aktuellen Bauzustand gegeben.
8.2
Kooperationen
Mit interessierten Instituten der LMU und TUM wurde der Kontakt hergestellt und die ersten Projekte
konnten erfolgreich realisiert werden. Hierzu zählt beispielsweise die Darstellung und Rekonstruktion der
Grabkammer von Karaburun in Zusammenarbeit mit dem Institut für Klassische Archäologie der LMU,
oder die Zusammenarbeit mit dem Institut für Fördertechnik Materialfluss und Logistik, TUM, wo virtuelle Kranmodelle mit realer Steuerung kontrolliert werden. Weitere Projekte stammen aus den Bereichen
der Architekturinformatik, Kunstpädagogik, Informationsvisualisierung und der Geoingenieurswissenschaften.
Bei der Umsetzung eines weiteren Projekts der Klassischen Archäologie, welches bei der Analyse und
beim Vergleich Antiker Statuten unterstützt, wurde erstmals auf internationaler Ebene mit der University
of Tokyo und der Tohoku University in Japan sowie der University of California in Berkeley, USA, zusammengearbeitet. Viele weitere Projekte und Forschungsanträge befinden sich in der Planungs- und
Umsetzungsphase.
Insgesamt wurden 2012 Kooperationsgespräche mit über 20 Instituten der Münchner Universitäten geführt.
Abbildung 74 Die Rekonstruktion der Grabkammer von Karaburun auf der Powerwall (links) und in der
5-seitigen Projektionsinstallation (rechts)
8.3
Forschung und Lehre
Im Bereich Virtuelle Realität und Visualisierung wurde in Zusammenarbeit mit der LMU ein Masterarbeitsthema erfolgreich bearbeitet. Eine Bachelorarbeit wurde abgeschlossen und zwei weitere begonnen,
welche voraussichtlich 2013 abgeschlossen werden. In Zusammenarbeit mit der Johannes Kepler Universität Linz in Österreich wurde ein Praktikumsthema bearbeitet. Eine Lehrveranstaltung „Virtual Reality“
wurde im Sommersemester an der LMU abgehalten.
119
Im Bereich der Forschung wurde in Zusammenarbeit mit dem Institut für Architekturinformatik der TUM
eine Publikation bei der 12th International Conference on Construction Applications of Virtual Reality
(CONVER’12) im November in Taipeh präsentiert.
Des Weiteren hat sich das LRZ bei der Einreichung eines Europäischen Forschungsprojekts beteiligt.
Dieses Projekt trägt den Titel Mr.SymBioMath und wurde positiv begutachtet. Der Projektstart ist für
Februar 2013 geplant. Die allgemeine Aufgabenstellung des Projekts ist die Analyse von Gendaten, wobei sich das V2C hierbei mit der Visualisierung der Datensätze beschäftigt.
Im Rahmen des Arbeitskreises Visualisierung, einer wissenschaftlichen Vortragsreihe rund um das Feld
Virtuelle Realität und Visualisierung, fanden vier Veranstaltungen statt, in welchen internationale Gäste
aus Österreich, Großbritannien und Japan von ihren aktuellen Forschungsergebnissen aus den Bereichen
VR und Visualisierung berichteten.
IT-Service-Management
120
9 IT-Service-Management
9.1
IT-Service-Management: Einführung von ISO/IEC 20000
Die Zuverlässigkeit und Verfügbarkeit von IT-Services ist in erheblichem Maß von der effektiven 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 ITService-Providers kontrollieren und lenken. Die Ausgestaltung eines solchen, prozessorientierten ITService-Managements (ITSM) ist Gegenstand verschiedener so genannter ITSM-Rahmenwerke wie der
IT Infrastructure Library (ITIL) oder des internationalen Standards ISO/IEC 20000. Das LRZ ist bemüht,
ein Managementsystem nach ISO/IEC 20000 zu etablieren.
9.1.1 Incident-Management
Für das im Vorjahr eingeführte Incident Management nach ISO/IEC 20000 lag der Fokus für das Jahr
2012 in der Etablierung eines kontinuierlichen Verbesserungsprozesses. Die mittlerweile durchschnittlich
700 erfassten Incidents pro Monat werden nun nicht mehr nur hinsichtlich der Zeit bis zur Lösung sondern auch in Bezug auf die Erstreaktionszeit überwacht. Zusätzlich werden weitere Kennzahlen erfasst
und es kann mit Hilfe eines neu eingeführten standardisierten Berichtes nachgewiesen werden, dass sich
die Einhaltung der Ziele für die Lösung von Incidents im Vergleich zum Vorjahr signifikant verbessert
hat.
Im gesamten Jahr 2012 wurden 8.605 Incidents (Falschmeldungen und Major Incidents nicht mitgerechnet) erfasst. Im Schnitt waren es also über 700 Incidents pro Monat, siehe Abbildung 75 (Zum Vergleich:
2011 wurden durchschnittlich etwas mehr als 500 Incidents pro Monat erfasst.). Diese Steigerung des
Incident Aufkommens bedeutet nicht, dass sich die Servicequalität des LRZ verschlechtert hat. Die Steigerung hängt damit zusammen, dass durch einen einheitlichen Incident Management Prozess nun viele
Incidents überhaupt erst erfasst werden und nicht am Prozess vorbei laufen. Dies wiederum gestattet eine
wesentlich bessere Analyse der aufgetretenen Störungen und macht eine Verbesserung der Servicequalität
wesentlich einfacher.
Abbildung 75 Verteilung des Incidentaufkommens über die Monate 2012
121
Abbildung 76 Verteilung der Incident-Prioritäten
Ein weiterer Schritt zur Verbesserung der Servicequalität des LRZ wurde mit einer verstärkten Einbindung des Servicedesks in den Incident Management Prozess erreicht. Gezielte Schulungen sowohl im
Prozess wie auch im Tool selbst hatten zur Folge, dass die Incidents durch das Servicedesk besser bewertet und auch umfassend koordiniert werden können. Die Mitarbeiter des LRZ selbst konnten dadurch
entlastet werden und sich verstärkt ihren Kernaufgaben widmen. Abbildung 76 zeigt hierbei die Verteilung der Priorität der Incidents. Dadurch, dass die Priorität der Incidents bereits von dem Servicedesk
korrekt bestimmt werden kann, ist es den Mitarbeitern möglich, ihre Zeit besser einzuteilen und nicht bei
jedem Eintreffen eines Incidents sofort ihre Arbeit unterbrechen zu müssen.
9.1.2 Weitere ITSM-Prozesse
Ein Großteil der Personalkapazitäten wurden 2012 für die Einführung eines Configuration Managements
und für die Vereinheitlichung des Change Managements beansprucht. Diese beiden Prozesse wurden
forciert vorangetrieben, so dass diese nun kurz vor dem „Go-Live“ stehen.
Kernaufgabe hierbei ist zum einen die Einführung einer zentralen CMDB. Da die Integration bestehender
Informationssysteme sich aufwändiger erwies als erwartet, musste ein wesentlicher Aufwand hierfür investiert werden. Aber auch im Change Management mussten große Anstrengungen unternommen werden,
um das Tool iET-ITSM anzupassen und für die Anforderungen der existierenden Verfahren am LRZ vorzubereiten.
Weitere Aktivitäten, welche die Bemühungen im Bereich IT Service Management seit Ende 2009 ergänzen, finden im Informationsmanagement statt. Hier wurde ein Arbeitskreis gebildet, welcher sich zur
Aufgabe gemacht hat, das Management der Informationen - im Speziellen der Dokumentationen - im
LRZ zu verbessern. Abteilungs- und Tool-übergreifende Strukturen sollen eingeführt werden, so dass
eine einheitliche und übersichtliche Informationslandschaft entstehen kann. Hierfür wurde 2012 der
„Dienstleistungsbaum“, welcher als zentrale Struktur für die Informationslandschaft dient und einen gesteigerten Wiedererkennungswert für die Kunden des LRZ bietet, kontinuierlich verbessert und auf zentrale Informationsquellen angewendet. Ein weiterer Meilenstein in Richtung „Abteilungsübergreifende
Strukturen“ wurde mit der Einführung eines zentralen Wiki-Systems erreicht. Eine Vielzahl an bisherigen
Wikis, die nur innerhalb einzelner Gruppen oder Abteilungen verwendet wurden, konnten durch ein zentral verwaltetes „LRZ-Wiki“ abgelöst werden.
9.1.3 Sonstige Aktivitäten
Parallel zu den Einführungsprojekten wird am LRZ auch weiterhin das Zertifizierungs- und 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.
IT-Service-Management
122
9.2
Service-Management-Plattform Action Request System
Das Action Request System (ARS) von BMC wird am LRZ seit 18 Jahren eingesetzt. Für das Change
Management, Beschaffungswesen, Asset-Management und die IP-Adressverwaltung wird weiterhin ARS
eingesetzt.
Die Webschnittstelle zum ARS wurde Ende August mangels Nutzung und aus Sicherheitsgründen abgeschaltet.
Die User-Lizenzen wurden von 20 auf 15 reduziert, da die Incidents jetzt in iET-Solutions bearbeitet
werden und die Nutzung von ARS aus diesem Grunde abgenommen hat.
Das KOM-Change-Record Formular unterstützt den Change-Management-Prozess in der Abteilung
Kommunikationsnetze. 2012 wurden insgesamt 1.275 (2011: 1.132) KOM-Change-Record-Tickets abgeschlossen.
9.3
Servicedesk
Der Servicedesk ist die Schittstelle zu Kunden und Anwendern der IT-Dienste des LRZ. Aufgabe des
Servicedesk ist es, die Serviceverantwortlichen, Administratoren und Fachleute am LRZ von 1st Level
Support-Anfragen soweit wie möglich zu entlasten und die Anfragen so aufzubereiten, dass der 2nd Level
Support umgehend mit der Problemlösung beginnen kann. Das gilt für die bestehenden Services, als auch
für alle neu aufzubauenden Dienste mit neuen Kundenkreisen. Der Servicdesk ist auch der primäre Integrationspunkt für die Incident-Management-Prozesse im Rahmen von ISO 20000. Er sorgt als Eigentümer
eines Großteils der Tickets für eine kontinuierliche Bearbeitung.
In einem Team von studentischen Hilfkräften mit hoher Fluktuationsrate sind diese hoch gesteckten Ziele
nur durch permanente interne Schulungen zu erreichen.
Als Hilfsmittel für das Wissensmanagement und den KnowHow-Transfer wird ein Sharepoint-basiertes
Portal eingesetzt, in dem die Servicedesk-Mitarbeiter wichtige Informationen sammeln, strukturiert hinterlegen und pflegen. Unterstützend kommen laufend Schulungen zu den Services, den ITSM-Prozessen
und den ITSM-Werkzeugen hinzu.
Insgesamt ist das große Interesse und Engagement aller Beteiligten, insbesondere auch unserer studentischen Hilfskräfte, sich mit neuen Themen auseinanderzusetzen und essentielle Rollen im Rahmen der ITSerivcemanagement-Prozesse zu übernehmen, sehr erfreulich und die Basis aller Verbesserungsmöglichkeiten.
123
10 Informationen und Weiterbildung
10.1 Kurse und Veranstaltungen
Das LRZ bietet seinen Kunden regelmäßig an die 20 Kurse an, die sich in die Bereiche PC-Software,
Hochleistungsrechnen und weitere Veranstaltungen einteilen lassen. Die in Tabelle 14 bis 16 aufgeführten
Veranstaltungen wurden von mehr als 1.000 Teilnehmern besucht. Zusätzlich haben externe Anbieter
weitere Kurse angeboten.
10.1.1 Kursübersicht, Statistik 2012
Wie schon in den vergangenen Jahren wurden die Kurse gut angenommen, die vom LRZ zum Thema
Hochleistungsrechnen angeboten wurden. Bei der Planung konnte stets davon ausgegangen werden, dass
alle Teilnahmewilligen, die einen Platz im Kurs erhalten, diesen auch wahrnehmen würden. Dies darf
beim übrigen Kursangebot leider nicht als selbstverständlich vorausgesetzt werden. Gerade bei den Kursen zu PC-Software ist der Unterschied zwischen der Zahl der Anmeldungen und der Zahl der Teilnehmer nach wie vor groß.
Es zeigte sich, dass das Interesse an Kursen zu den aktuellen Microsoft Office-Produkten nach wie vor
groß war. Dabei wird vom Kursprogramm des LRZ einerseits Aktualität erwartet, die Akzeptanz der
Anwender in Bezug auf neue Programmversionen andererseits hinkt dieser Erwartungshaltung häufig
hinterher. Oft werden aus den unterschiedlichsten Gründen Programmversionen auch einfach „ü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.
Kurse zu PC-Software
2012
Kurstitel
Dauer
Anzahl
Teilnehmer
Stunden
Kurse
angemeldet
Word 2010 (Kompaktkurs)
9
3
77
Excel 2010 (Kompaktkurs)
9
3
228
Excel 2010 (Fortsetzungskurs)
9
3
129
PowerPoint 2010 (Kompaktkurs)
9
3
88
Access 2010 (Kompaktkurs)
5
2
100
Photoshop Elements 10 Einführungskurs
9
3
68
Einführung in SPSS
6
2
38
56
19
728
Insgesamt:
Tabelle 14: Kurse zu PC-Software
Informationen und Weiterbildung
124
Hochleistungsrechnen
2012
Kurstitel
Dauer
Anzahl
Teilnehmer
Stunden
Kurse
angemeldet
Amsterdam Density Functional
6
1
13
Accelrys MatScience Workshop
8
1
21
Big Data Analysis
7
1
9
Data Visualisation for Publications and Websites
7
1
19
Programming with Fortran
9
1
23
Advanced Fortran Topics
9
1
14
10th VI-HPS Workshop
9
1
27
Introduction to large scale program development
and debugging on SuperMUC with DDT
7
1
8
Introduction to SuperMUC
9
1
29
Node-Level Performance Engineering
8
1
69
Parallel Programming on High Performance
Systems
9
1
3
Insgesamt:
88
11
235
Tabelle 15: Hochleistungsrechnen
Weitere Veranstaltungen
2012
Kurstitel
Dauer
Anzahl
Teilnehmer
Stunden
Kurse
angemeldet
Besichtigung von Rechner-Räumen des LRZ
3
1
39
Besichtigung des Zentrums für virtuelle Realität
und Visualisierung
3
1
52
Insgesamt:
6
2
91
Tabelle 16: Weitere Veranstaltungen
Auch im Jahr 2012 wurde – zusätzlich zum regulären Kursprogramm – die vorhandene, moderne 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.
10.1.2 Kurse und Ausbildung im Bereich Hochleistungsrechnen
10.2 Vorträge „Schattenseiten des Internet“
Die nach wie vor große Zahl der Missbrauchsfälle im Münchner Wissenschaftsnetz (v.a. mit Schädlingen
infizierte Rechner) zeigt, dass das Sicherheitsbewußtsein im Bereich der virtuellen Welt des Internet noch
deutlich besser werden muss.
Deshalb veranstaltet das LRZ regelmäßig den Vortrag „Schattenseiten des Internet – Praktische Tipps zur
Vermeidung von Gefahren“ vor Teilnehmern des Münchner Wissenschaftsnetzes (weitere Details und die
Handouts der Vortragsfolien siehe www.lrz.de/services/security/gefahren/).
125
Abbildung 77 Themenbild des Vortrags
Außerdem bietet das LRZ diesen Vortrag im Rahmen seiner Öffentlichkeitsarbeit Schulen und anderen
interessierten Einrichtungen an. Dies ist möglich, da sich der Vortrag an Einsteiger auf dem Gebiet der
Internet-Sicherheit richtet. Dabei stehen für Eltern und Lehrer einerseits und Jugendliche ab 11 Jahren
andererseits angepasste Varianten zur Verfügung. Die Schwerpunkte des Vortrags behandeln Problembereiche, die Kinder, Jugendliche und Erwachsene gleichermaßen betreffen: Alle Nutzer des Internet unterliegen mehr oder weniger umfangreichen rechtlichen Pflichten. Ein Verstoß dagegen (z.B. gegen das
Recht am eigenen Bildnis oder das Urheber-Recht) kann empfindliche Konsequenzen haben (z.B. Abmahngebühren von mehreren Hundert Euro). Leider kennen praktisch keine Jugendlichen und nur wenige Erwachsene diese Art von Gefahren.
Im Jahr 2012 wurden durch diesen Dienst des LRZ an der Allgemeinheit knapp 700 interessierte Zuhörer
erreicht. Dabei wurden u.a. bei drei Gymnasien jeweils komplette Schülerjahrgänge informiert. Zwei
Veranstaltungen wurden für Erwachsene (Eltern, Lehrer und Studenten) und ältere Jugendliche durchgeführt.
10.3 Öffentlichkeitsarbeit
Das herausragende Ereignis am LRZ aus öffentlicher Sicht war die Feier anlässlich des fünfzigjährigen
Bestehens des LRZ und der Inbetriebnahme des neuen Höchstleistungsrechners „SuperMUC“ am 20. Juli
2012, worauf bereits im Überblick eingegangen wurde.
Darüber wurde in sehr vielen Medien z.T. sehr ausführlich berichtet. Allein fünf Fernsehteams berichteten direkt aus dem SuperMUC u.a. für den Bayerischen Rundfunk, die „heute“-Sendung des ZDF und die
„Tagesschau“ der ARD. Die Aufnahmen eines Teams der Nachrichtenagentur Reuters fanden sich auf
sehr vielen Webseiten wie spiegel online u.ä. Auch in Rundfunk und Printmedien wurde ausführlich über
SuperMUC und LRZ berichtet, allen voran in der Süddeutschen Zeitung, die zusätzlich zur aktuellen
Berichterstattung der Geschichte des LRZ eine ganze Seite widmete. Sogar Fernsehteams aus Österreich
und Russland berichteten.
Neben vielen Interviews verschiedenster Medien vor allem im Zusammenhang mit der Nominierung des
SuperMUC als schnellstem Rechner Europas führte der Bayerische Rundfunk am 28. November ein sehr
126
Informationen und Weiterbildung
ausführliches Gespräch mit dem Vorsitzenden des Direktoriums, Prof. Dr. Arndt Bode (Ausstrahlung in
der Reihe BR-alpha Forum im Frühjahr 2013).
Insgesamt kann man feststellen, dass das LRZ im Jahre 2012 so intensiv in der Öffentlichkeit präsent war
wie nie zuvor. Besonders erfreulich ist die Tatsache, dass alle Berichte, Interviews usw. positiv waren.
Anlässlich der Feier am 20. Juli widmete „Akademie aktuell“ die gesamte Ausgabe dem Höchstleistungsrechnen, SuperMUC und dem LRZ.
Am 22. Februar besuchte MdB Florian Hahn das LRZ.
Am 15. April 2012 erschien in der Neuen Zürcher Zeitung (NZZ am Sonntag) die ausführliche und exzellente Reportage „Vorbild Gehirn“ von Andreas Hirstein über die Herausforderungen an Supercomputer
im Vergleich zum menschlichen Gehirn.
Auch über die Eröffnung des Zentrums für Virtuelle Realität und Visualisierung V2C (v2c.lrz.de) am 25.
Oktober 2012 berichteten die Medien.
Etliche Firmen erstellten „Success Stories“ über den Einsatz ihrer Produkte am LRZ, u.a. fertigten IBM
und SUSE Videos für YouTube und andere öffentlich zugängliche Webseiten an. Auch im Rahmen eines
europaweiten Videos für PRACE war SuperMUC am LRZ ein Hauptdrehort.
Am 18. Oktober konnte das LRZ seine Dienstleistungen für Studenten wieder an einem Infostand bei der
Erstsemesterbegrüßung der LMU vorstellen.
Beim „Tag der offenen Tür“ am 27. Oktober 2012 besichtigten etwa 1.500 Besucherinnen und Besucher
das LRZ und sein neues Zentrum für Virtuelle Realität und Visualisierung V2C. Erstmals wurden auch
englischsprachige Führungen angeboten, die sehr gut angenommen wurden. Insgesamt nutzten im Berichtsjahr über 3.500 Besucherinnen und Besucher bei ca. 85 Führungen die Gelegenheit, das LRZ kennen zu lernen.
Das Erscheinungsbild der Webseiten des LRZ wurde komplett neu gestaltet.
Der ständig wachsenden Zahl von Studenten aus dem Ausland an den Münchner Universitäten trägt das
LRZ dadurch Rechnung, dass viele seiner Webseiten inzwischen auch auf Englisch verfügbar sind, vor
allem die Seiten, die den Einstieg in das Studium und die Nutzung der Dienste des LRZ erst ermöglichen.
Das LRZ gibt gemeinsam mit dem Jülich Supercomputing Centre und dem Hochleistungsrechenzentrum
Stuttgart zweimal im Jahr anlässlich der Supercomputing-Konferenzen SC und ISC die Zeitschrift „inSiDE – Innovatives Supercomputing in Deutschland“ mit Beiträgen über Projekte, die auf dem Höchstleistungsrechner des LRZ bearbeitet wurden, heraus. Zusätzlich liefert das LRZ Beiträge zum Infobrief der
Gauß-Allianz e.V. Anlässlich der Außerbetriebnahme des vorherigen Höchstleistungsrechners SGI Altix
4700 erschien ein Berichtsband über die darauf bearbeiteten wissenschaftlichen Projekte.
Darüber hinaus erschien monatlich der LRZ-Newsletter, in dem u.a. Termine, Veranstaltungen, Kurse
und Stellenangebote mitgeteilt wurden und der über eine Mailingliste verteilt sowie im Web angeboten
wird. Dort ist auch ein Newsletter-Archiv verfügbar.
Ferner stehen Faltblätter zur Verfügung, die sich auf Deutsch und Englisch an die allgemeine Öffentlichkeit wenden oder speziell für Studenten die Dienstleistungen des LRZ vorstellen. Besonders die Faltblätter für Studierende in Deutsch und Englisch, die in den größeren Bibliotheken der Universitäten ausgelegt
werden, fanden viele Abnehmer.
Anlässlich der Einweihungsfeier wurde die Darstellung des LRZ in einer Postergalerie aktualisiert und
überarbeitet. Auch diese ist auf dem Webserver des LRZ verfügbar (http://www.lrz.de/wir/postergalerie/).
Für die Zusammenarbeit mit den Medien erwies es sich als unverzichtbar, ihnen einen festen Ansprechpartner (http://www.lrz.de/presse/) nennen zu können.
127
11 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.
11.1 Bundesweiter Rahmenvertrag für Microsoft-Lizenzen
Mit Microsoft Irland wurde zum 1. Mai 2012 erstmals ein bundesweit gültiger Rahmenvertrag über die
Lizenzierung von Software auf Subskriptionsbasis abgeschlossen. Er wurde gemeinsam mit dem Arbeitskreis Software-Lizenzen des ZKI vorbereitet. Alle deutschen Hochschulen können diesem bis April 2017
gültigen Vertrag eigenständig beitreten. Er räumt Einstiegshürden für kleinere Hochschulen aus dem Weg
und enthält hohe Rabatte und nützliche Zusatzvereinbarungen. Bestehende Landesverträge werden nach
und nach in diesen Bundesvertrag überführt. Der im Vorjahr abgeschlossene bayerische Landesvertrag,
der in wesentlichen Punkten die Vorlage für den bundesweiten Vertrag bildete, läuft weiter, jeder teilnehmende Hochschule kann selbst kalkulieren, ob sich für sie ein Umstieg während der Laufzeit lohnt.
Beim Umstieg kann die Bindung an den für den Landesvertrag im Vorjahr ausgeschriebenen Handelspartner und an die seinerzeit festgelegte Preisliste erhalten bleiben.
11.2 Überregionaler Rahmenvertrag zum Bezug von Beratungs- und
Supportdienstleistungen zu Microsoft-Produkten
Im Dezember konnte zwischen dem LRZ und Microsoft Deutschland ein Vertrag, der den Universitäten
und Hochschulen in Bayern günstigen Zugang zu Support- und Beratungsleistungen der Firma Microsoft
verschafft („Premier Support“), abgeschlossen werden. Der Vertrag sieht den solidarischen Austausch
von Knowhow und Erfahrungen zwischen den Hochschulen vor. So wird auch kleinen Standorten der
ansonsten unerschwingliche Zugang zu Dienstleistungen des Premier-Support Programms von Microsoft
ermöglicht. Teilnehmer sind zunächst bayersiche Hochschulen. Künftig kann jede Hochschule im Bundesgebiet eigenständige Beitritte unter diesem Vertrag abschließen.
11.3 Bayernweiter Mietvertrag für Adobe-Lizenzen
Mit Adobe Irland wurde im März 2012 ein Vertrag über die Lizenzierung von Acrobat Pro auf Subskriptionsbasis abgeschlossen („Adobe TSL“), über den sich bayerische Hochschulen versorgen können. Mit
der Vergabestelle der Universität Würzburg wurde für die teilnehmenden Hochschulen ein Handelspartner ausgeschrieben, den Zuschlag bekam die Firma Cancom.
11.4 Vereinfachung der Versorgung mit ESRI-Lizenzen an der TU München
Die Versorgung der TU München mit Lizenzen aus dem ESRI-Landesvertrag des LRZ konnte vereinfacht
werden: die Institute der TU müssen nun nicht mehr einzeln individuelle Bestellungen beim LRZ vornehmen, stattdessen wird eine flächendeckende Vollversorgung („Flatrate“) ermöglicht. Die TU beteiligt
sich mit einem festen Betrag an den Kosten des Landesvertrages.
Software-Bezug und Lizenzen
128
11.5 Vereinfachung der Versorgung mit Mathematica-Lizenzen an der
LMU München
Auf ähnliche Weise konnte die Versorgung der Physik-Fakultät der LMU mit Mathematica-Lizenzen in
ein Flatrate-Modell überführt werden (wobei in diesem Fall die Physik selbst direkt mit dem Handelspartner abrechnet).
11.6 Weitere laufende Verhandlungen und Planungen
Für das erste Halbjahr 2013 geplante Aktivitäten, die schon 2012 begonnen wurden, beinhalten u.a. die
Vorbereitung eines bundesweiten Rahmenvertrags für Adobe-Mietlizenzen nach dem Vorbild des Microsoft-Bundesvertrags und des Adobe-Landesvertrags (beides siehe oben). Der Novell-Landesvertrag für
Bayern endet im Oktober 2013 und muss sowohl mit dem Anbieter als auch im Innenverhältnis der bayerischen Hochschulen neu verhandelt werden.
11.7 Tagesgeschäft
11.7.1 Abläufe und Änderungen bei der Versorgung der Kunden des LRZ
Das LRZ stellt den Münchner Hochschulen unter anderem Kauflizenzen aus den Bereichen
 Microsoft-Lizenzen im Rahmen der Select-Plus-Verträge
 Adobe- und Corel-Bestellungen im Rahmen des Adobe CLP-Vertrags
zur Verfügung. Dies sind bisher die umsatzstärksten Bereiche. Wo es sinnvoll ist, eine flächendeckende
Pauschalversorgung mit Mietlizenzen einzuführen, sollte das auch gemacht werden. Dadurch kann der
anfallende Arbeitsaufwand sowohl in den Instituten als auch im LRZ reduziert werden. Der mit Kauflizenzen erzielte Umsatz ist also kein Erfolgsindikator, im Gegenteil sind etwa bei den MicrosoftKauflizenzen sinkende Umsatzzahlen sogar Folge der Verbesserung der Versorgungssituation (die TUM
ist im Sommer 2011 dem vom LRZ abgeschlossenen bayernweiten Mietvertrag für Microsoft-Lizenzen
beigetreten und musste daher in 2012 nur noch Serverprodukte über das Select-Plus Programm kaufen).
Bei Bestellungen zu Microsoft und Adobe/Corel-Kauflizenzen kümmert sich das LRZ im Tagesgeschäft
lediglich um Authentifizierung/Autorisierung der Besteller, Verteilung der Software, Beratung und 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 nachfolgende Tabelle listet die wertmäßig umsatzstärksten Softwarepakete (nur Kauflizenzen) auf.
Miet- und Subskriptionsmodelle (SPSS, Matlab, Novell, SAS) sowie Flatrate Verträge (ESRI, Sophos)
werden nicht in dieser Tabelle erfasst.
Hersteller /
Name
Beschreibung
Lizenzzahlen 2012
Bruttowert
der
2012 beschafften
Lizenzen
Microsoft
Applikationen, System- und ServerSoftware
13.568
320.155 €
Adobe und Corel
Acrobat, Photoshop,
GoLive, Illustrator,
Premiere etc., Corel
Grafiksoftware
ca. 3.300
382.617 €
Endnote
Literaturverarbeitung
99
8.079,- €
Systat
Datenanalyse
und
Datenpräsentation
48
14.246,- €
129
Bei den meisten anderen Produkten tritt das LRZ in Vorleistung und beteiligt die Institute an den Kosten:
 SPSS: im MWN im oberen fünfstelligen Bereich, bayernweit deutlich über 100.000 Euro
 Matlab: der Umsatz im MWN erreichte 2012 einen niedrigen sechsstelligen Eurobereich.
 Bei etlichen weiteren Produkten lagen die Umsätze im fünfstelligen Bereich.
Für Einrichtungen mit zentralem Einkauf besteht die Möglichkeit, die am meisten nachgefragten Kauflizenzen beim LRZ online zu bestellen. Zu diesen Einrichtungen zählen die Münchner Universitätskliniken, die Universität Augsburg, einige Hochschulen aus dem südbayerischen Raum sowie einige kleinere
Einrichtungen.
Produkte aus Landesverträgen (Novell, Sophos, ESRI, Secunia) werden den bayerischen Universitäten
und Hochschulen nach einem festen Kostenschlüssel bereitgestellt, daher gibt es an dieser Stelle keine
Umsatzzahlen (ESRI-Produkte werden an der LMU teilweise noch mit den Instituten einzeln abgerechnet). Produkte aus Landesrahmenverträgen (Microsoft EES, Adobe TSL) werden direkt zwischen den
ausgeschriebenen Händlern und den Lizenznehmern abgewickelt, ohne dass das LRZ involviert werden
muss.
11.7.2 Routinemäßige Verlängerung und Ausbau bestehender Verträge
2012 wurden mehrere auslaufende Verträge abgelöst oder planmäßig verlängert (Labview, SAS, Ansys,
Novell, NAG, Scientific Workplace). Die Verlängerung des Landesvertrags zu ArcGIS Geoinformationssystem-Software mit der Firma ESRI und des Bundesvertrags über Adobe Kauflizenzen („CLP“) erfolgten zum Jahreswechsel 2012/2013.
11.7.3 Betrieb von Lizenzservern für Kunden des LRZ
Das LRZ betreibt derzeit für ca. 30 unterschiedliche Softwarepakete Lizenzserver, die für die Benutzer im
MWN Netzwerklizenen zur Verfügung stellen. Das angebotene Spektrum der Netzwerklizenzen beinhaltet vor allem technisch wissenschaftliche Software (Matlab, Mathematica, Ansys, Patran, etc).
Für Kurse und Praktika in den CIP-Pools der berechtigten Einrichtungen im MWN werden die Teaching
Lizenzen der FE-Software Ansys über den Lizenzserver vom LRZ kostenfrei zur Verfügung gestellt.
Der zentrale Betrieb der Lizenzserver am LRZ erspart den Mitarbeitern an den Lehrstühlen und Instituten
im MWN den redundanten Betrieb eigener Lizenzserver und damit viel Arbeit. Im Bedarfsfall unterstützt
das LRZ die Anwender bei der Anbindung ihrer Rechner an die Lizenzserver am LRZ.
Benutzerverwaltung und Verzeichnisdienste
130
12 Benutzerverwaltung und Verzeichnisdienste
12.1 Benutzerverwaltung für LRZ-Dienste
Im Zentrum der Benutzerverwaltung steht das LRZ-Identity-Managementsystem (LRZ-SIM) mit den
LRZ-Verzeichnisdiensten als Basis. Nach einem Überblick über die derzeit vergebenen LRZ-Kennungen
und ihre Verteilung auf die Hochschulen und LRZ-Plattformen wird über Stand und Entwicklung von
LRZ-SIM im Organisations- und Frontend-Bereich, in den angebundenen Diensten und Plattformen sowie im SIM-Serverbetrieb berichtet. Es folgen die Weiterentwicklungen bei der VerzeichnisdiensteKopplung mit den beiden Münchner Universitäten und beim MWN Active Directory als zentralem Infrastrukturdienst im gesamten Münchner Wissenschaftsnetz. Die Neuerungen in der Authentifikations- und
Autorisierungsföderation des DFN (DFN-AAI), in der das LRZ als Dienstleister und sogenannter Identity-Provider für die LMU und TUM fungiert, schließen dieses Kapitel ab.
12.1.1 Für LRZ-Systeme vergebene Kennungen
12.1.1.1
An Hochschuleinrichtungen vergebene Kennungen
Mail
Exchange
PC/OnlineSpeicher
Linux-Cluster
Webserver
persönliche
Homepages
NeSSI
(NV-Portal)
WebDNS
693
345
375
1.167
226
21
102
91
37
55
Bayer. Akad. der Wissenschaften
401
378
72
367
–
25
12
23
5
–
12.196 10.451
1.110
2.904
817
127
369
478
151
54
LMU München
von Campus
LMU
importiert
TU München
von TUMonline importiert
TSM
Einrichtung
VPN / WLAN
Die folgende Tabelle gibt einen Überblick über die vom LRZ an Hochschuleinrichtungen vergebenen
Berechtigungen, und zwar pro Dienst bzw. Plattform und mit Stand von Ende 2012. Für die LMU und die
TU München sind dabei außer den via Master User vergebenen Berechtigungen auch die Kennungen
aufgelistet, die direkt an den Hochschulen vergeben und via Campus LMU bzw. TUMonline importiert
wurden.
19.665
–
–
2.710
–
–
–
–
–
–
9.042
9.139
–
469
961
523
123
920
422
173
– 22.277 19.447
–
–
–
–
–
–
19.447
Hochschule München
420
383
–
9
39
–
74
4
4
2
andere bayerische Hochschulen
498
320
–
183
208
12
10
10
9
3
3.690
3.589
–
1.622
26
48
58
70
44
14
26
1
–
–
14
–
1
1
3
–
–
–
–
– 1.729
–
–
–
–
–
190
16
–
152
–
–
7
–
–
66.268 24.622 23.834 28.915 3.946
756
749 1.604
675
301
Öffentlich-rechtliche Einrichtungen
sonstige Einrichtungen
Grid-Kooperationsprojekte
HPC-Projekte
Gesamt
37
Tabelle 17: Vergabe von Kennungen für LRZ-Plattformen
Nicht in der Tabelle enthalten sind die Kennungen für den Höchstleistungsrechner, da es hier häufig Kooperationen gibt und daher keine klare Zuordnung zu einer Einrichtung möglich ist. Ende 2012 waren für
diese Rechner insgesamt 3.914 Kennungen vergeben, davon 1.673 für Projekte aus dem Grid-Bereich.
12.1.1.2
131
An Studenten vergebene Kennungen
An der Ludwig-Maximilians-Universität und der Technischen Universität werden Kennungen für Studenten direkt an den Hochschulen vergeben und anschließend von dort ans LRZ übernommen (via CampusLMU bzw. TUMonline). Für Studenten anderer Münchner Hochschulen erfolgt die Vergabe individuell
und direkt durch das LRZ.
Ende 2012 hatten gut 86.000 Studenten eine Kennung, die u.a. für die Dienste VPN/WLAN, Mail und
PC/Online-Speicher genutzt werden konnte. Hier die Aufteilung auf die Hochschulen mit den meisten
Kennungen:
Hochschule
Anzahl
Kennungen
Hochschule für Musik und Theater München
Hochschule für Fernsehen und Film München
Akademie der Bildenden Künste München
Hochschule für Philosophie München
Verwaltungs- und Wirtschaftsakademie München
FernUniversität Hagen
Hochschule für Politik München
sonstige Hochschulen
49.460
34.890
1.444
289
122
46
21
19
21
67
Gesamt
86.379
Tabelle 18: Vergabe von Kennungen an Studenten
12.1.2 Identity Management und Verzeichnisdienste
Das LRZ Identity-Management-System (LRZ-SIM) basiert auf einem Cluster von Verzeichnisdiensten
(Novell eDirectory und OpenLDAP), deren Datenbestände durch Konnektoren (sog. Novell IDMTreiber) live synchronisiert, transformiert und in die LDAP-Authentifizierungsserver sowie in die direkt
angebundenen Plattformen provisioniert werden. Als universelles Webfrontend dient das LRZ Id-Portal
(https://idportal.lrz.de), sowohl für die Benutzer (Self Services) als auch für die Master User, die LRZBetreuer, den Servicedesk und Administratoren.
12.1.2.1
Neuerungen in der Benutzerverwaltung und Organisation
Die wichtigste Entwicklung in LRZ-SIM war die technische Umsetzung der neuen LRZPasswortrichtlinie. Diese Richtlinie ist seit Anfang 2012 für LRZ-Mitarbeiter und seit Juni 2012 für alle
LRZ-Benutzer bindend. Neben der nun erzwungenen Passwort-Mindestqualität sind der regelmäßige
automatische Passwortverfall sowie der Änderungszwang von Startpasswörtern die wichtigsten Neuerungen. Kennungen mit verfallenem Passwort bzw. Startpasswort unterliegen einer technischen Sperre, die
die Anmeldung an allen Authentifizierungsservern blockiert (siehe Abbildung 78). Ausgenommen von
der LRZ-Passwortrichtlinie sind die von LMU und TUM importierten Kennungen, die der Passwortrichtlinie der jeweiligen Hochschule folgen, sowie die in Grid-Projekten angesiedelten Kennungen, für die ein
gültiges Passwort aufgrund von zertifikatsbasierter Authentifizierung nicht zwingend notwendig ist. Im
Id-Portal waren dazu umfangreiche Erweiterungen sowohl in den Login-Seiten als auch in den Self Services erforderlich, um die Änderungen von Start- und verfallenen Passwörtern zu erzwingen. Hinzu kamen in fast allen Dienstebenen des Id-Portals zusätzliche Anzeigen und Übersichten zu Status, Änderungs- und Verfallsdatum von Passwörtern. Begleitend zur technischen Umsetzung der Passwortrichtlinie
erfolgte eine vielschichtige Information von Benutzern und Master Usern.
132
Abbildung 78 Passwortstatus und Auswirkung auf die Authentifizierungsmöglichkeit bei den angebundenen Diensten und Plattformen
Die zentrale Benutzerverwaltung und die Betreuer am LRZ bilden den Second-Level-Support von LRZSIM und stehen den Master Usern und Administratoren beratend und helfend zur Seite bei Fragen und
Problemen im Zusammenhang mit der Verwaltung von Projekten, Kennungen und Berechtigungen. 2012
war der Support-Bedarf besonders hoch, da es eine Vielzahl von Detailfragen und Spezialfällen im Zusammenhang mit der Passwortrichtlinie zu beantworten und zu lösen galt. Darüber hinaus sorgten neue
Dienste für das VM-Serverhosting, neue Formen von Grid-Projekten und neue Kontingente für die Speicherbereiche im Linux-Cluster samt ihren unterschiedlichen technischen Auswirkungen für eine erhöhte
Zahl von Benutzeranfragen..
Bei neueren Diensten wurden die Betreuer und Master User dadurch entlastet, dass dort die Plattformverantwortlichen oder Administratoren über neue Webschnittstellen selbständig Berechtigungen vergeben
können, so z.B. für die Netzverantwortlichen- und Monitoring-Portale sowie für Zugänge für Administratoren im Web- und VM-Serverhosting-Bereich.
Mit der seit 2012 vorliegenden Verfahrensbeschreibung „Identity-Management“ werden die Vorgaben
des Datenschutzes umgesetzt. Da LRZ-Benutzer auf Anfrage Einblick in diese Beschreibung nehmen
können, ist für sie eine kompakte Übersicht über Art, Verwendung und Sichtbarkeit ihrer persönlichen
Daten in der zentralen LRZ-Benutzerverwaltung gegeben.
12.1.2.2
Erweiterungen bei der Anbindung von Plattformen und Diensten
In Vorbereitung der Außerbetriebnahme des Speichersystems AFS mit seinem sehr vielschichtigen und
feingranularen Berechtigungssystem wurden umfangreiche Untersuchungen über die bisherige Verwendung von AFS-berechtigten Kennungen angestellt. So konnten die AFS-Benutzer dann gezielt darüber
informiert werden, welche Migrationswege und Ersatzsysteme (z.B. NAS) für sie zur Verfügung stehen.
Im Laufe des Jahres wurden alle AFS-Berechtigungen mit Ausnahme der noch nicht migrierten virtuellen
Webserver gesperrt und zum Jahreswechsel die zugehörigen AFS-Volumes endgültig gelöscht.
Die Verwaltung der persönlichen Homepages, die bisher ebenfalls in AFS angesiedelt waren und deshalb
migriert werden mussten, wurde in LRZ-SIM integriert. Anstelle der bisherigen Kommandozeilenschnittstelle können Benutzer nun bequem über das Id-Portal Homepages und Aliasnamen anlegen und löschen
sowie Zertifikate für die verschlüsselte Übertragung beantragen. Sowohl das Anlegen neuer Homepages
und Aliasnamen als auch die Ermittlung des belegten Speicherplatzes in den Self Services geschieht live
durch Funktionsaufrufe auf den Webserver-Maschinen.
133
Bei Funktionskennungen wurde das Id-Portal für die Verwaltung von shared Mailboxen unterschiedlicher
Ausprägung und für deren Provisionierung nach Exchange erweitert. Es fehlen nun noch Funktionsobjekte für Exchange-Verteiler. Für deren Konfiguration und Verwaltung gibt es jedoch ein detailliertes Implementierungskonzept, das 2013 umgesetzt werden kann.
Für den autorisierten Mailversand wurde in den Authentifizierungsservern ein eigener Verzeichniscontainer namens Postouts eingeführt, den ein Loopback-Treiber aus den Containern der verschiedenen Mailsysteme provisioniert. Die für den autorisierten Mailversand wichtige Vervollständigung des Datenbestands um Funktionsmailadressen gelang durch vorausgehende Weiterentwicklungen des SIM-Schemas,
der SIM-Konnektoren und des Live-Imports aller TUM- und LMU-Funktionskennungen (siehe Abschnitt
12.2).
Nach Neuprogrammierung des Webformulars zur Beantragung einer LRZ-Kennung für externe Studierende werden nun auch hier Kennungen nach dem neuen LRZ-Namensschema vergeben und direkt die
SIM-Directorys statt die frühere LRZ-Oracle-Datenbank als Zwischenspeicher verwendet. Auch der jährliche Bulkimport der Kennungen der Studenten der Hochschule für Musik und Theater basiert nun vollständig auf Directorys.
Zum Ende des Jahres wurde im Id-Portal die Möglichkeit für Master User geschaffen, kurzlebige WLANKennungen für Gäste an den Hochschulen einzurichten, für die die herkömmliche Kennungsvergabe zu
aufwändig ist. Die Konnektor-Erweiterung im Backend zum Eduroam-Active-Directory ermöglicht diesen Benutzern den tageweisen WLAN-Zugang über die bewährte Eduroam-Technik.
Bei der Provisionierung des MWN-ADS wurde ein Automatismus zur Generierung von Gruppen eingeführt: Spezielle Entitlement-Werte in den Benutzerdaten regeln die Aufnahme von Kennungen in und die
Entfernung aus ADS-Gruppen. Dieser Automatismus kann gewinnbringend bei weiteren ADangebundenen Diensten zum Einsatz kommen, um den Zugang zu zielgruppenspezifischen Diensten und
Systemen an den Fakultäten zu regeln. Profitieren von diesem Konzept wird zunächst die Verwaltung der
VM-Infrastruktur, für die automatisch projektgebundene Gruppen von VM-Administratoren und VMServer-Bestellberechtigten erzeugt werden. Die dafür notwendigen Erweiterungen in LRZ-SIM und im
MWN-ADS-Konnektor sind weitgehend implementiert und werden Anfang 2013 produktiv geführt.
Auch für die HPC-Plattformen gab es auf Seiten der Benutzer- und Projektverwaltung einige Neuerungen. Zunächst wurde die Migration auf einheitliche Home-Verzeichnispfade vollzogen und in LRZ-SIM
abgebildet. Für das Linux-Cluster wurden in LRZ-SIM neue Kontingentierungsmöglichkeiten der HOME- und WORK-Bereiche eingeführt. Beim Höchstleistungsrechner SuperMUC wurden die RechenzeitRestkontingente des HLRB II für den SuperMUC skaliert übernommen. Die zukünftige Deprovisionierung der abgelaufenen HPC-Projekte und die Freigabe der von ihnen belegten Speicherbereiche unterstützt LRZ-SIM mit neuen Verwaltungsmöglichkeiten bei Historieneinträgen.
Die mySQL-Provisionierung der LRZ-SIM-Daten von HPC-Projekten und -Benutzern musste auf drei
neue Datenbanken aufgeteilt werden, getrennt für den SuperMUC, das Migrationssystem SuperMIG und
das Linux-Cluster. Diese Datenbanken dienen als Grundlage für Accounting, Antragsbearbeitung und
Statistik-Generierung.
Im Vorfeld der Inbetriebnahme des SuperMUC war die Planung und Inbetriebnahme von ausreichend
leistungsstarken Authentifizierungsservern erfolgt, wie im folgenden Abschnitt darlegt.
12.1.2.3
Entwicklungen im Server- und Dienstbetrieb
Für den IDM-Betrieb entscheidend ist die Leistungsfähigkeit der Authentifizierungsserver-Infrastruktur.
Zum Aufspüren von Performance-Engpässen oder auch zum Debuggen bei Schwierigkeiten der angebundenen Dienste wurden Logfile-Auswertungsprogramme geschrieben, die die sehr rasch wachsenden
LDAP-Logdateien nach Verbindungen und Benutzern gruppieren, die umfangreichen Informationen bündeln und die nicht explizit geloggten Antwortzeiten ermitteln können. Mit diesen Tools und ihrer pipelineartigen Implementierung stand dann eine gute Abschätzung der LDAP-Last zur Verfügung, die vom
SuperMUC zu erwarten war. Als geeignetste Basis wurden zwei Servernodes auf dem SuperMUC ausgewählt, motiviert durch die sehr leistungsfähige Hardware einerseits und die zu erwartende extrem hohe
LDAP-Last beim Start großer SuperMUC-Jobs andererseits. Mit LRZ-SIM-Unterstützung wurden auf
diesen zwei Nodes OpenLDAP-Server eingerichtet, die ihre Daten durch Replikation von den SIMOpenLDAP-Servern beziehen, wobei der Benutzerumfang auf die HPC-Kennungen eingeschränkt ist.
134
Die aktuelle Infrastruktur der LRZ-Authentifizierungsserver mit der Datenprovisionierung über Novell
IDM-Treiber (rot Pfeile) bzw. Replikationsmechanismen (graue Pfeile) sowie die beispielhafte Anbindung von Diensten und Servern (unten) ist in Abbildung 79 dargestellt. Dabei ist der Serverbetrieb auf
verschiedene LRZ-Gruppen verteilt: Die SIM-Server administriert das Directory-Team (gelb), die SuperMUC-Server die Gruppe HPC (schwarz), die Active-Directory-Server die Gruppe DesktopManagement (violett), und schließlich die Service Load Balancer die Gruppe Netzbetrieb (orange).
Abbildung 79 LRZ-Infrastruktur der Authentifizierungsserver
Im SIM-Kern ist das tägliche Backup um die Erzeugung von LDIF-Dateien erweitert worden, um im
Fehlerfall auch Ausschnitte des Datenbestandes restaurieren zu können. Sicherungen erfolgen sowohl auf
die lokale Platte als auch in ein eigenes NAS-Volume. Die LDAP-Server-Konfigurationen werden zusätzlich in Subversion gehalten. Auch die Konfigurationen der SIM-Webserver (Id-Server, Id-Portal, Webservices für Kennungen sowie die Shibboleth Identity-Provider) und die zeitgesteuerten Programme der
zentralen Benutzerverwaltung werden auf diese Art mindestens doppelt gesichert. Die neuen, zusätzlichen
Möglichkeiten des Backups ersetzen nun die in der Vergangenheit problematische TSM-Sicherung der
LDAP-Server, bei denen die Größe in Kombination mit der Dynamik der eDirectory- und OpenLDAPDatenbanken vermehrt zu Fehlern (und damit nicht brauchbaren) Backups geführt hatte.
Der SIM-Monitoring-Server wurde virtualisiert, was neben Ressourcenersparnis auch eine bessere Ausfallsicherheit und Administrierbarkeit brachte. Neue Restart-Skripte sichern die Verfügbarkeit der Monitoring-Prozesse selbst. Die von Nagios überwachten Services wurden um dienstspezifische Tests erweitert. Die parallel laufenden, eigenentwickelten LDAP-Monitoring-Tools liefern durch neue Fehlerzustandsspeicher zeitnäher Warnmeldungen, ohne diese Meldungen unnötigerweise zu oft zu wiederholen.
Schließlich gab es noch einige Maßnahmen zur weiteren Verbesserung der Sicherheit der Server: Die
AFS-Abhängigkeiten, die naturgemäß bei den SIM-Servern besonders ausgeprägt waren, konnten sukzessive reduziert und auf eine letzte Maschine verlagert werden. Ohne AFS konnten die SIM-Server, insbesondere diejenigen, auf denen öffentliche Dienste wie LDAP- oder Webserver laufen, auf die aktuellste
SLES-Version angehoben werden. Für diese wegen Sicherheits-Patches erforderliche Version stand nämlich kein AFS-Kernelmodul mehr zur Verfügung. Eine zweite Maßnahme, speziell für die Webserver wie
das Id-Portal, war die Konfiguration eines Apache-Modules, um beabsichtigte oder unbeabsichtigte Deni-
135
al-of-Service-artige Request-Szenarien zu verhindern. Eine dritte Verbesserung der Sicherheit brachte die
Revision der SSL-Konfiguration, wodurch auch neueren Angriffsszenarien erfolgreich begegnet wird.
12.2 CampusLMU und TUMonline
Annähernd zwei Drittel der aktiven Kennungen im Bestand von LRZ-SIM entstammen den zentralen
Verzeichnisdiensten von LMU und TUM (vgl. Tabellen in Abschnitt 12.1). Diese Benutzerdaten werden
von IDM-Konnektoren automatisch und ohne Verzögerung in LRZ-SIM synchronisiert und enthalten
Attribute, die die Berechtigungen für die vom LRZ erbrachten Dienste bei den einzelnen Kennungen
steuern.
12.2.1 CampusLMU-Anbindung
Für die bewährte Kopplung an den CampusLMU-Verzeichnisdienst waren in LRZ-SIM auch 2012 Anpassungen und Erweiterungen notwendig, um die sich wandelnden und erweiterten Dienste des LRZ für
die LMU optimal zu unterstützen.
Die sogenannten Entitlement-Attribute, die von CampusLMU bei Kennungen gesetzt und in LRZ-SIM
übernommen werden, dienen der automatischen Steuerung erweiterter Berechtigungen in LRZ-SIM selbst
(Linux für die Physik, Mail und PC für die Biologie I) sowie dem automatischen Erzeugen von Gruppen
im MWN-ADS. Für die AD-Anbindung einer Teaming-Software der LMU-Fakultät 11, die nahezu alle
LMU-Studenten und viele Mitarbeiter verwenden dürfen, wurde ein solches neues Entitlement eingeführt.
Dies bewirkte eine beträchtliche Erhöhung der Zahl von CampusLMU-Kennungen, die nun neu ins
MWN-ADS weiterprovisioniert werden.
Weiterhin wurde die Verschiebung von Kennungen zwischen LRZ-Projekten, basierend auf PhysikEntitlements für das Linux-Cluster, vollständig automatisiert. Ebenfalls automatisiert wurde die Deprovisionierung dieser Linux-Berechtigungen: CampusLMU-seitig ist kein dienstspezifischer Status „gesperrt“
vor der endgültigen Löschung möglich. Bei Wegfall des Linux-Entitlements löscht deshalb ein LRZseitiges Programm die Linux-Berechtigung und das Linux-Homeverzeichnis erst nach einer 14-tägigen,
aus dem Historie-Attribut ermittelten Karenzzeit.
Neben den aus Entitlements abgeleiteten Berechtigungen ist die explizite Dienste-Provisionierung durch
CampusLMU erweitert worden: So entscheidet nun allein CampusLMU, nach welchen Regeln ein Benutzer VPN- und Eduroam-Berechtigung bekommt, ohne dass auf LRZ-Seite ein manueller Prozess notwendig ist. In LRZ-SIM erforderte dies eine Erweiterung der Regeln, wann zu einer LMU-Person eine LRZKennung angelegt wird.
Ein weiterer Schritt in Richtung Automatisierung stellte die Übernahme der LMU-Funktionsmailadressen
direkt aus CampusLMU dar. Sie ersetzt damit einerseits manuelle Eintragungen in LRZ-SIM und ermöglicht andererseits auch den autorisierten Versand mit diesen Funktionsmailadressen als Absender.
Die Konsolidierung der LMU-Import-Projekte beseitigte die bisherige maildienstspezifische Trennung
von Kennungen. Importierte Kennungen können nun gleichzeitig eine CampusLMU-Mailbox und eine
lmu.de-Weiterleitung haben.
12.2.2 TUMonline-Anbindung
Erweiterungen der Funktionalität des TUMonline-Portals und der in den TUM-Verzeichnissen gespeicherten Objekte machten auch bei der nunmehr schon im zweiten Jahr stabil laufenden Kopplung der
TUM- und LRZ-SIM-Verzeichnisdienste Anpassungen erforderlich. Die beiden großen Arbeitsgebiete
dabei waren die Übernahme von Funktionsobjekten sowie die Zusammenführung von Status- und Berechtigungsinformationen mit fremd- und LRZ-vergebenen Diensten.
Obwohl das Schema der TUM-Funktionsobjekte mittlerweile sehr komplex ist, konnte die Kopplung
erfolgreich um diese Objekte erweitert und auf Funktionskennungen im LRZ-SIM-Schema abgebildet
werden. Eine Hürde bildete die Generierung von Personenobjekten und -referenzen, die in den TUMVerzeichnissen nicht separat vorhanden sind. Die TUM-Funktionsmailadressen, die in früherer Zeit manuell in LRZ-SIM eingetragen wurden, können nun sukzessiv konsolidiert und über TUMonline verwaltet
werden. Zudem haben mit den Funktionsobjekten nun sowohl der LRZ-Servicedesk wie auch Administratoren im Id-Portal einen kompletten Überblick über alle TUM-Kennungen.
136
Zusätzlich zu den von TUMonline importierten Kennung sind nach wie vor von Master Usern verwaltete
Kennungen in längerfristigen Projekten erforderlich, etwa für die Hochleistungsrechner, für Webserver
und für TSM-Backup und -Archivierung. Für einen besseren Überblick erhalten die TUMVerantwortlichen (CIO, Verwaltung) monatlich eine Liste der Master User von TUM-Projekten. Die aus
SIM-Sicht einfachen Dienstberechtigungen, etwa für die WebDNS-, Netzverantwortlichen oder Monitoring-Portale, können in LRZ-SIM zusätzlich auf TUM-Kennungen vergeben werden. Bei solchen Kennungen, deren Berechtigungen aus unterschiedlichen Quellen stammen, mussten jedoch geeignete Lösungen zur Deprovisionierung im TUM-Konnektor gefunden werden.
12.3 MWN Active Directory
Als weiteren großen Infrastrukturdienst betreibt das LRZ für das MWN ein mandantenfähiges Active
Directory (AD). Der Aufbau des zentralen, MWN-weiten AD wurde im Jahr 2007 im Rahmen der Bereitstellung von Exchange und den Fileservices für den MWN-Speicher auf Basis von NetApp mit CIFS
notwendig.
Dieses MWN-AD ist so angelegt, dass einzelne, große Institutionen wie LMU, TUM oder die BAdW
voneinander getrennt agieren können. Ziel ist es dabei, Synergien bei der Administration von DesktopPCs zu erschließen und Mehrwerte im Funktionsumfang für Anwender und Administratoren nutzen zu
können. Dieses „Remote Desktop Management“ Serviceangebot ist seit langem am LRZ erprobt.
Jede Organisationseinheit erhält eine vordefinierte Unterstruktur (Organisational Unit, OU) in diesem
Directory, die wiederum in Fakultäten und Lehrstühle weiter untergliedert werden kann. Auf diesen Ebenen können von einem sog. „Teil-Administrator“ des Kunden Computerkonten eingetragen und verwaltet
werden. Damit es nicht zu Namenskonflikten kommt, wurde ein verbindliches Namenskonzept für Objekte im Active Directory entwickelt. Zur Erfüllung ihrer Aufgaben wird den Teil-Administratoren ein Set an
Werkzeugen über zwei Terminalserver zur Verfügung gestellt. Die Einrichtung dieser Organisationsstrukturen wurde in 2008 für die TU München umgesetzt und wird stetig in Absprache mit der TU München
angepasst. Für die LMU wird die Struktur bei Bedarf angelegt. Die Benutzerkonten und zentralen Gruppen werden über die beiden Metadirs (SIM, TUM) am LRZ weitestgehend automatisiert gepflegt. Dabei
kommen Softwarelösungen der Firma Novell zum Einsatz.
Mit dem MWN Active Directory können alle Clients ab Windows 2000 verwaltet, Mac OS X und LinuxSysteme integriert werden. Momentan sind aus den Mandanten TUM, LMU, HMT, BVB und BAdW
rund 4.870 (Vorjahr: 3.550) Rechner im MWN-AD integriert. Es wurden bisher 508 (398) Teiladmins aus
302 (227) Einrichtungen registriert und in 2012 haben sich an der Infrastruktur rund 29.000 (21.000) verschiedene Nutzer angemeldet. Dabei wurden Dienste wie der MWN-Speicher, die Groupware Exchange
oder die Anmeldung an ins MWN-AD integrierte Clientrechner genutzt.
Seit 2009 erfolgt die Provisionierung der Benutzerkonten der TU München aus den Metadirs in das Active Directory durch den Identity Manager Driver for Scripting von Novell, der Attributsänderungen an
vom LRZ selbstentwickelten PowerShell Skripten an die AD-Seite übergibt. Dadurch wird eine enorme
Flexibilität beim Verarbeiten und der Fehlerbehandlung von Ereignissen erreicht.
In 2012 wurden die Skripte weiter angepasst und bei der Verarbeitung von Funktionsobjekten wie Gruppen, shared Mailboxen, Ressourcenmailboxen und Verteilerlisten weiter verfeinert.
Viel Zeit floss auch in diesem Jahr in die Planung und Abstimmung mit der TUM. Um den Übergang von
Berechtigungen bei der Vergabe oder dem Entzug von Berechtigungen für Kennungen abzubilden, sollen
in Zukunft Dienstübergänge definiert werden. Dadurch lassen sich dann einzelne Berechtigungen im
MWN-AD, MWN-Speicher und Exchange unabhängig voneinander vergeben. Die Realisierung ist für
2013 geplant.
Um auch Gruppierungen im LRZ-SIM Verzeichnis umzusetzen ist mit der Provisionierung von Entitlements als Benutzerinformation eine einfache Art der Gruppierung von Benutzerobjekten im MWN Active
Directory implementiert worden. Dieser Mechanismus kann nun von der LMU direkt genutzt werden um
Gruppen ohne Zutun des LRZ im MWN-AD zu pflegen.
In 2012 wurde für notwendige Infrastrukturdienste wie dem SCCM 2012 eine ins MWN-AD integrierte
Windows Zertifizierungsstelle aufgebaut. Über die CA werden seit 2012 automatisiert Computerzertifikate an alle konfigurierten Windows Clients verteilt.
137
12.4 DFN-AAI/Shibboleth
Föderiertes Identity Management (FIM) auf Basis der Software Shibboleth ermöglicht es Benutzern,
Webdienste, die außerhalb ihrer eigenen Hochschule oder Einrichtung angesiedelt sind, mit der lokalen
Hochschulkennung zu nutzen. Den organisatorischen Rahmen für einen solchen Diensteverbund stellt die
DFN-AAI-Föderation dar. Als Authentifikationskomponenten, sogenannte Identity Provider (IdP), betreibt das LRZ in der DFN-AAI neben dem eigenen LRZ-IdP auch die IdPs für die LMU und die TUM.
Die IdPs nutzen dabei als Datenbasis die SIM- und TUM-Verzeichnisdienste. Die großen Vorteile der
Shibboleth-Authentifizierung, auch für nur hochschullokale Dienste, gegenüber einer LDAP-Anbindung
sind:
 Datenschutz: bedarfsgetriebene und vom Benutzer explizit zu genehmigende Weitergabe persönlicher Daten nur an die Dienste, die der Benutzer wirklich nutzt (keine universell leseberechtigten
LDAP-Proxy-User, kein User-Provisioning auf Vorrat)
 Sicherheit: Passworteingabe ausschließlich am IdP der Heimat-Einrichtung statt bei jedem Webdienst extra, und damit u.a. Schutz vor Phishing
 Komfort: Einmalige Passworteingabe für Zutritt zu allen Webdiensten während einer BrowserSession (Single-Sign-on)
12.4.1 Entwicklungen im Identity-Provider-Dienstbetrieb
Bei den drei Servern für die TUM-, LMU- und LRZ-IdPs lag der Schwerpunkt der Weiterentwicklung auf
der informationellen Selbstbestimmung: Die Konfiguration der Benutzerdatenfreigaben wurde grundlegend überarbeitet und an vorgegebene DFN-Standards angepasst. Trotzdem die Benutzer – im Gegensatz
zu einer LDAP-Authentifizierung – vor der Nutzung eines Webdienstes der Weitergabe ihrer persönlichen Daten explizit zustimmen müssen (Digital ID Card), konnte die Menge dieser Daten IdP-seitig vorab
weiter eingeschränkt werden: Erstens wird der eduPersonPrincipalName nur noch an diejenigen Webdienste übertragen, die explizit Bedarf an diesem Identifikator angemeldet haben. In der Regel können die
Dienste einen Benutzer bei späteren Logins allein aufgrund eines automatisch berechneten Pseudonyms
(eduPersonTargetedID) seinem bisherigen Profil zuordnen. Zweitens werden die Entitlement-Werte, die
Voraussetzung z.B. für den Zugriff auf kostenpflichtige Online-Publikationen sind, gefiltert und dedizierter für einzelne SPs weitergegeben.
Ein sehr sporadisch auftretender, aber dann schwerwiegender Fehler der Shibboleth-Software verhinderte
zeitweise, dass die Metadaten aus den Föderationen automatisch aktualisiert wurden. Das Problem konnte
dadurch entschärft werden, dass ein eigenentwickeltes Programm regelmäßig die Restgültigkeitsdauer
aller Zertifikate in den Metadaten geprüft.
Seit Mitte 2012 ist im LRZ-IdP die Voraussetzung dafür geschaffen, dass über dessen Authentifikation
auch Dienste außerhalb Deutschlands genutzt werden können; genauer: Dienste, die über die Metaföderation eduGAIN zugänglich sind. EduGAIN ist eine Föderation von Föderationen, zu der seit 2012 auch der
DFN-AAI gehört. Technisch ist hier die explizite Einbindung der eduGAIN-Metadaten notwendig für alle
Dienste, die nicht auf „tieferer“ Ebene wie DFN-AAI oder einrichtungslokalen Freigaben erreichbar sind.
Es handelt sich dabei um ein Opt-in-Verfahren, d.h. Identity- und Service-Provider müssen bei der DFNAAI explizit zur Aufnahme in eduGAIN gemeldet werden. 2013 wird auch die Aufnahme der IdPs von
TUM und LMU beantragt.
12.4.2 Anpassungen für spezielle Service Provider
Für zwei sehr nützliche Dienste – den Transfer großer Datenmengen (GigaMove) und den DFNWebkonferenzdienst – wurde die Freischaltung der drei IdPs bei den jeweiligen Service Providern veranlasst und die Freigabe der notwendigen Attribute im IdP konfiguriert.
Ein Pilotprojekt stellte die Einbindung des SPs für die Online-Abstimmung über die Einführung eines
Semestertickets in München dar, weil hier mit den Verantwortlichen von TUM, LMU und HM nicht nur
Fragen des Datenschutzes, sondern auch spezielle Anforderungen bei Senioren- und Promotionsstudenten, Doppel- und Zweit-Studiengängen zu lösen waren. Zudem mussten Mechanismen zur Verhinderung
von doppelter Stimmabgabe gefunden werden.
138
Daneben gab es eine Reihe von zumeist hochschullokalen Diensten, die Shibboleth-Authentifikation nutzen und von den IdPs eine erweiterte Berechnung und Freigabe von Benutzerattributen benötigten. Dabei
handelte es sich um Dienste wie Wiki-, Blog- und Evaluations-Server, weitere TUM-Typo3-Instanzen
und LMU-Moodle-Instanzen (Medizin, Chemie, Physik, BWL).
Für Berechtigungen, die nicht das Identity-Management-System selbst, sondern wie im Falle der vhbKurse ein Dritt-Dienstleister mittels Entitlement-Werten vergibt und verwaltet, wurde eine Lösung mit
Zwischenspeicherung in der lokalen Datenbank der Identity-Provider-Server implementiert. Damit sind
IdP-seitig diese Attribute nun ganz von den Directorys entkoppelt, um Seiteneffekte von Konnektoren
(Löschung aller Entitlement-Werte) zu vermeiden. Nach erfolgreichem Login werden die in der Datenbank gespeicherten Werte dann zusätzlich zu den aus dem Directory ausgelesenen Entitlements in der
Benutzerfreigabe angezeigt und an den Service Provider ausgeliefert. Leider wird die Möglichkeit der
Autorisierung für vhb-Kurse über die beim Shibboleth-Login mitgelieferten Attribute nach wie vor von
keinem Moodle-Betreiber unterstützt.
139
13 Dienste mit Sondervereinbarungen
13.1 Bibliotheksverbund Bayern
Zur Erhöhung der Redundanz der Bibliothekssysteme wurde eine Planung erstellt, die vorsieht, die Clustersysteme auf die Brandabschnitte zu verteilen. Im Serverraum in DAR1, der in einem anderen Brandabschnitt liegt, wurden die technischen Vorbereitungen zur Installation der Clusterrechner durchgeführt. Um
die Speicherkomponenten auf die Brandabschnitte zu verteilen, müssen weitere Speichersysteme beschafft werden. Dazu wurde ein Antrag für Großgeräte der Länder gestellt. Der Antrag wurde ohne Abzüge genehmigt, die Ausschreibung ist für 2013 in Vorbereitung.
Weiterhin wurde die Ersetzung des jetzigen Firewallclustersystems, das schon heute den Datenverkehr
nicht mehr komplett verwalten könnte, geplant. Für den Backupverkehr wurde dabei eine Lösung auf
kostenfreier Open Source Software (pfsense) auf Althardware aufgebaut, um so den Betrieb aufrechterhalten zu können. Der Ersatz des Firewallclustersystems und die Verteilung des Clusters auf die beiden
Brandabschnitte ist auch Teil des oben genannten Antrags und der Ausschreibung.
In Kooperation mit der Bayerischen Staatsbibliothek wurde das System zur Langzeitarchivierung „Rosetta“ von Ex Libris nach einer zweijährigen Projektphase jetzt produktiv geführt. Das LRZ betreibt die
Plattform und betreut das Betriebssystem sowie den zugehörigen Datenbankcluster und die angeschlossenen Speichersysteme. Die Archivierung der Daten erfolgt auch durch das vom LRZ betriebene Backupsystem „Tivoli Storage Manager“ von IBM.
13.2 Managed Hosting für hochschulstart.de
In diesem Jahr etablierte die „Stiftung für Hochschulzulassung“ (Stiftung öffentlichen Rechts) als Nachfolger der „Zentralstelle für die Vergabe von Studienplätzen“ (ZVS) gemäß dem Auftrag der Kultusministerkonferenz das bundesweite, zentrale "Dialogorientierte Serviceverfahren" für die Vergabe von Studienplätzen. Der Wirkbetrieb, an dem sich grundsätzlich alle deutschen Hochschulen beteiligen können,
wurde im April gestartet.
Über eine Web-Applikation können sich Bewerber bei mehreren Hochschulen bewerben. Somit sind
Letztere in der Lage, eine effizientere Bewerberauswahl, genauer gesagt Zu- oder Absagen zu treffen.
Das LRZ, das im Vorjahr die Entwicklung der neuen Plattform technisch begleitet hat, ist für den Infrastrukturbetrieb zuständig; das Managed Hosting für die neue Applikation verlief aus Sicht des LRZ störungsfrei. Die Applikation selbst wird von der Firma T-Systems Multimedia Solutions (MMS) betreut.
IT-Sicherheit
140
14 IT-Sicherheit
14.1 Antivirus
Auf der Grundlage eines Landesvertrages über die Antiviren-Software der Fa. SOPHOS betreibt das LRZ
eine Service-Infrastruktur zur automatischen Verteilung und Installation von SOPHOS-Virensignaturen
für alle Nutzer im Münchner Wissenschaftsnetz, verbunden mit entsprechenden Beratungsleistungen zur
Nutzung für Endbenutzer und CID-Betreibern in Bayern. Der Dienst wird täglich von rund 25.000 Clients
im MWN genutzt. Der gesamte First-Level-Support wird inzwischen von den Auszubildenden am LRZ
geleistet.
(Weiterführende Serviceinformationen siehe: http://www.lrz.de/services/security/antivirus/).
14.2 WSUS
Zur Versorgung von Clients im MWN mit Sicherheitsupdates für Windows-Betriebssysteme und 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.
(Weiterführende Serviceinformationen siehe: http://www.lrz.de/services/security/mwnsus)
14.3 Virtuelle Firewall
Das LRZ betreibt 5 Cisco Firewall Service Module (FWSM), die sich auf verschiedene Backbone-Router
im Münchner Wissenschaftsnetz (MWN) verteilen, und zwei ASA5580-40 zentral am LRZ (technische
Details siehe Jahresbericht 2009). Derzeit werden damit rund 115 Kunden (104 im Vorjahr) mit virtuellen
Firewalls (VFW) bedient.
Abbildung 80 Entwicklung der Anzahl von Kunden-VFWs
Abbildung 81 zeigt die Web-Schnittstelle zur Administration einer VFW.
141
Abbildung 81 Web-Schnittstelle Adaptive Security Device Manager (ADSM)
Die beiden zentralen ASA5580-40 sollten im High-Availability-Modus (HA) in Betrieb genommen werden. Das wurde möglich, da die neueste Betriebssystemversion von Cisco sogenannte „Shared-Licenses“
zulässt. Das bedeutet, dass jetzt nur noch eine Lizenz pro VFW benötigt wird, die für beide ASA5580-40
gilt. Zuvor fielen im HA-Betrieb doppelte Lizenzkosten an, da pro VFW und pro ASA5580-40 eine Lizenz benötigt wurde. Leider stellte sich diese und alle folgenden Betriebssystemversionen als so fehlerhaft heraus, dass der geplante HA-Betrieb zurückgestellt werden musste.
Um die Ausfallsicherheit zu erhöhen, wurde eine ASA5580-40 räumlich getrennt von der anderen aufgestellt. Diese befindet sich nun im Erweiterungsbau des Rechnerwürfels.
Alle VFWs wurden für den Einsatz mit IPv6 vorbereitet. Viele Netze hinter den Firewalls haben bereits
IPv6 Interface-Adressen erhalten und sind somit nativ mit IPv6 versorgt.
Die Planungen für die Ersetzung der FWSMs haben begonnen. Als Folge der Ersetzung der BackboneRouter 2013 können die FWSMs nicht weiter betrieben werden, da die neue Router-Plattform nicht mit
den vorhandenen FWSMs kompatibel ist. Dazu gab es bereits Gespräche und Produktpräsentationen
14.4 Sicherheitswerkzeuge und Sicherheitsmanagement
14.4.1 Secomat
Das automatische proaktive Intrusion Prevention System (IPS) Secomat (vormals NAT-o-MAT) besteht
derzeit aus einem Cluster mit 4 Nodes (Geschichte siehe Jahresbericht 2007 und 2009). Jeder Node kann
eine theoretische Datenübertragungsrate von 10Gbit/s bewältigen. Die eingesetzte Technik zur Lastverteilung spaltet jedoch nur einmal 10Gbit/s auf die 4 Nodes auf. Diese Obergrenze wird vom MWNBackbone vorgegeben, das auf dem 10-Gbit/s-Ethernet-Standard fußt.
IT-Sicherheit
142
Die folgenden Abbildungen zeigen Datenübertragungsraten, Benutzer und gesperrte Benutzer des Secomat-Clusters im Zeitraum von einer Woche.
Abbildung 82 Secomat1
Abbildung 83 secomat2
Die folgende Tabelle zeigt die Spitzenwerte bei Datenübertragungsrate und gleichzeitigen Benutzern.
Secomat-Cluster
Eingehende Datenübertragungsrate
ca. 2,3 Gbit/s
Ausgehende Datenübertragungsrate
ca. 3,7 Gbit/s
Gleichzeitige Benutzer
ca. 17.000
Tabelle 19: Spitzenwerte der eingehenden und ausgehenden Datenübertragungsrate,
sowie der Benutzeranzahl
Der Secomat-Cluster zeigt sich im Betrieb zuverlässig. Probleme im Betrieb macht im Großen und 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 SkypeClients auf dem Client-PC beeinflusst werden. Je nach Betriebssystem gibt es dafür unterschiedliche Lösungen. Zur Unterstützung der LRZ-Kunden wurde dazu eine ausführliche FAQ im Webserver des LRZ
eingestellt. Die FAQ wurde um eine benutzerfreundliche Variante für Apples OS X ergänzt. Das LRZ
143
stellt in diesem Fall ein vorkompiliertes Apple Script zur Verfügung, mit dem die erforderlichen Einstellungen per Mausklick durchgeführt werden (siehe https://www.lrz.de/fragen/faq/netz/netz10/).
Um die Ausfallsicherheit zu erhöhen, wurde der Secomat-Cluster räumlich aufgeteilt: 2 Nodes wurden in
den Erweiterungsbau des Rechnerwürfels migriert, während die restlichen 2 Nodes im alten Rechnerwürfel verblieben. Zusätzlich wurden die doppelt ausgelegten IP-Netze für die Cluster-Kommunikation physisch von den Administrations- und Strom-Management-Netzen getrennt.
14.4.2 Security Information & Event Management
Die Detektion sicherheitsrelevanter Ereignisse erfolgt weiterhin am zentralen Übergang aus dem MWN
ins X-WiN. Die dafür eingesetzte Sensorik umfasst zum einen ein signaturbasiertes Intrusion Detection
System (IDS) und parallel dazu ein Accounting-System. Der vom IDS verwendete Regelsatz wurde auch
2012 an die aktuelle Bedrohungslage angepasst und um Signaturen ergänzt, die neue Schadsoftware erkennt, die auf MWN-Systemen trotz regelmäßig durchgeführter Aktualisierung des Betriebssystems und
der Software installiert werden konnte. So zeigte sich 2012 ein deutlicher Anstieg der Infektionen mit
dem Trojanischen Pferd Zeus. Dieses verfolgt durch Kombination verschiedener Angriffstechniken das
Ziel, für den Nutzer unbemerkt in Online-Banking-Kommunikation einzugreifen, um dabei genutzte Zugangsdaten, PINs und TANs zu stehlen. Die anschließende missbräuchliche Verwendung dieser Daten hat
meist schlimme finanzielle Folgen für den Kontoinhaber. Die bewährte Identifikation Spam-versendender
Systeme und von Portscan- und Denial-of-Service-Angriffen aus dem MWN heraus funktionierte überaus
zuverlässig und ergänzte das nur auf bekannte Angriffe abzielende IDS um eine Anomalie-basierte Erkennung.
Die Auswertung und Korrelation der Ereignisse sowie die Alarmierung der zuständigen Netzverantwortlichen und Systemadministratoren erfolgte weiterhin durch das am LRZ seit einiger Zeit eingesetzte
Security Information & Event Management System (SIEM). Durch Event-Aggregation und Sensorübergreifende Korrelation von Alarmmeldungen konnte ein erster Verdacht zuverlässig erhärtet oder entkräftet werden. Die Anzahl fälschlicherweise gemeldeter Auffälligkeiten konnte dadurch auf nahezu Null
reduziert werden. Ein manuelles Eingreifen durch die LRZ-Abuse-Teammitglieder war nurmehr in wenigen Einzelfällen erforderlich, was auf die von der SIEM-Lösung angebotenen automatischen Reaktionsmöglichkeiten zurückzuführen war.
2012 wurde, um die Erkennungsraten der eingesetzen Mechanismen weiter zu erhöhen und die knappen
Systemressourcen noch effektiver zu nutzen, eine Bandbreitenmanagement-Lösung evaluiert. Zielsetzung
war weniger ein aktives Eingreifen in die Kommunikation und das Beschränken der Bandbreite bestimmter Applikationen, sondern vielmehr eine Klassifikation des MWN-Netzverkehrs. Grundsätzlich sollten
an dieser Stelle folgende Fragestellungen beantwortet werden:
 Welche Applikationen und Protokolle werden im Münchner Wissenschaftsnetz verwendet und
welchen prozentualen Anteil haben diese am Gesamtverkehrsaufkommen?
 Sind nennenswerte Unterschiede bei ein- und ausgehender Kommunikation erkennbar?
 Welche Netzbereiche besitzen monatlich das größte Verkehrsaufkommen? Sind die eingesetzten
Netzkomponenten ausreichend dimensioniert?
 Ließe sich die genutzte Bandbreite ausgewählter Applikationen zu bestimmten Zeiten begrenzen
oder nur nicht-verschlüsselter Traffic an das IDS weiterleiten?
 Können Applikationen selektiv priorisiert werden?
Als Ergebnisse lassen sich u.a. festhalten, dass die im Rahmen der Tests durchgeführte Klassifikation die
bisherige Vermutung des LRZ weitestgehend bestätigte. Streaming-Media und der Einsatz verschlüsselter
Protokolle nehmen einen beachtlichen Anteil des MWN-Netztraffics ein, was besonders die Erkennung
durch das IDS zunehmend erschweren wird. Desweitern würden sich die Reaktionsmöglichkeiten der
SIEM-Lösung sinnvoll erweitern lassen. So könnte eine länger anhaltende Übertragung größerer Datenmengen, welche sich oftmals negativ auf die übrigen Kommunikationsparteien auswirkt, durch gezielt
angestoßenes Traffic Shaping Bandbreiten-technisch reglementiert werden. Dennoch wird auf eine derart
aktive Regulierung durch Bandbreitenbegrenzung oder Priorisierung auch zukünftig im MWN verzichtet,
auch wenn diese mit dem evaluierten Produkt problemlos möglich wäre.
Die Einführung des IPv6-Protokolls im MWN ist in naher Zukunft weitestgehend abgeschlossen. Die
erwartete IPv6-Unterstützung der LRZ-SIEM-Lösung ist, trotz mehrfacher Zusage des Herstellers, nicht
vorhanden, so dass über einer Ersetzung nachgedacht werden muss. Diese soll neben einem um weitere
IT-Sicherheit
144
Sensoren ergänztes Event-Management, ein vollständig IPv6-fähiges Assetmanagement besitzen. Eine
performante Auswertungsmöglichkeiten auch für Netflow-basierte Ereignisdaten, sowie erweiterte Korrelations- und Auswertemöglichkeiten, sowie LRZ- und MWN-spezifische Reportingfunktionen sind wichtige zu erfüllende Anforderungen.
14.4.3 Nessi
Das über den im ID-Portal anwählbaren Menüpunkt „Dienste für Netzverantwortliche“ ist ein SelfService Portal für Netzverantwortliche. Netzverantworlichen wird es damit ermöglicht Informationen aus
ihrem Netzbereich abzufragen (z.B. Mac-Adressen, per DHCP vergebene Adressen). Einfache ServiceRequests können über dieses Portal an das LRZ verschickt werden. Das Portal wurde an die veränderte
Struktur (DHCP-Server etc.) angepasst, und soll in Zukunft weitere Funktionen erhalten.
Abbildung 86 Nessi Portal
14.4.4 Nyx
Das Sicherheits- und Netzmanagementwerkzeug Nyx, mit dem einzelne Rechner im MWN lokalisiert
werden können, liefert nach Eingabe einer bestimmten MAC- oder IP-Adresse den Switchport, an dem
der Rechner angeschlossen ist. Außerdem wird, falls hinterlegt, die Bezeichnung der Netzwerkdose ausgegeben, zu welcher diese Switchports gepatcht ist. Dies ist gerade auch im Hinblick auf das schnelle
Auffinden von Rechnern/Telefonen wichtig.
Nyx überprüft dabei ca. 1.300 (Vorjahr: 1.250) Switche und fragt ca. 2.030 (Vorjahr: 1.800) AccessPoints ab.
Die Endgeräteanzahl innerhalb des MWNs steigt weiterhin deutlich, ebenso die Anforderungen an die
Fähigkeiten dieses System. Bei der Bearbeitung von Missbrauchsfällen beispielsweise zum Auffinden
infizierter Rechner ist es sehr nützlich. Für administrative Zwecke (Powercycling via PoE) werden die
Daten aus Nyx ebenfalls verwendet.
145
14.5 Server- und Benutzerzertifizierung nach X.509
Das LRZ ist mit mehreren Zertifizierungs- und Registrierungsstellen (CAs und RAs) in die Zertifizierungshierarchien „Global“ und „Grid“ der Public-Key-Infrastruktur des Deutschen Forschungsnetzes
(DFN-PCA) eingebunden, deren Wurzelzertifikat von einer kommerziellen CA (T-TeleSec Trust Center
der Deutschen Telekom AG) beglaubigt wird.
Das LRZ betreibt im Rahmen dieser Hierarchien eine Zertifizierungsstelle (CA) mit zwei Registrierungsstellen (RA), eine RA für die Grid-CA der DFN-PCA sowie je eine RA für die CAs der beiden Münchner
Universitäten. Im Gegensatz zu den Vorjahren werden letztere nur noch dazu verwendet, Zerifikate für
solche Serverrechner auszustellen, die am LRZ selbst betrieben werden, insbesondere für Server für das
Webhosting. Die eigene CA deckt den Bereich der Bayerischen Akademie der Wissenschaften einschließlich des LRZ selbst sowie solcher Einrichtungen im Münchner Wissenschaftsnetz ab, die keine eigene CA
betreiben.
146
Arbeitsplätze
15 Arbeitsplätze
15.1 Windows
Für das Deployment und Management von Windows Desktop- und Serversystemen kommt am LRZ
Microsoft System Center Configuration Manager (SCCM) zum Einsatz.
Der SCCM ermöglicht ein Betriebssystemrollout als Bare-Metal Variante (auf einem leeren System) sowie als in-place Upgrade oder Neuinstallation über ein bereits vorhandenes System. Im letzteren Fall
werden dabei auch Einstellungen und Nutzdaten migriert. Des Weiteren ist es möglich, Software auf den
gemanagten Clients zu installieren,, aktualisieren oder deinstallieren. Ein integriertes Reporting gibt 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 gemanaged.
Ein wichtiges Ziel ist es, das Produkt 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 managen.
Software-Pakete, die sich bereits im Software Repository befinden, können jederzeit benutzt werden entsprechende Lizenzierung durch den Kunden vorausgesetzt. Software, die im Repository nicht vorhanden ist (in der Regel Spezialsoftware von Fakultäten), wird für den Kunden paketiert und nach Aufwand
in Rechnung gestellt. Das LRZ übernimmt bei gemanagten PCs zudem die Aktualisierung von Standardsoftware, die aus Sicherheitsgründen aktualisiert werden muss (z.B. Java, Mozilla Firefox, Adobe Flash).
Um das verfügbare Software Repository stets aktuell zu halten und an den Bedürfnissen der Nutzer auszurichten, wurden im vergangenen Jahr fortlaufend Software-Pakete aktualisiert sowie neue Software in
das Repository eingepflegt. Dabei wurden die Methoden weiter verfeinert und die Reaktionszeiten bei
den Paketen mit hohen Updatezyklen und hoher Sicherheitsrelevanz wie Java, Firefox oder Flash Player
weiter deutlich verbessert und effizienter gestaltet.
Insgesamt stehen derzeit über 400 Software-Pakete aus den unterschiedlichsten Anwendungsbereichen
(Office, Internet, Architektur, Musik, Biologie, Wirtschaft, uvm.) für die Verteilung zur Verfügung. Unterstützt werden alle aktuellen Windows Betriebssysteme. Insgesamt, d.h. MWN-weit, werden vom System Center Configuration Manager 757 (698) Client-Systeme und 125 Serversystem verwaltet.
In 2012 fand der Upgrade der Umgebung auf die neue Version SCCM 2012 statt. Vor allem in die Umstellung der Pakete und Tasksequenzen musste dieses Jahr sehr viel Zeit investiert werden. Die bei der
neuen Version erhofften Verbesserungen der Mandantenfähigkeit bei der neuen Version haben sich leider
nur zum Teil erfüllt.
15.2 Linux-Mitarbeiter-PCs
Schwerpunkt des Jahres 2012 war die Aktualisierung des Betriebssystems auf den etwa 60 vorhandenen
Linux-Arbeitsplatz-Systemen. Die Version „openSUSE 11.3“ wurde auf „openSUSE 12.1“ angehoben.
Zur Optimierung und Verschlankung der Partitionstabellen wurde jeweils eine Neuinstallation durchgeführt. Individuelle Daten konnten vor dem Formatieren per NFS gesichert und nach Abschluss der Installation zurückkopiert werden.
Neben der Installation auf physischer Hardware wird auch der Betrieb von „openSUSE 12.1“ als lokale,
virtuelle Maschine (VM) mittels Hypervisor von VirtualBox, VMware-Player o.Ä. unterstützt. Bei Laptops, deren Hardwarefunktionalität für Windows-Betriebssysteme optimiert ist, ist der Einsatz von Linux
als VM obligatorisch. Dies verringert aufwändigere Anpassungsarbeiten, zumal bei Vorhandensein vielfältiger Laptop-Modelle.
15.3 Rechnerpools und Spezialarbeitsplätze
Die PC-Gruppe hat unterschiedliche Modelle für die Bereitstellung von aktuellen WindowsArbeitsplätzen für verschiedene Kundengruppen entwickelt. Die Lösungen reichen dabei vom vollwerti-
147
gen Mitarbeiterarbeitsplatz über Terminalserverlösungen für Mitarbeiter bis zum virtuellen Desktop für
Testzwecke. Für Studenten werden sowohl vollwertige Rechnerpools als auch auf Terminalserverlösungen basierende Pools angeboten. Diese „Fullmanaged Desktops“ werden vom LRZ von der OS Installation, über die Softwarepflege bis zum Monitoring betreut. Bei den vom LRZ betreuten Systemen an der
BAdW, TUM, LMU oder HMT wird der First Level Support von Vorortbetreuern der jeweiligen Mandanten wahr genommen, die bei Problemen oder Änderungswünschen als Ansprechpartner zum LRZ
agieren.
Im Rahmen des MWN-AD wird der „Light-Desktop/Server“ angeboten, bei dem Institutionen im MWN
Rechner in die Infrastruktur integrieren können und so die Vorteile des zentral gepflegten MWN-AD für
das Desktopmanagement mitnutzen können, ohne selbst eine Infrastruktur betreiben zu müssen. Die
komplette Administration der integrierten Light-Desktop/Server obliegt dabei aber den lokalen Administratoren der jeweiligen Institutionen.
Die verschiedenen Rechnergruppen setzen sich zahlenmäßig Ende 2012 wie in Tabelle 20 zusammen
(Vorjahreszahlen in Klammern):
Light Desktop/Server
LRZ
Pool und Kurs
86
51 (51)
BAdW
Fullmanaged Desktop
177 (182)
216 (198)
TUM
3.597 (2.402)
154 (128)
LMU
402 (395)
20 (35)
HMT
46 (57)
BVB
4 (5)
Summen
4.089 (2.802)
271 (271)
393 (380)
Tabelle 20: Clients im MWN-AD
Bei den Kunden für den Remote Desktop Management Service in der ADS/LRZ-Domäne fanden in 2012
einige Umrüstungen statt:
-
BAdW:
o laufende Modernisierung der Hard- und Softwareausstattungen
-
LRZ:
o
o
o
o
o
o
o
laufende Modernisierung der Hard- und Softwareausstattungen
Ersetzung der Leitwarte mit Thin-Clients
Modernisierung der CD-Brennstationen
Mac-Authentifizierung für Leitwarte und Pool-Rechner
Info-Display in der Hotline
Umbau der Netze für Gebäudemanagement
Aufbau einer zentralen Passwortverwaltung
-
HMT (Hochschule für Musik und Theater)
o Umstellung der letzten Pools auf Windows 7
-
TUZE (TUM – Zentrale Einrichtungen)
o Neuaufbau eines Pools mit 40 Clients
-
TUSP (TUM-Sport)
o Neuaufbau eines Pools mit 30 Clients
Arbeitsplätze
148
o
-
Umstellung des bestehenden Pools auf Windows 7
TUPH (TUM-Physik)
o Übernahme des Betriebs der Terminalserver für Studenten an der Fakultät
Auch im Jahr 2012 wurden viele Stunden für Kundenberatung erbracht, um das Angebot des zentralen
Speichers und des Light-Desktop/Server vorzustellen.
In 2012 wurden die bisherigen Datei-Ablagen von BAdW und LRZ auf dem gfiler.lrz-muenchen in den
MWN-Speicher umgezogen. Dazu mussten Projektablagen und persönliche Verzeichnisse migriert werden. Mitte des Jahres erfolgte dann ein Umzug des MWN-Speichers auf neue, physische Systeme der
Firma NetApp.
Kurzfristig musste zum Ende des Jahres 2012 der Datenbereich der Fakultät F11 der LMU mit über 10
TB und rund 4.000 persönlichen Verzeichnissen auf den neuen MWN-Speicher migriert werden.
Die in die Jahre gekommene und recht instabile Eigenentwicklung Webdisk um den MWN-Speicher auch
über einen Browser zugänglich zu machen, wurde durch ein kommerzielles Produkt Http Commander
von der Firma ElementIT ersetzt. Die neue zeitgemäße Oberfläche und die zusätzliche Möglichkeit nun
auch über WebDAV zugreifen zu können, fanden im MWN große Akzeptanz.
149
16 Interna
16.1 Personal
16.1.1 Personalausstattung
Die Anzahl der Mitarbeiter im LRZ ist im Jahre 2012 aufgrund weiterer Drittmittelprojekte (EU- und
BMBF-Projekte) weiter gestiegen. Aufgrund der weiterhin guten Konjunkturlage im IT-Bereich konnten
offene Stellen jedoch teilweise gar nicht bzw. erst nach mehrfachen Ausschreibungen erfolgreich besetzt
werden. So waren Ende 2012 am LRZ 157 Mitarbeiter und 39 wissenschaftliche und studentische Hilfskräfte beschäftigt. 2012 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 bereits kurze Zeit danach eine Anstellung in der Industrie annehmen.
16.1.2 Personalveränderungen 2012
Im Jahre 2012 waren insgesamt 43 Zugänge und 30 Abgänge zu verzeichnen. Es wurden 23 wissenschaftliche Mitarbeiter, 13 studentische Hilfskräfte, drei technische Angestellte, zwei Auszubildende sowie ein
Verwaltungsangestellter und ein Kommunikationselektroniker neu am LRZ eingestellt. Acht wissenschaftliche Mitarbeiter, 16 studentische Hilfskräfte, zwei technische Angestellte, zwei Auszubildende
nach erfolgreicher Ausbildung und zwei Verwaltungsangestellte verließen das LRZ und nahmen eine
neue Beschäftigung an. Darüber hinaus traten drei wissenschaftliche Mitarbeiter sowie ein technischer
Angestellter und ein Kommunikationselektroniker ihre Ruhephase in der Altersteilzeit an.
16.2 Gebäude und Infrastruktur
16.2.1 Gebäudemanagement
Die Infrastruktur an Elektrizität und Kühlung als wichtigste Aufgabe des Infrastrukturmanagements konnte mit großem Einsatz stabil betrieben werden. Vor allem noch immer ausstehende Restleistungen und
Mängel im Erweiterungsgebäude, das Mitte 2011 übergeben worden war, bergen latent Risiken für den
Rechenzentrumsbetrieb.
Die wichtigste Leistung des Jahres 2012 stellte die erfolgreiche Einbettung des neuen Höchstleistungsrechners SuperMUC in die LRZ-Infrastruktur dar. Dazu musste eigens ein innovatives Kühlsystem aus
deionisiertem Wasser im SuperMUC-Bereich installiert werden.
Im Einzelnen gab es sehr viel Arbeit mit Restleistungen und Mängeln aus dem Bauabschnitt 2 (Erweiterungsbau) aus den Jahren 2009-2011. Hier sind v.a. zu nennen
 Gebäudeleittechnik (GLT)
Dieses Gewerk hat für Überwachung und Steuerung der technischen Gebäudeausrüstung rund um
die Uhr zentrale Bedeutung. Die GLT befand sich indes auch mehr als ein Jahr nach Übergabe
des Erweiterungsbaues (Aug. 2011) noch in einem so beklagenswerten Zustand, dass die Überwachungsaufgaben nur durch Botengänge und vor-Ort-Beobachtungen der Hauswerkstätte wahrgenommen werden konnten. Leider konnten dadurch auch Fehler und Schwächen anderer Gewerke erst spät entdeckt und behoben werden. Dieser Prozess ist auch zum Jahresende 2012 noch
nicht abgeschlossen.
 Kühlturmbetrieb
Bei den neuen Rückkühlwerken auf dem Dach zeigte sich erst spät - verschleppt u.a. durch die
mangelhaft funktionierende Leittechnik - wie komplex und anpassungsbedürftig ihr Betrieb war.
Dies führte über längere Zeit zu einem erhöhten Verbrauch von teurem Umkehrosmosewasser,
weil die Regelung für das Abschlämmen des mit Verdunstungsrückständen befrachteten Abwassers nicht funktionierte.
 Wasseraufbereitung / Umkehrosmose
150
Interna
Der für die Leistungsfähigkeit der Kühltürme entscheidende sog. „Benetzungsbetrieb“ mit Umkehrosmosewasser konnte aufgrund von Durchsatzproblemen und von Fehlsteuerungen der Wasseraufbereitung erst spät im Jahr so betrieben werden, dass Schäden durch Benetzungswasserrückstände einigermaßen sicher vermieden werden können.
 Hydraulik der Wasserkühlsysteme
Die Verzweigtheit der Rohrnetze und der sehr ungleichmäßige Kältebedarf des LRZ führt v.a. im
Warmwasserkühlbereich zu hydraulischen Problemen: sie äußern sich in ungewollten „Kurzschlüssen“ und beträchtlichen Ineffizienzen in den Entsorgungspfaden für die Rechnerabwärme.
Hier sind größere Anpassungen notwendig. Dieser Prozess wird sich noch deutlich ins Jahr 2013
hinein ziehen.
 Kommunikationshindernisse zwischen Lüftung und Steuerung
Die ausführenden Firmen insbesondere der Lüftungstechnik sahen sich außerstande bzw. waren
nicht bereit, die dringend benötigte Kompetenz ihrer Subunternehmer einzuschalten, deren Geräte
sie zugekauft haben.
Das LRZ erprobt hier erstmalig eine neue Kühlungsinfrastruktur, die zu massiven Einsparungen bzgl. der
Energie führen. Diese „Pionierfunktion“ führt allerdings dazu, dass nicht von Beginn der Inbetriebnahme
ein voll erprobtes Gesamtsystem vorhanden ist. Die genannten Probleme wurden in Dringlichkeitssitzungen mit dem Bauamt und den wesentlichen beteiligten Firmen eskaliert. Durch die Einrichtung von regelmäßigen wöchentlichen Sitzungen wurden wesentliche Fortschritte erzielt, ebenso durch die personelle
Erweiterung des Teams des LRZ durch einen erfahrenen Mitarbeiter.
16.2.2 Energieeffizienz
Das LRZ erhielt im März 2012 den deutschen Rechenzentrumspreis in der Kategorie "Energie- und Ressourceneffiziente Rechenzentren". In seiner Bewerbung "Höchstleistungsrechnen – höchst effizient!"
hatte das LRZ die weltweit einzigartige Energieeffizienz seines neuen Höchstleistungsrechners SuperMUC herausgestellt. Durch die innovative Kühlung des Systems mit warmem Wasser ist es möglich, den
Großteil der Rechnerkomponenten ganzjährig ohne den Einsatz von Kältemaschinen zu kühlen. Die effiziente Ausnutzung der Energiesparmechanismen neuester Prozessortechnologien erlaubt zudem die
gleichzeitige Optimierung der Rechnerperformance für Geschwindigkeit und Energie. Auch auf diesem
Gebiet ist das LRZ Pionier.
Trotz dieser Auszeichnung mussten aufgrund fehlender Personalkapazitäten (sowohl beim LRZ wie auch
bei den beteiligten Firmen) und den oben beschriebenen Problemen bei der Mängelbeseitigung des Erweiterungsbaus geplante Tätigkeiten zur weiteren Optimierung auf das Jahr 2013 verschoben werden, da vor
allem zuerst der geplante Funktionsumfang der Gebäudeinfrastruktur zuverlässig betriebsfähig gestaltet
werden muss. Erst danach bleibt Raum für dringend naheliegende Optimierungen in der Betriebsweise
der Stromversorgungs- und Kühlungsaggregate.
16.3 Das LRZ als Ausbildungsbetrieb
Seit 2007 ist das LRZ als Ausbildungsbetrieb anerkannt und bietet Ausbildungsplätze für IT-SystemElektroniker und Fachinformatiker Systemintegration an. Die Ausbildung geschieht abteilungsübergreifend und wird von Herrn Reiser (als verantwortlicher Ausbilder), Herrn Benen (Vertreter), Herrn Häfele,
Herrn Neumann und Herrn Niedermeier koordiniert. Im Ausbildungsjahr 2012/2013 wurden wieder zwei
Auszubildende (ein IT-System-Elektroniker und ein Fachinformatiker der Richtung Systemintegration)
am LRZ eingestellt, die Bewerberauswahl wurde Ende 2011 erstmals eigenständig im LRZ durchgeführt.
Zwei Auszubildende konnten ihre Ausbildung erfolgreich abschließen und bereits kurze Zeit danach eine
Anstellung in der Industrie annehmen. Auch für das Ausbildungsjahr 2013/2014 ist geplant, wieder zwei
Auszubildende einzustellen.
Die Verstetigung der Ausbildung im Haushaltsansatz für den Doppelhaushalt 2013/2014 war leider nicht
erfolgreich. Es wurden hierfür leider keine entsprechenden Mittelansätze genehmigt.
151
16.4 Dienstleistungskatalog
Der Wunsch anderer Hochschulen und wissenschaftsnahen Institutionen (Fachhochschulen, Bibliotheken,
Max-Planck-Institute, Studentenwerk usw.) IT-Dienste des LRZ für sie zu betreiben und zu betreuen (ITOutsourcing) hat sich auch 2012 weiter verstärkt. Das LRZ hatte schon Ende 2008 eine erste Version
eines Dienstleistungskatalogs in Absprache mit seinem zuständigen Ministerium (Bayerisches Staatsministerium für Wissenschaft, Forschung und Kunst) erstellt, der im ersten Schritt nur diejenigen Dienste
enthalten hatte, die bisher für andere Institutionen schon betrieben bzw. von anderen Institutionen aktiv
nachgefragt wurden. Langfristig soll dieser Dienstleistungskatalog alle Dienstleistungen des LRZ umfassen, also auch diejenigen, die bisher und auch in Zukunft für Nutzer (im engeren Sinne) kostenlos sind, da
sie der satzungsgemäßen Grundversorgung zugerechnet werden. Eine erste Auflistung hierzu findet sich
in der Schrift „Das Leibniz-Rechenzentrum (LRZ) – eine Einführung“, die 2012 in einer neuen Auflage
und einer einheitlichen Strukturierung nach dem Dienstleistungsbaum erschienen ist. Diese Schrift hatte
2010 den bisher im Jahresbericht enthaltenen Teil über die Dienstleistungen des Leibniz-Rechenzentrums
ersetzt und wird auch zukünftig regelmäßig den aktuellen Gegebenheiten angepasst werden.
Teil dieses Dienstkatalogs ist auch eine aktualisierte Klasseneinteilung möglicher Nutzer/Kunden. Anhand dieser Einteilung werden die Antragsteller klassifiziert und die für die Dienstleistung anzusetzenden
Kosten berechnet. Dieser Entscheidungsprozess erfolgt in enger Abstimmung mit der Bayerischen Akademie der Wissenschaften und unserem Ministerium.
Im letzten Jahr wurden zusätzlich zu den schon in den Vorjahren erbrachten Dienstleistungen weitere
Dienste für die Hochschulen und die Bayerische Staatsbibliothek insbesondere aus dem Bereich Hosting
virtueller Server, Online-Speicher und Archiv- und Backupservice erbracht.
16.5 Management-Tools, Dokumentation und Dienstleistungsbaum
2009 wurde im Zuge eines Projektes zur Konsolidierung der Management-Tools ein Arbeitskreis für
Informationsmanagement gegründet. Um sowohl die Management-Tools wie auch die administrativen
Abläufe am LRZ auf eine konsolidierte und fundierte Informationsbasis zu stellen, hat es sich der Arbeitskreis zur Aufgabe gemacht, das Management der Informationen, im Speziellen der Dokumentationen
zu verbessern. 2012 wurden wichtige Maßnahmen, die bereits 2011 initiiert wurden, konsequent fortgeführt. Der sogenannte Dienstleistungsbaum gliedert die Aufgabenbereiche des LRZ systematisch nach
dem Dienstangebot. Diese Struktur wurde kontinuierlich weiter auf verschiedene Informationsquellen am
LRZ ausgerollt und etabliert. In regelmäßigen Intervallen wurde der Dienstleistungsbaum auch überarbeitet und an das sich ändernde Dienstleistungsportfolio des LRZ angepasst. Eine klare und intuitive Strukturierung des Serviceangebots und ein verbesserter Wiedererkennungswert sind hierbei große Vorteile für
die Kunden des LRZ.
Auch in der internen Gestaltung der Informationslandschaft wurde 2012 ein wichtiger Meilenstein erreicht. Um die unterschiedlichen Informationsquellen der einzelnen Projekt-Teams, Gruppen und Abteilungen für die Dokumentenablage konsolidieren zu können, wurde ein zentrales „LRZ-Wiki“ eingeführt.
Durch diese Einführung konnte eine Vielzahl zuvor dezentral administrierter Wikis durch ein zentral gepflegtes Wiki abgelöst werden. Ein wichtiger Baustein für die Verbesserung der abteilungsübergreifenden
Informationsstrukturen ist damit gelegt. Weitere Planungen für die Konsolidierung anderer dezentral
verwalteter Daten konnten nun angegangen werden. Die Planung und Umsetzung hierfür wird auch 2013
noch eine zentrale Aufgabe für den Arbeitskreis für Informationsmanagement sein.
16.6 Mitarbeit in Gremien








BRZL: Arbeitskreis der bayerischen Rechenzentrumsleiter
ZKI: Zentren für Kommunikation und Information
ZKI-Arbeitskreis Universitäts- und Fachhochschul-Rechenzentren
MPG: Beratender Ausschuss für Rechensysteme
MPG: Kuratorium der Institute für Extraterrestrik und Astrophysik
DFN: Diverse Gremien und Ausschüsse
DFG-Gutachtersitzungen
IFIP/IEEE: Diverse Working Groups, Program and Organization Committees
Interna
152
















IT-Beirat fuer das Bibliothekswesen Bayerns (Bayerische Universitäts- und Fachhochschulbibliotheken), ehemals: Kommission für EDV-Planung
Arbeitsgruppe IT-Strategie für die staatlichen Museen und Sammlungen in Bayern
Beirat zur Implementierung der Langzeitarchivierungssoftware „Rosetta Digital Preservation
System“ im Bibliotheksverbund Bayern
D-Grid Beirat
EGI Management Board
DGI-2 Leitungsgremium
NGI/DE : nationale Koordination der Entwicklungsaktivitäten für eine europäische GridInfrastruktur)
Gauss Centre for Supercomputing (GCS)
Gauß Allianz
PRACE Management Board
ETP4HPC (European Technology Platform for High Performance Computing) Founding Fathers
Board
PRACE Council
PROSPECT Board
EOFS Administrative Council
OGF GLUE Working Group
GEG (Géant Expert Group)
16.6.1 Abteilung „Benutzernahe Dienste und Systeme“







ZKI-Arbeitskreis Verzeichnisdienste
ZKI-Arbeitskreis Multimedia und Grafik
ZKI-Arbeitskreis Verteilte Systeme
Regionale DOAG-Arbeitsgruppe München (Deutsche Oracle Anwendergemeinde)
Arbeitskreis vernetzter Arbeitsplatzrechner (AKNetzPC)
Bayerischer Arbeitskreis Identity Management
(vormals Bayerischer Arbeitskreis Metadirectory und Arbeitskreis AAI)
DFN-Arbeitsgruppe E-Learning
16.6.2 Abteilung „Hochleistungssysteme“












ZKI-Arbeitskreis Supercomputing
KONWIHR (Kompetenznetzwerk für Technisch-Wissenschaftliches Hoch- und Höchstleistungsrechnen in Bayern)
UNICORE Forum (UNICORE User Group)
IBM SPXX-L User Group for Large IBM Installations
IBM SciCom HPC Systems Scientific Computing User GroupD-Grid Technical Advisory Board
(TAB)
OGF Production Grid Interoperability (PGI) working group
NGI-DE Joint Research Unit (JRU)
Münchner Arbeitskreis Langzeitarchivierung
Fortran Standardisierung (International Organization for Standardization (ISO) and the
International Electrotechnical Commission (IEC) through their Joint Technical Committee 1
(JTC1), International Standardization Subcommittee for programming languages (SC22),
Working Group 5 Fortran)
STRATOS (PRACE Advisory Group for Strategic Technologies)
IESP (International Exascale Software Project)
EESI2 (European Exascale Software Initiative 2)















153
ETP4HPC Strategic Research Agenda (SRA) Working Group
PRACE-1IP Technical Board
PRACE-2IP Executive Board
EEHPCWG (Energy Efficient HPC Working Group)
ScalaLife Executive Board
ScalaLife Project Management Board
Autotune Management Board
EGI Technology Coordination Board (TCB)
EGI CF12 Programme Committee
IGE Project Management Team (PMT)
IGE Steering Committee
IGE Technical Board
VERCE Steering Committee
VERCE Technical Board
e-IRGSP3 Project Management Board
16.6.3 Abteilung „Kommunikationsnetze“



















BHN (Bayerisches Hochschulnetz)
IT-Beirat der Staatlichen Museen und Sammlungen
ZKI-Arbeitskreis Netzdienste
ZKI-Kommission "Eduroam off Campus"
DFN-Betriebsausschuss
Projektgruppe Datenverkabelung (öffentlicher Gebäude in Bayern)
Arbeitsgruppe "Voice over IP Strategie" für bayerische Dienststellen (Leitung STMF)
Arbeitskreis IT Service Management in Hochschulen
IT Service Management Forum itSMF
TÜV Komitee Personenzertifizierung nach ISO/IEC 20000
TÜV Komitee Personenzertifizierung nach ISO/IEC 27000
DFN Forum Kommunikationstechnologien 2012
19. DFN-Workshop Sicherheit in vernetzten Systemen (2012)
International Conference on Resource Intensive Applications and Services (INTENSIVE 2012)
IEEE/IFIP International Symposium on Integrated Network Management (IM 2013)
7th International Conference on Autonomous Infrastructure, Management and Security (AIMS
2013)
IEEE GlobeCom 2012 (GC’12) - Symposium on Communication and Information Systems
Security (CISS 2012)
DMTF Academic Alliance Workshop on Systems and Virtualization Management (SVM’12)
International Conference on Advanced Communications and Computation (INFOCOMP 2012)
16.6.4 Abteilung „Zentrale Dienste“


ZKI-Arbeitskreis Softwarelizenzen
BSK-Arbeitskreis (Bayerische Software-Kooperation)
Interna
154
16.7 Veranstaltungen am LRZ
Titel
Datum
ZKI, Eduroam of Campus
10.01.2012
CUDA Kurs
16.01. - 18.01.2012
IGE Advisory Board Meeting
31.01.2012
DFN Informationsveranstaltung „VideoConferencing“
01.02.2012
EOFS-Meeting
07.02. – 08.02.2012
ExaScale I/O Workshop
07.02. – 08.02.2012
NGI-DE Beiratssitzung
13.02.2012
PDP Workshop
15.02. - 17.02.2012
Besuch ZiH Dresden Baudelegation
20.02.2012
ASCETE Kickoff Meeting
24.02.2012
Scalalife Winterschool
27.02. – 02.03.2012
Kompaktkurs: Parallel Programming of High Performance Systems
05.03. – 09.03.2012
OCIP Workshop 2012
12.03.- 14.03.2012
ETP Steering Board Meeting
12.03.2012
PROSPECT Meeting
13.03.2012
Thementag SOPHOS Endpoint Security
15.03.2012
EGI Community Forum 2012
26.03. – 30.03.2012
Ferienprogramm Stadtjugendamt München
04.04.2012
ieT User Group Treffen
16.04.2012
ITSM Airport Simulation für Hochschule München
20.04.2012
Girls Day 2012
26.04.2012
DEEP All Hands Meeting
08.05. – 09.05.2012
BGCE Research Day
10.05.2012
Symposium Forum Technologie der BAdW
11.05.2012
Sitzung der Evaluationskommission der BAdW
11.05.2012
Scalalife EAC Board Meeting
15.05.2012
GEPOM Workshop
15.06.2012
LabView Anwendertreffen
18.06.2012
GIDS Projekttreffen
25.06. – 27.06.2012
ISPDC 2012
11th Intern. Symposium on Parallel and Distributed Computing
25.06. – 29.06.2012
DRIHM Meeting
17.07. – 18.07.2012
Einweihungsfeier SuperMUC und 50 Jahre LRZ
20.07.2012
Gauss Allianz Mitgliederversammlung
20.07.2012
Sitzung des Bayerischen Arbeitskreises Metadirectory und AAI
25.07.2012
155
PRACE PCP Meeting
08.08.2012
Kompaktkurs: Iterative Linear Solvers and Parallelisation
10.09. – 14.09.2012
TUM Workshop Numerik
17.09. – 18.09.2012
DRIHM Meeting
18.09. – 19.09.2012
Kompaktkurs: Advances Topics with Fortran
17.09. – 21.09.2012
ieT User Group Treffen
01.10.2012
LabView Anwendertreffen
04.10.2012
ISO 20000 Kurs - Airport Simulation
08.10. – 09.10.2012
Tag der offenen Tür am Campus Garching
27.10.2012
DRIHM Meeting
08.10. – 12.10.2012
IBM Veranstaltung X-Series (Mittelstandskunden)
11.10.2012
10th VI-HPS Tuning Workshop
15.10. - 19.10.2012
Besuch einer chinesischen Delegation
19.10.2012
Adobe Roadshow
22.10.2012
Festakt: Eröffnung V2C
25.10.2012
Maplesoft Seminar "Mathematics and Modeling with Maple and MapleS- 26.10.2012
im"
Tag der offenen Tür am Campus Garching
27.10.2012
DRIHM 2 US Kickoff Meeting
09.11.2012
HP Networking Technology Day
14.11.2012
Storage Consortium Anwenderkonferenz
15.11.2012
GCS Steuerkreissitzung
20.11.2012
Abschlussfeier Elitestudiengang Wirtschaftsinformatik
30.11.2012
Node-Level Performance Engineering
06.12. – 07.12.2012
Interna
156
16.8 Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen
16.8.1 Abteilung „Benutzernahe Dienste und Systeme“























Workshop Konnektivität der Hochschulen zur vhb
26.01.2012 Hochschule München (Ebner)
AK NetzPC Thementage Sophos
08.02.2012 Würzburg (Schreiner)
Storage AK NetzPC; Treffen BSK Novell Landeslizenzvertrag
15.02.2012 - 16.02.2012 Regensburg (Hartmannsgruber)
ZKI Arbeitskreise Verzeichnisdienste und Campus Management
07.03.2012 - 08.03.2012 Halle (Ebner)
Preisverhandlungen in Rahmen der Beschaffungsverträge für Monitore, Notebooks und Desktops
14.03.2012 Regensburg (Hartmannsgruber)
Diskussion zum Thema "Microsoft Support Vertrag Bayern"
30.03.2012 Kempten (Hartmannsgruber)
Sitzung des AK NetzPC GroupWise Tag
Apple Mac OS X Support Essential 10.7
07.05.2012 - 09.05.2012 Erlangen (Gillmeister)
Workshop AD Grundlagen
15.05.2012 - 16.05.2012 Würzburg (Hollermeier)
Hochverfügbarkeitslösungen auf Basis von MySQL
23.05.2012 München (Nickl)
Ausschreibung Notebook/ Desktop
Workshop AD Fortgeschrittene
02.07.2012 - 03.07.2012 Augsburg (Hollermeier)
VRAR 2012
19.09.2012 - 20.09.2012 Düsseldorf (Anthes)
ZKI Arbeitskreis Verzeichnisdienste
08.10.2012 - 09.10.2012 Würzburg (Ebner)
VM World Konferenz 2012
08.10.2012 - 11.10.2012 Barcelona (SP) (Gillmeister)
AK Netz PC
11.10.2012 Amberg (Niedermeier)
Security Vorträge an Schulen
26.10.2012 Ingolstadt (Bötsch)
Workshop Windows Server 2012; Treffen der AG Novell Landeslizenz
29.10.2012 - 31.10.2012 Regensburg (Hartmannsgruber)
Workshop Windows Server 2012
29.10.2012 - 30.10.2012 Regensburg (Fakler)
International Supercomputing Conference 2012
10.11.2012 - 22.11.2012 Salt Lake City (USA)/Ho Chi Minh (Vietnam) (Anthes)
DV-Fachseminar
21.11.2012 - 28.11.2012 Stade (Oesmann)
Gastvortrag Identity Management
13.12.2012 Kempten (Ebner)
Vertragsverhandlungen zum Novell-Landeslizenzvertrag
19.12.2012 Nürnberg (Hartmannsgruber)
16.8.2 Abteilung „Hochleistungssysteme”



























Peer review meeting
16.01.2012 - 17.01.2012 Brüssel -BE (Brehm)
PRACE 2IP WP 11 Meeting
17.01.2012 - 18.01.2012 Brüssel -BE (Christadler)
ETP Steering Board Meeting
19.01.2012 - 20.01.2012 Rom -IT (Huber)
Projekttreffen DGSI
23.01.2012 - 24.01.2012 Göttingen (Paisios)
DEEP-Projektmeeting
23.01.2012 Regensburg (Auweter, Huber)
Face-to-Face working group KPIs
25.01.2012 - 26.01.2012 Amsterdam -NL (Saverchenko)
PRACE 1IP und 2IP MB Meeting
27.01.2012Frankfurt am Main (Christadler)
PRACE 1IP WP9 und 2IP WP11 Meeting
13.02.2012 - 16.02.2012 Stockholm -SE (Auweter, Christadler)
PRACE 2IP WP 11 Meeting
13.02.2012 - 16.02.2012 Stockholm -SE (Wilde)
Thementage Storage
15.02.2012 Regensburg (Reiner)
Dissemination Workshop Development of impact measures for e-infrastructures
20.02.2012 Brüssel -BE (Straube)
Projekttreffen SLA4 D-Grid
22.02.2012 - 23.02.2012 Göttingen (Paisios)
High Performance Computing Workshop
26.02.2012 - 01.03.2012 Leogang -AT (Auweter)
Standbetreuung CeBIT
05.03.2012 - 11.03.2012 Hannover (Kemmler, Weinberg)
Parallel programming of high performance systems (eigener Vortrag)
05.03.2012 Erlangen (Guillen)
Kurs "Parallel programming of high performance systems"
05.03.2012 - 08.03.2012 Erlangen (Bader)
Vortrag bei IBM über SuperMUC im Rahmen der CeBIT
06.03.2012 - 07.03.2012 Hannover (Huber)
DEEP-Projektmeeting WP7
19.03.2012 Regensburg (Auweter, Huber)
D-Grid Ergebniskonferenz
19.03.2012 - 21.03.2012 Bonn (Paisios)
e-IRGSP3 Delegates Meeting; ICRI 2012
20.03.2012 - 23.03.2012 Kopenhagen -DK (Frank)
EGI Community Forum Spring 2012 (Techn. Conference)
26.03.2012 - 30.03.2012 München (Frank)
9th Intel EMEA HPC Roundtable Meeting; Face-to-Face Meeting WP7
27.03.2012 - 30.03.2012 Paris –FR / Stockholm -SE (Weinberg)
Face-to-Face Meeting WP 7
28.03.2012 - 30.03.2012 Stockholm -SE (Block, Christadler)
Future Thinking Konferenz 2012 - Preisverleihung Rechenzentrumspreis
29.03.2012 - 30.03.2012 Sinsheim (Auweter)
EC Review PRACE prototypes
29.03.2012 - 30.03.2012 Brüssel -BE (Wilde)
PRACE 1 IP Prototype Evaluation and Future Technologies (WP9)
10.04.2012 - 13.04.2012 Daresbury -UK (Christadler, Wilde)
MONT-BLANC Face-to-Face Meeting
157
Interna
158



























11.04.2012 - 13.04.2012 Barcelona -ES (Auweter)
PRACE 1IP WP6 und PRACE 2IP WP6+WP10 all Hands Meeting
11.04.2012 - 13.04.2012 Bologna -IT (Saverchenko)
NA2/JRA 1/JRA2 Meeting
11.04.2012 - 13.04.2012 Rom -IT (Leong)
MONT-BLANC Face-to-Face Meeting
11.04.2012 - 13.04.2012 Barcelona -ES (Allalen)
PRACE 1 IP WP6 und PRACE 2IP WP6-WP10 all Hands meeting
11.04.2012 - 13.04.2012 Bologna -IT (Lanati)
Invitation to the 4th PRACE Executive Industrial Seminar
15.04.2012 - 17.04.2012 Bologna -IT (Wilde)
IGE All-Hands Meeting
17.04.2012 - 20.04.2012 Uppsala -SE (Frank, Paisios, Rössle-Blank)
PRACE Priorisation Panel
18.04.2012 - 19.04.2012 Brüssel -BE (Brehm)
NGI-DE Jahrestagung: Ein neues Betriebskonzept für das Grid in Deutschland
18.04.2012 - 19.04.2012 Karlsruhe (Eißler, Saverchenko, Waldmann)
ZKI AK Supercomputing Frühjahr 2012 (eigener Vortrag)
19.04.2012 - 20.04.2012 Karlsruhe (Weinberg)
HPC Lösungen für ANSYS mechanical 14.0
19.04.2012 Böblingen (Block)
TCB 11
23.04.2012 - 24.04.2012 Amsterdam -NL (Heller)
Seminar IBM Tivoli Storage Manager Client Functions
23.04.2012 - 25.04.2012 Stuttgart (Hoferer, Neumann)
VERCE Face-to-Face Meeting
02.05.2012 - 04.05.2012 Paris -FR (Frank, Leong)
HLRS Workshop on Scalable Global Parallel File Systems
07.05.2012 - 09.05.2012 Stuttgart (Otte)
ETP4HPC Steering Board Meeting
10.05.2012 Paris -FR (Huber)
ACM International Conference (eigener Vortrag)
15.05.2012 - 17.05.2012 Cagliari -IT (Auweter)
Informationsveranstaltung: Aktuelle Fördermöglichkeiten im 7. Forschungsprogramm der EU für
Informations- und Kommunikationstechnologien
24.05.2012 München (Frank)
VERCE Project Rehearsal and Project Review
07.06.2012 - 08.06.2012 Brüssel -BE (Frank)
PRACE 2IP WP 8 Face-to-Face Meeting
11.06.2012 - 13.06.2012 Paris -FR (Wilde)
e-IRGSP3 Workshop; Closes e-IRG Delegates Meeting
11.06.2012 - 13.06.2012 Kopenhagen -DK (Frank, Straube)
DEEP Rehearsal and Review Meeting
11.06.2012 - 12.06.2012 Brüssel -BE (Auweter)
Intel Many Integrated Core Advanced-Workshop
13.06.2012 - 15.06.2012 Feldkirchen (Allalen, Weinberg)
15.06.2012 - 21.06.2012 Hamburg (Auweter, Hammer, Jamitzky, Satzger)
International Supercomputing Conference 2012 (eigener Vortrag)
17.06.2012 - 21.06.2012 Hamburg (Brehm, Wilde)
18.06.2012 - 21.06.2012 Hamburg (Huber)
DatacenterDynamics Conference and Training
25.06.2012 München (Huber)
VM- VIWN (VMware vSphere 5: What´s new)



























25.06.2012 - 26.06.2012 Hallbergmoos (Roll)
Arbeitsmeeting ISO/ IEC JTC1/ SC22/ WG 5
25.06.2012 - 30.06.2012 Toronto -CA (Bader)
Strategic Research Agenda Workshop
29.06.2012 Paris -FR (Huber)
DESY Computing Seminar (eigener Vortrag)
02.07.2012 Hamburg (Lanati)
DEEP WP3 Meeting
04.07.2012 - 05.07.2012 Braunschweig (Auweter)
Peer Review Meeting
17.07.2012 Brüssel -BE (Brehm)
Seminar "Führung kompakt"
30.07.2012 - 03.08.2012 Seeon (Biardzki)
Antragsvorbereitung Projekt NLL
22.08.2012 Frankfurt am Main (Baur)
GridKa School 2012
27.08.2012 - 31.08.2012 Karlsruhe (Leong)
VERCE Training
02.09.2012 - 05.09.2012 Liverpool (UK) (Brietzke, Frank, Leong)
Meeting bei Fa. Bull
03.09.2012 - 04.09.2012 Les Clayes -FR (Auweter, Pancorbo)
PRACE 2 IP All Hands Meeting; PRACE 3 IP Kick off; PRACE 2 IP WP11 Meeting
03.09.2012 - 07.09.2012 Paris -FR (Wilde)
PRACE 2 IP All Hands Meeting; PRACE 3 IP Kick off
05.09.2012 - 07.09.2012 Paris -FR (Lanati, Weinberg)
2nd International Conference on ICT
05.09.2012 - 06.09.2012 Wien -AT (Auweter)
Conf 2012 The 3rd Annual Splunk Worldwide User´s Conference
08.09.2012 - 15.09.2012 Las Vegas -US (Hanauer)
DEEP-Treffen
12.09.2012 Regensburg (Auweter, Huber, Tafani)
e-IRG Delegates Meeting
13.09.2012 - 14.09.2012 Athen -GR (Frank, Straube)
PRACE 1 IP Review Meeting
13.09.2012 - 14.09.2012 Brüssel -BE (Wilde)
EGI Technical Forum
16.09.2012 - 19.09.2012 Prag -CZ (Heller, Leong, Rössle-Blank, Waldmann)
Kurs Data ONTAP 7-Mode Administration
17.09.2012 - 21.09.2012 Hallbergmoos (Kaumanns)
EGI Technical Forum
17.09.2012 - 21.09.2012 Prag -CZ (Frank, Saverchenko)
CEA Meeting
18.09.2012 - 20.09.2012 Paris -FR (Huber)
Xeon Phi Workshop
18.09.2012 - 21.09.2012 Montpellier -FR (Brietzke, Weinberg)
8. Fachtagung IT-Beschaffungen
18.09.2012 - 19.09.2012 Berlin (Bopp)
CEA Meeting
19.09.2012 - 20.09.2012 Paris -FR (Brehm, Wilde)
Finales Redaktionstreffen zum Projekt NLL
19.09.2012 Berlin (Baur)
1st International LSDMA Symposium
24.09.2012 - 25.09.2012 Eggenstein (Peinkofer)
Projektmeeting Autotune
25.09.2012 - 28.09.2012 Rennes/Vannes -FR (Guillen, Hesse, Navarrete)
159
Interna
160




























IGE All-Hands Meeting
01.10.2012 - 04.10.2012 Madrid -ES (Frank, Heller, Paisios, Rössle-Blank)
Mont-Blanc Face-to-Face Meeting; Slurm User Group Meeting
07.10.2012 - 11.10.2012 Barcelona -ES (Pancorbo)
Mont-Blanc Meeting
07.10.2012 - 10.10.2012 Barcelona -ES (Auweter, Tafani)
VM World Konferenz 2012
08.10.2012 - 11.10.2012 Barcelona -ES (Roll)
Blender Conference 2012 (eigener Vortrag)
11.10.2012 - 16.10.2012 Amsterdam -NL (Satzger)
DEEP Treffen WP7
15.10.2012 Regensburg (Auweter)
Tutorium "Grundlagen des Datenschutzes für Administratoren"
15.10.2012 - 15.10.2012 Berlin (Hanauer)
DEEP-Treffen
15.10.2012 Regensburg (Tafani)
DEEP ER Face-to-Face Meeting
17.10.2012 Köln (Huber)
ETP4 HPC Meeting
19.10.2012 Brüssel -BE (Huber)
DEEP Face-to-Face Meeting
22.10.2012 - 24.10.2012 Leuven -BE (Auweter, Tafani)
DGI-2 Workshop zu NGI-DE General Operations Policy
23.10.2012 - 24.10.2012 Karlsruhe (Waldmann)
Review Meeting
23.10.2012 - 24.10.2012 Brüssel -BE (Wilde)
Workshop zur NGI-DE General Operations Policy
23.10.2012 - 24.10.2012 Karlsruhe (Saverchenko)
Mont-Blanc Meeting
28.10.2012 - 30.10.2012 Barcelona -ES (Auweter)
ScalaLife Review Meeting
28.10.2012 - 31.10.2012 Brüssel -BE (Jamitzky)
PRACE 2 IP WP7 Meeting; PRACE 3 IP Face-to-Face Meeting
29.10.2012 - 01.11.2012 Montpellier -FR (Weinberg)
Technology Coordination Board Meeting
05.11.2012 - 06.11.2012 Amsterdam -NL (Heller)
EESI2 Coordination Meeting
06.11.2012 Brüssel -BE (Huber)
Workshop "Online Speicher" als föderierter DFN-Dienst
07.11.2012 - 07.11.2012 Berlin (Baur)
09.11.2012 - 17.11.2012 Salt Lake City -US (Huber, Jamitzky, Satzger, Wilde)
10.11.2012 - 17.11.2012 Salt Lake City -US (Bader)
11.11.2012 - 17.11.2012 Salt Lake City -US (Brehm)
Project Rehearsal and Project Review
18.11.2012 - 21.11.2012 Barcelona -ES (Tafani)
DV-Fachseminar
21.11.2012 - 28.11.2012 Stade (Hufnagl)
EGI/EUDAT/PRACE Workshop
26.11.2012 - 27.11.2012 Amsterdam -NL (Lanati)
IGE Review Meeting
27.11.2012 - 29.11.2012 Brüssel -BE (Frank, Heller, Rössle-Blank)
DEEP Workshop for Suppliers of Supercomputing / HPC System





28.11.2012 - 30.11.2012 Ostrava -CZ (Tafani)
DGI-2 Abschlusstreffen mit dem PT
05.12.2012 - 06.12.2012 Hannover (Frank)
Autotune Review Meeting
10.12.2012 - 11.12.2012 Brüssel -BE (Brehm, Navarrete)
ETP4 HPC Meeting
13.12.2012 - 14.12.2012 Flughafen Municon (Huber, Ott)
Tivoli Sorage Manager Update
13.12.2012 - 14.12.2012 Heidelberg (Peinkofer)
ICPADS Konferenz
17.12.2012 - 19.12.2012 Singapur -SG (Leong)
16.8.3 Abteilung „Kommunikationsnetze“





















D-Grid Beiratssitzung
13.01.2012 Hannover (Reiser)
ZKI Arbeitskreis "Service-Management und Sicherheit"
16.01.2012 - 17.01.2012 Ansbach (Hommel)
DFN-Betriebsausschusssitzung
14.02.2012 Berlin (Reiser)
UI Workshop
15.02.2012 - 17.02.2012 Zürich -CH (Schmitz)
19. DFN-Workshop "Sicherheit in vernetzten Systemen" (eigener Vortrag)
21.02.2012 - 22.02.2012 Hamburg (von Eye)
19. DFN-Workshop "Sicherheit in vernetzten Systemen"
21.02.2012 - 22.02.2012 Hamburg (Hommel)
Geant E2E Mon Review Face-to-Face Meeting
29.02.2012 - 03.03.2012 Kopenhagen -DK (Liu)
Geant Third Bandwidth-on-Demand Service Pilot Workshop
11.03.2012 - 14.03.2012 Athen -GR (Liu)
56. DFN Betriebstagung
13.03.2012 - 14.03.2012 Berlin (Tunka)
D-Grid Ergebniskonferenz
18.03.2012 - 21.03.2012 Bonn (von Eye)
NOMS 2012 (eigene Veröffentlichung)
13.04.2012 - 23.04.2012 Hawaii -US (Reiser)
GN3 JRA 2T1/ SA 2T5 Face-to-Face Meeting
17.04.2012 - 19.04.2012 Belgrad –XS (Liu)
Best Management Practice Kongress 2012
08.05.2012 - 10.05.2012 Bad Neuenahr (Brenner)
IPv6 Kongress
09.05.2012 - 11.05.2012 Frankfurt am Main (Schmidt)
DFN-Forum (eigener Vortrag)
21.05.2012 - 22.05.2012 Regensburg (Reiser, Schmitz)
DFN-Mitgliederversammlung
11.06.2012 - 12.06.2012 Berlin (Reiser)
EUNIS 2012 (eigener Vortrag)
19.06.2012 - 23.06.2012 Vila Real – PT (von Eye)
BHN-Sitzung
21.06.2012 Bamberg (Reiser, Tröbs)
Beratungs- und Expertenworkshop "Europäische IT-Sicherheitsforschung"
04.07.2012 Köln (Reiser)
SIDAR Graduierten Workshop über Reaktive Sicherheit (eigener Vortrag)
161
Interna
162






















05.07.2012 - 06.07.2012 Berlin (von Eye)
D-Grid Beiratssitzung
06.07.2012 Frankfurt am Main (Reiser)
Normausschuss Informationstechnik und Anwendungen "IT-Sicherheitsverfahren"
22.08.2012 Berlin (Metzger)
Fortbildung ComConsult IPv6
09.09.2012 - 12.09.2012 Berlin (Tunka)
ZKI Herbsttagung 2012
10.09.2012 - 12.09.2012 Leipzig (Reiser)
ZKI AK Service Management und Sicherheit
10.09.2012 Leipzig (Hommel)
Security Kurs
17.09.2012 - 21.09.2012 Nürnberg (Metzger)
Teilnahme und Vortrag bei der User Group "IT-Betrieb" (eigener Vortrag)
20.09.2012 - 21.09.2012 Leipzig (Brenner)
Abschiedskolloquium für Peter Holleczek
21.09.2012 Erlangen (Reiser)
Work Meeting FedSM-Projekt
03.10.2012 - 05.10.2012 Barcelona -ES (Brenner)
GEANT Symposium (eigener Vortrag)
15.10.2012 - 19.10.2012 Wien -AT (Gräter, Liu, Pöhn, Schmitz)
57. DFN Betriebstagung
15.10.2012 - 17.10.2012 Berlin (Tunka)
INFOCOMP 2012 Konferenz (eigener Vortrag)
21.10.2012 - 25.10.2012 Venedig -IT (Hommel)
BHN-Sitzung
25.10.2012 Erlangen (Reiser, Tröbs)
Erfahrungsaustausch Netzwerk Management
08.11.2012 Nürnberg (Loidl)
Laborbesuch, Workshop und Besuch NMC
19.11.2012 - 20.11.2012 Bamberg (Reiser)
DV-Fachseminar
21.11.2012 - 28.11.2012 Stade (Stoller)
72. DFN-Betriebsausschusssitzung
DFN Workshop Datenschutz
27.11.2012 - 28.11.2012 Hamburg (Hommel)
Kick-Off Meeting SASER-SIEGFRIED (deutscher Teil)
27.11.2012 - 28.11.2012 München (Hommel, von Eye)
65. DFN Mitgliederversammlung
04.12.2012 - 05.12.2012 Bonn (Reiser)
Working Meeting FedSM-Projekt (eigener Vortrag)
04.12.2012 - 06.12.2012 Amsterdam –NL (Brenner)
GN3 Übergabe Treffen (eigener Vortrag)
06.12.2012 - 07.12.2012 Kopenhagen -DK (Gräter, Liu)
16.8.4 Abteilung „Zentrale Dienste“




Seminar: Gebäudeautomation mit BACnet
23.01.2012 - 25.01.2012 Frankfurt am Main (Kirnberger)
Besprechung Projektvorschlag "German Academic Library Cloud"
26.01.2012 Berlin (Apostolescu)
Tagung "Die neue Entgeltordnung im TV-L"
06.02.2012 München (Apel)























AK Softwarelizenzen Frühjahrstreffen 2012
28.02.2012 - 29.02.2012 Hamburg (Diehn)
BSK-Sitzung
21.03.2012 Regensburg (Diehn)
BRZL-Klausurtagung
21.03.2012 Regensburg (Apostolescu)
CMS Schulung "Einführung in das Content-Management-System GSB"
22.03.2012 - 23.03.2012 Jülich (Palm)
Netzsitzung 2012
22.03.2012 - 23.03.2012 Köln (Apostolescu)
IT-Beiratssitzung in der Bay. Staatsbibliothek
25.04.2012 München (Apostolescu)
Rehearsel und DEEP Review Meeting
10.06.2012 - 12.06.2012 Brüssel -BE (Palm)
ZKI Kernteam-Treffen
13.06.2012 - 14.06.2012 Würzburg (Diehn)
DEEP on ISC 2012
20.06.2012 - 21.06.2012 Hamburg (Palm)
ZKI Arbeitskreis Software-Lizenzen
17.09.2012 - 19.09.2012 Wismar (Diehn)
IBM DataCenter Expert Conference (eigener Vortrag)
19.09.2012 - 20.09.2012 Bonn (Breinlinger)
Abschiedskolloquium für Peter Holleczek
21.09.2012 Erlangen (Apostolescu)
BSK Klausurtagung
27.09.2012 - 28.09.2012 Pfronten (Diehn)
Konferenz Data Center Dynamics
22.10.2012 Frankfurt am Main (Breinlinger)
DEEP Face-to-Face Meeting
22.10.2012 - 24.10.2012 Leuven -BE (Palm)
DFG Netzsitzung 2012
28.10.2012 - 29.10.2012 Berlin (Apostolescu)
Entgeltsystem TVöD/ TVL
29.10.2012 - 30.10.2012 Unterhaching (Apel)
Treffen der AG Novell Landeslizenz
31.10.2012 Regensburg (Diehn)
09.11.2012 - 17.11.2012 Salt Lake City –US (Palm)
DataCenter Update 2012
13.11.2012 - 14.11.2012 Ehningen (Labrenz)
DV-Fachseminar
21.11.2012 - 28.11.2012 Stade (Mende)
72. DFN-Betriebsausschusssitzung
163
Interna
164
16.9 Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten
Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung Benutzernahe Dienste und Systeme betreut:


Lang, A., EnergyViz – Visualising large scale multi-dimensional sensory data to reduce
power
consumption, Master Thesis, Ludwig-Maximilians-Universität München, Sommer 2012
Fussenegger, M., 3D Printing in a Scalable Cloud Environment, Bachelor Thesis, Ludwig-Maximilians-Universität München, Sommer 2012
Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung
Kommunikationsnetze betreut:









Bittner, S., Effizientes Management von Router Access Control Lists (ACL) am Leibniz–
Rechenzentrum (LRZ), Bachelorarbeit, Ludwig–Maximilians–Universität München, Juli,
2012.
Eberl, R., Ontologie–basierter Ansatz einer interorganisationalen Configuration Management Database als Grundlage für das IT Service Management, Diplomarbeit, Ludwig–Maximilians–Universität München, Mai, 2012.
Gembler, E., Erarbeitung eines kryptographischen Modells organisationsweiter Passwortverwaltung am Beispiel des Leibniz–Rechenzentrums, Bachelorarbeit, Ludwig–
Maximilians–Universität München, September, 2012.
Grabatin, M., Erkennung von Innentätern — Entwicklung eines Systems zur heuristischen Analyse von Logfiles am Beispiel eines Hochschulrechenzentrums, Bachelorarbeit,
Ludwig–Maximilians–Universität München, August, 2012.
Obexer, G., Erstellung eines IPv6–Securitykonzeptes für das Münchner Wissenschaftsnetz, Diplomarbeit, Ludwig–Maximilians–Universität München, Mai, 2012.
Reisinger, R., Evaluation der Leistungsfähigkeit des Datenqualitätsmanagements mit
Uniserv–Werkzeugen, Bachelorarbeit, Ludwig–Maximilians–Universität München, September, 2012.
Romanyuk, A., Erstellung eines IT–Forensik–Leitfadens für das LRZ, Diplomarbeit,
Ludwig–Maximilians–Universität München, Januar, 2012.
Wallwitz, A., Konzeption und Implementierung eines Moduls für den Fraunhofer–
Honeypot "MalCoBox" am Leibniz–Rechenzentrum, Bachelorarbeit, Ludwig–
Maximilians–Universität München, Oktober, 2012.
Weber, T., Authentifizierung mit dem neuen Personalausweis (nPA), Fortgeschrittenenpraktikum,
Ludwig–Maximilians–Universität München, Juli, 2012.
Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung Hochleistungssysteme betreut:

Hayk Shoukourian, Towards a unified energy efficiency evaluation toolset: an approach and its
implementation at LRZ, TUM, Oct-2012
165
16.10 Veröffentlichungen der Mitarbeiter 2012
ALLALEN M., OFFMAN D., SATZGER H., JAMITZKY F., LRZ Validation-Suite for
life Science. IinSIDE Vol. 10 No.2 (Autumn), 2012
ISSN 1436-753X
APOSTOLESCU V., BODE A., FRANK A.C., Wissenschaft verbinden – Forschungskooperationen am LRZ, In: Akademie Aktuell, Zeitschrift der Bayerischen Akademie der Wissenschaften, 02/2012, pp. 42-43, 2012
AUWETER A., HUBER H., Direct warm Water cooled Linux Cluster Munich:
CooLMUC. In: inSiDE Band 10, Heft 1, Juni 2012
ISSN 1436-753X
BAUR W., (K)EIN GRUND ZUM FEIERN. In: Akademie Aktuell, Zeitschrift der
bayerischen Akademie der Wissenschaften, Heft 41, Ausgabe 02-2012
ISBN 978-3-642-24024-9
BISCHOF C., HEGERING H.-G., NAGEL W., W ITTUM G., (eds): Competence in
High Performance Computing 2010 (Proceedings, Schwetzingen, June
2010). Springer-Verlag Berlin, Heidelberg 2012 (234 Seiten)
ISSN 1436-753X
BODE A., 50 Jahre IT-Dienstleistung am Leibniz-Rechenzentrum, In: Akademic Aktuell, Zeitschrift der Bayerischen Akademie der Wissenschaften,
02/2012, , pp. 12-16, 2012
ISSN 1436-753X
BODE A., Höchstleistungsrechnen am LRZ, In: Akademie Aktuell, Zeitschrift
der Bayerischen Akademie der Wissenschaften, 02/2012, pp. 44-45, 2012
ISSN (Online) 1865-7648
ISSN (Print) 0341-4183
BRANTL M., CEYNOWA K., GROß M., REINER B., SCHOGER A., Digitale
Langzeitarchivierung in Bayern - Vom explorativen Projekt zum nachhaltigen Modell. In: Bibliothek Forschung und Praxis, Band 35, Heft 1, April
2011
ISBN 978-1-4673-0267-8
BRAUN L., KLEIN A, CARLE G., REISER H., EISL J., Analyzing Caching
Benefits for YouTube Traffic in Edge Networks - A Measurement-Based
Evaluation. In: IEEE/IFIP Network Operations and Management Symposium (NOMS 2012), Maui, Hawaii, USA; April 2012
BREHM M.; BADER R., The new Petaflop Class System at LRZ In: inSiDE –
Innovatives Supercomputing in Deutschland, Vol. 10 No. 1, Spring 2012.
EYE F., METZGER S., HOMMEL W., REISER H., GAIAS-IDS: Architekturkonzept zur Integration szenarienspezifischer Datenquellen in dyna
mische Intrusion Detection Systeme In: SIDAR Graduierten-Workshop
über Reaktive Sicherheit, Berlin, July 2012
VON
ISBN: 978-3-939296-04-1
FASTL H., LICHTINGER B., KERBER S., Psychoakustische Experimente zur
Knallhaftigkeit. Tagungsband Fortschritte der Akustik - DAGA 2012, Darmstadt, pp. 583–584, 2012
FIESELER T., HOMBERG W., AUWETER A., The Mont-Blanc Project: European
Summit of Exascale System Architectures. In: inSiDE Band 10, Heft 1, Juni
2012
Interna
166
ISBN 978-3-00-038333-5
HEGERING H.-G., Chronik 50 Jahre Leibniz-Rechenzentrum der Bayerischen Akadmie der Wissenschaften. LRZ Garching, Druckhaus Köthen,
2012 (304 Seiten)
ISBN 978-9897040863
GENTSCHEN FELDE N., HOMMEL W., REISER H., VON EYE F., KOHLRAUSCH J.,
SZONGOTT C., A Grid–based Intrusion Detection System (GIDS), In Book of
abstracts — a 360° perspective on IT/IS in higher education, 185–186,
University of Trás–os–Montes e Alto Douro, EUNIS 2012 — 18th EUNIS
Congress, Vila Real, Portugal, Juni 2012
ISBN 978-3885792970
GENTSCHEN FELDE N., HOMMEL W., REISER H., VON EYE F., KOHLRAUSCH J.,
SZONGOTT C., Das Datenschutzkonzept für das föderierte Frühwarnsystem
im D–Grid und seine technische Umsetzung, In GI–Edition — Lecture Notes in Informatics (LNI): Proceedings; 5. DFN–Forum Kommunikationstechnologien — Beiträge der Fachtagung, (203), 53–62, Gesellschaft für
Informatik, Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
(DFNVerein), Bonn, Germany, Mai 2012
HOMMEL, W., Integriertes Management von Security–Frameworks, Ludwig–
Maximilians–Universität München, Habilitation, Juli 2012
HOMMEL, W., KRANZLMÜLLER, D., STRAUBE, C., A Platform for the Integrated
Management of IT Infrastructure Metrics, In Proceedings of the Second International Conference on Advanced Communications and Computation
(INFOCOMP 2012), 2012(2), 125–129, Venice, Italy, Oktober 2012
ISSN 2190-846X
HOMMEL W., METZGER S., REISER H., VON EYE F., GAIAS–IDS: Architekturkonzept zur Integration szenarienspezifischer Datenquellen in dynamische
Intrusion Detection Systeme, In: Proceedings of the Seventh GI SIG
SIDAR Graduate Workshop on Reactive Security (SPRING), (SR–2012–
01), GI FG SIDAR, Berlin, Deutschland, Juli 2012
ISBN 978-9897040863
HOMMEL W., METZGER S., REISER H., VON EYE F., Log file management
compliance and insider threat detection at higher education institutions, In
Book of abstracts — a 360° perspective on IT/IS in higher education, 115–
116, Universidade de Trás–os–Montes e Alto Douro, EUNIS 2012 — 18th
EUNIS Congress, Vila Real, Portugal, Juni 2012
ISBN 978-3844806885
HOMMEL W., METZGER S., VON EYE F., Innentäter in Hochschulrechenzentren — organisatorische und technische Maßnahmen zur Prävention und
Detektion, In Sicherheit in vernetzten Systemen: 19. DFN Workshop, B–1–
B–19, Books on Demand, Norderstedt, Januar 2012
ISSN: 1099-1190
DOI 10.1002/nem.1801
HOMMEL W., LIU F., METZKER M., SCHIFFERS, M. KÖNIG R., YAMPOLSKIY M.,
Link repair in managed multi–domain connections with end–to–end quality
guarantees, International Journal of Network Management, 2012 (Volume
22, Issue 6), John Wiley & Sons, September, 2012
ISSN (Online) 1436-753X
HUBER A., AUWETER A., Green IT am Leibniz-Rechenzentrum.
In: Akademie Aktuell, Heft 41, Ausgabe 02/2012, Juli 2012
ISSN (Online) 1436-753X
HUBER H., AUWETER A., Energieeffizienz für die Supercomputer von morgen. In: Akademie Aktuell, Heft 41, Ausgabe 02/2012, Juli 2012
167
JANUSZEWSKI R., GILLY L., YILMAZ E., AUWETER A., SVENSSON G., Cooling –
making efficient choices. PRACE Whitepaper, Oktober 2012
ISBN 978-9897040863
KNITTL S., HOMMEL W., VON EYE F., XaaS Cloud Service Strategy for Dynamic Higher Education Institution IT Infrastructures, In Book of abstracts
— a 360° perspective on IT/IS in higher education, 177–178, Universidade
de Trás–os–Montes e Alto Douro, EUNIS 2012 — 18th EUNIS Congress,
Vila Real, Portugal, Juni 2012
ISSN: 1942-2652
KNITTL S., LIU F., YAMPOLSKIY M., A Reference Model for Improving an Inter–Organizational IT Management Tool, International Journal On Advances in Internet Technology, 2012( Vol. 5, No. 1&2), IARIA, Juli, 2012
DOI 10.1109/
AHS.2012.6268638
ISSN: 1095-323X
DOI 10.1109/
AERO.2012.6187226
ISSN: 1095-323X
DOI 10.1109/
AERO.2012.6187225
ISBN: 978-3-88579-297-0
KRAJA F., BODE A., MARTORELL X.., 2D-FMFI SAR Application on HPC Architectures with OmpSs Parallel Programming Model, Proc. 2012
NASA/ESA Conference on Adaptive Hardware and Systems, pp. 115-121,
IEEE Conference Publications, 2012
KRAJA F., MURARASU A., ACHER G., BODE A., Performance evaluation of
SAR image reconstruction on CPUs and GPUs, IEEE 2012 Aerospace
Conference, pp.1-16, 2012
KRAJA F., ACHER G., BODE A., Parallelization techniques for the 2D Fourier
Matched Filtering and Interpolation SAR Algorthm, IEEE 2012 Aerospace
Conference, pp. 1-10, 2012
LIU F., MARCU P., SCHMITZ D., YAMPOLSKIY M., Rethinking of Multi–Layer
Multi–Domain Network Monitoring, In 5th DFN–Forum Kommunikationstechnologien — Verteilte Systeme im Wissenschaftsbereich, 2012, GI–
Verlag, DFN Forum, Regensburg, Germany, Mai, 2012.
METZGER S., HOMMEL W., VON EYE F., Innentäter in Hochschulrechenzentren – organisatorische und technische Maßnahmen zur Prävention und
Detektion. In: Sicherheit in vernetzten Systemen: 19. DFN Workshop, B-1B-19,
Books
on
Demand,
Norderstedt,
Januar
2012
METZGER S., HOMMEL W., REISER H., VON EYE F., Log file management
compliance and insider threat detection at higher education institutions. In:
Book of abstracts – a 360° perspective on IT/IS in higher education, EUNIS
2012 – 18th EUNIS Congress, Vila Real, Portugal, Juni 2012
METZGER S., HOMMEL W., REISER H., VON EYE F., GAIAS-IDS: Architekturkonzept zur Integration szenarienspezifischer Datenquellen in dynamische
Intrusion Detection Systeme. In: Proceedings of the Seventh GI SIG
SIDAR Graduate Workshop on Reactive Security (SPRING), Berlin,
Deutschland, Juli 2012
ISBN 978-3-88579-297-0
MÜLLER P., NEUMAIR B., REISER H., DREO RODOSEK,G., (Hrsg.) 5. DFN-
Interna
168
Forum Kommunikationstechnologien: Verteilte Systeme im Wissenschaftsbereich. Lecture Notes in Informatics (LNI). Band P-203, Bonn,
May 2012
DOI 10.1016/
j.procs.2012.04.038
MURARASU A., BUSE G., PFLÜGER D., W EIDENDORFER J., BODE A., Fastsg: A
Fast Routines Library for Sparse Grids, Procedia Computer Science, Vol.
9, 2012, Proc. Conf. on Computational Science, ICCS 2012, pp. 354-363,
Elsevier, 2012
ISSN 1436-753X
REISER H., An jedem Ort, zu jeder Zeit: Mobilität im „Netz“. In: Akademie
Aktuell, Ausgabe Nr. 42, S. 30-33, Oktober 2012
ISSN 1436-753X
REISER H., MWN, DFN, GÉANT – München weltweit vernetzt. In: Akademie Aktuell Ausgabe Nr. 41, S. 38-39, Bayerische Akademie der
Wissenschaften, July 2012
RICHTER C., SCHAAF T., An approach to consolidate and optimize monitoring solutions, In 7th IFIP/IEEE International Workshop on Business-driven
IT Management (BDIM 2012), Hawaii, USA, Mai, 2012
PALM L., SuperMUC-Aufbau am LRZ schreitet zügig voran. In: Quartl
1/2011
PALM L., Leibniz-Rechenzentrum erhält „Deutschen Rechenzentrumspreis
2012“. In: Quartl 1/2011
ISSN 1436-753X
PALM L., Das LRZ in Kürze. In: Akademie aktuell 02/2012
PALM L., Inauguration Ceremony of LRZ Extension. In: inSiDE – Innovatives Supercomputing in Deutschland, Vol. 10 No. 1, Spring 2012
PALM L., LRZ awarded German Data Centre Prize. In: inSiDE – Innovatives
Supercomputing in Deutschland, Vol. 10 No. 1, Spring 2012
PALM L., “SuperMUC”, Europe’s fastest Supercomputer, inaugurated at the
50th Anniversary of LRZ. In: inSiDE – Innovatives Supercomputing in
Deutschland, Vol. 10 No. 1, Autumn 2012
PALM L., Mit SuperMUC in die nächsten 50 Jahre. In: Quartl 2/2011
PALM L., Zentrum für Virtuelle Realität und Visualisierung (V2C) am Leibniz-Rechenzentrum eröffnet. In: Quartl 3/2011
ISSN 1436-753X
PALM L., In der Champions League der Großrechner. In: Akademie aktuell
04/2012
ISBN (Print)
978-986-03-4289-5
SCHUBERT G., ANTHES C., KRANZLMÜLLER D., PETZOLD F., From Physical
to Virtual: Real-time Immersive Visualisations from an Architect‘s working
Model. In: Proceedings of 12th International Conference on Construction
Applications of Virtual Reality, Band 12, Heft 1, S. 417-426, November
2012
169
W AGNER S., BODE A. SATZGER H. BREHM M., High Performance Computing
in Science and Engineering, Garching/Munich 2012, Bayerische Akademie
der Wissenschaften 2012 (232 Seiten)
W EINBERG V., Data-parallel programming with Intel Array Building Blocks
(ArBB)
PRACE
Whitepaper,
November
2012,
http://arxiv.org/abs/ 1211.1581
16.11 Promotionen und Habilitationen am LRZ
In 2012 konnte ein Mitarbeiter erfolgreich sein Habilitationsvorhaben abschließen. In diesem Zusammenhang entstand folgende Arbeit

Hommel, W., Integriertes Management von Security–Frameworks, Ludwig–Maximilians–
Universität München, Habilitation, Juli 2012
Technische Ausstattung
170
17 Technische Ausstattung
17.1 Datenspeicher
BRUTTOKAPAZITÄTEN ONLINE-SPEICHER (NAS+SAN)
Typ
Modell
Anwendung
NAS
2 x NetApp FAS 3050
E-Mail LRZ, interne Server, ArbeitsplatzFiledienste, WWW
47 TB
NAS
1 x NetApp R200
Replikation (asynchrones Spiegeln)
50 TB
NAS
2 x NetApp FAS 6070
Speicher für die Wissenschaft (SFW), Speicherhosting LMU, Exchange
236 TB
NAS
2 x NetApp FAS 3170
Metrocluster für VMware
504 TB
NAS
1 x NetApp FAS 6070
Replikation für den SFW und VMware
319 TB
NAS
2 x NetApp FAS 6280
Speicher für die Wissenschaft (SFW), NFSDateidienste, Linux-Mailsysteme (NEU)
960 TB
NAS
1 x NetApp FAS 6280
Replikationssystem für SFS, NFS-Dateidienste,
Linux-Mailsysteme (NEU)
576 TB
NAS
1 x NetApp FAS 6280
Replikationssystem für VMware
288 TB
NAS
2 x NetApp FAS 3170
Speicher für LZA-Projekte der BSB
730 TB
NAS
12 x NetApp FAS 6280 Projektspeicherplatz für SuperMUC
3.456 TB
NAS
4 x NetApp FAS 6280
Replikation Projektspeicherplatz für SuperMUC
1.536 TB
NAS
6 x NetApp FAS 3170
Linux-Computecluster
NAS
1 x NetApp FAS 3050
Linux compute cluster repository (staging)
NAS
2 x SUN 7310
Speicher für Datenbanken und VMware
22 TB
NAS
1 x SUN 7210
Replikation für SUN7310
24 TB
NAS
2 x NetApp FAS 3170
Metrocluster für Hochschulstart.de
50 TB
NAS Gesamt
Kapazität
584 TB
8 TB
9.390 TB
SAN
1 x STK D280
AFS
SAN
9 x IBM DS3500
Cache für Archiv- und Backupsystem
1938 TB
SAN
3 x SUN 6780
Cache für Archiv- und Backupsystem
486 TB
SAN
2 x IBM StorWize SSD DB für Archiv- und Backupsystem
SAN
3x Dell PowerVault
SAN Gesamt
Gesamt NAS+SAN
DB+Cache für Archiv- und Backupsystem
14 TB
10 TB
281 TB
2.729 TB
12.119 TB
171
Die Tabelle gibt differenziert nach Speicherarchitektur einen Überblick über die Bruttokapazität der Plattenspeichersysteme des LRZ Ende 2012 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, NFS und iSCSI zugegriffen. Die SAN-Plattensysteme sind mit den Rechnern und Bandlaufwerken über die Speichernetz-Infrastruktur verbunden.
Unter Nearlinesystemen versteht man Speicher, die nicht in direktem Zugriff sind. Der Datenträger (in
der Regel eine Kassette) muss erst in ein Laufwerk geladen werden. Die nachfolgende Tabelle gibt die
Mindestkapazitäten differenziert nach Typ des Datenträgers an. Durch die Hardwarekomprimierung der
Bandlaufwerke wird in der Praxis eine deutlich höhere Speicherbelegung erreicht, als in der Tabelle angegeben.
KAPAZITÄTEN DER NEARLINE-SPEICHER
Systemname
Bandbibliothek
Bandlaufwerke
Kassetten
Kapazität
DRABS
IBM TS3500
7 x IBM LTO 5
6.000
9.000 TB
SUN SL8500
26 x SUN T10K
10.000
10.000 TB
IBM TS3500
15 x IBM LTO 5
5.000
7.500 TB
IBM TS3500
10 x IBM LTO 4
8 x IBM LTO 5
16.500
14.000 TB
SUN SL8500
16 x IBM LTO 4
16 x IBM LTO 5
5
98
37.500
40.500 TB
HABS
LABS
Gesamt
17.2 Rechner und Server
17.2.1 Höchstleistungsrechner SuperMUC
Gesam- Systemdaten
Anzahl ter
Kompo- HauptProzessoren der
nenten speicher Typ der Komponenten Komponenten
(in GB)
18 Inseln 297216
Hochtemperaturwassergekühltes IBM
System x iDataPlex mit
Fat-Tree Verbindungsnetz auf der Basis von
Mellanox FDR10 Infiniband Technologie.
Die Inseln sind untereinander ebenfalls mit
einem Fat-Tree verbunden, allerdings mit einer
um den Faktor 4 reduzierten Bandbreite.
Aufgabe
Je Insel 516 iDaHöchstleistungsrechner für BenuttaPlex Knoten mit
zer aus den Hochschulen in
jeweils zwei 8-Core Deutschland sowie Tier-0 System
Intel Sandy Bridge- für europäische Nutzer aus dem
EP (Xeon E5-2680) PRACE Projekt; für die NutzungsSockeln und 32
berechtigung ist eine spezielle BeGByte Hauptspeicher. gutachtung durch den wissenschaftlichen Lenkungsausschuss oder
PRACE-Begutachtung notwendig.
Typ: Parallel-Rechner
172
17.2.2 Migrationssystem SuperMIG (IBM BladeCenter HX5)
Anzahl
der
Komponenten
Gesam- Systemdaten
ter
Haupt- Typ der Komponen- Prozessoren der
speicher ten
Komponente
(in GB)
Eine
Insel
52480
Aufgabe
Luftgekühltes
IBM 205 x3850 Blades Höchstleistungsrechner für BenutBladeCenter HX5 mit mit jeweils vier 10- zer aus den Hochschulen in
Fat-Tree Verbindungs- Core Westmere-EX Deutschland; für die Nutzungsbenetz auf der Basis von (Intel Xeon E7-4870) rechtigung ist eine spezielle BeMellanox QDR Infini- Sockeln und 256 gutachtung durch den wissenband Technologie.
GByte Hauptspeicher schaftlichen Lenkungsausschuss
notwendig. Typ: Parallel-Rechner
17.2.3 Hochleistungs-Linux-Systeme
Am LRZ selbst konfigurierter Linux-Cluster, der aus ca. 1.100 Komponenten mit insgesamt 23.5 TByte
Hauptspeicher besteht, die mit 1 oder 10 GBit Ethernet, Myrinet oder Infiniband vernetzt sind. Er dient
zur Bearbeitung üblicher, auf Linux verfügbarer Anwendungsprogramme und für Programme, die mittels
MPI parallelisierbar sind.
Systemdaten
Anzahl
Anzahl der Hauptder
Typ der Kom- Prozessoren speicher Aufgabe
Kompo- ponenten
der Kompo- der Komnenten
nente
ponente
1
SUN X4100
2
Opteron,
2600
MHz
4 GB
Komponente des Linux-Clusters:
SGE 6.2u2 Master-Server
1
SUN X4100
4
Opteron,
2600
MHz
8 GB
Komponente des Linux-Clusters:
Zentraler nagios-Überwachungsserver
8
MEGWARE
8
Xeon
E5462,
2800 MHz
16 GB
Attended Cluster-Housing-Knoten des
Lehrstuhls für Geodäsie der TUMünchen
15
SUN 4600
16
Opteron,
2800
MHz
64 GB
Lehrstuhls für Mathematik der TUMünchen
35
MEGWARE
4
Xeon
X3230,
2667 MHz
8 GB
Attended Cluster-Housing-Knoten der
Bayerischen Staatsbibliothek
124
MEGWARE
4
Xeon
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:
173
Systemdaten
Anzahl
Anzahl der Hauptder
Kompo- ponenten
nente
ponente
68
MEGWARE
8
Xeon
L5420,
2500 MHz
16 GB
Komponente
des
Linux-Clusters:
15
MEGWARE
4
Xeon 5060, 3200
MHz
4 GB
Komponente
des
Linux-Clusters:
LCG Tier-2 dCache-Knoten
13
MEGWARE
4
Xeon 5148, 2333
MHz
4 GB
Komponente
des
Linux-Clusters:
10
MEGWARE
4
Xeon
L5240,
3000 MHz
8 GB
Komponente
des
Linux-Clusters:
6
DELL
24
Xeon
L5640,
2261 MHz
16 GB
Komponente
des
Linux-Clusters:
2
MEGWARE
16
Quad-Core Opteron, 2400 MHz
132 GB
LMU Exzellenz-Cluster
20
MEGWARE
8
Xeon
L5420,
2500 GHz
32 GB
112
MEGWARE
8
Xeon L 5420,
2500 GHz
16 GB
1
MEGWARE
4
Xeon
E5504,
2000GHz
12
LMU, LS Prof. Ruhl
12
MEGWARE
6
Xeon
X5500,
2660GHz,
Je 1 NVidia GPU
48
LMU, LS Prof. Ruhl
4
MEGWARE
48
AMD Opteron,
Je 1 NVIDIA
GPU
16
LMU, LS Prof. Ruhl
38
MEGWARE
8
Opteron,
2600
MHz
32 GB
Komponente
des
Linux-Clusters:
x86_64-Cluster Knoten für parallele
MPI- und 8-fach Shared Memory Jobs
234
MEGWARE
Opteron,
2600 MHz
8 GB
Komponente
des
Linux-Clusters:
x86_64-Cluster Knoten für serielle und
parallele 4-fach Shared Memory Jobs
4
174
Systemdaten
Anzahl
Anzahl der Hauptder
Kompo- ponenten
nente
ponente
64
SGI
Altix 512
ICE8200
Xeon
E5540,
2533 MHz
1536 GB
X86_64-MPP-Rechner
 2 Prozessorsockel pro Knoten
 8 Prozessorkerne pro Knoten
 3 GB pro Prozessorkern
2
SGI UV1000
Xeon E7-4780,
2400 MHz
1040
3328 GB
X86_64-SMP-Rechner. Er wird in Form
zweier separierter 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.
17.2.4 Grid-Rechner
Anzahl
Typ
CPUs
RAM (GB)
Projekt
9
VM
1-2
0,5-4
D-Grid
2
VM
1
0,5
EGI
10
VM
1-2
0,5-4
IGE
23
VM
1-2
0,5-4
Internal
3
VM
1
0,5-2
MAPPER
13
VM
1-2
0,5-8
PRACE
3
VM
1
1-32
VERCE
8
Intel Xeon
16
16
Internal
17.2.5 Hochleistungs-Graphik-System
System
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
Kompo- Typ der Komponenten
nenten
Anzahl der
Prozessoren der
Komponente
Hauptspeicher
der
Komponente
Aufgabe
Systemdaten
(Bei Systemen, die aus mehreren Komponenten bestehen,
stehen die Daten der einzelnen Komponenten in den
Zeilen darunter)
Hersteller
und System-Typ
Struktur
GrafikHochleistungsCluster
SGI Altix
XE500
Cluster mit 12
Knoten
System
175
Anzahl
der
Kompo- Typ der Komponenten
nenten
Anzahl der
Prozessoren der
Komponente
Hauptspeicher
der
Komponente
Aufgabe
12
Je 2 x Intel 6core Xeon, 2
3.06 GHz,Nvidia Quadro
6000
144 GB 5-seitige Projektionsinstallation,
(Server) (CAVE), 2,70 x 2,70 m pro Seite
48 GB
(Renderknoten)
SGI Altix
UV10
1
4 x Intel 8core Xeon,
2.66 GHz, Nvidia
Quadroplex mit 4
Quadro 7000
4
262 GB
Großformatige Stereoprojektion,
(Powerwall), 6m x 3,15 m
Am LRZ
Mit 10 Gbit-E
selbst
vernetzte Intel
konfiguriert Xeon Systeme
3
SGI VSS40
Intel Xeon 5160 3 GHz
Nvidia Quadro FX5600
mit Gsync
2
32 GB
Immersive 3D-Projektionstechnik (im
Visualisierungs-Labor) als RechenCluster für eine Holobench
Remote
SUN Fire
Visualisie- X4600
rungssysteme
Mit 10 Gbit-E
1
vernetztes AMD
Opteron System
SUN Fire X4600 mit 4 16
Nvidia QuadroplexEinheiten mit insgesamt
4 Quadro FX5500 Grafikkarten
128 GB
Remote Visualisierung von umfangreichen Datensätzen
SUN Fire
X4600
Mit 10 GbitE
4
vernetztes AMD
Opteron System
8
AMD Quad-Core Opteron
16
128 GB
Remote Visualisierung von umfangreichen Datensätzen, speziell im
Rahmen von D-GRID
Nvidia Quadro FX5800
Grafikkarte
240 GPUs
4 GB
Intel Xeon
System
Intel Xeon Quadcore
8
62 GB
GPGPU
System
FluiDyna
TWS
2
Nvidia Tesla Grafikkarte 240 GPUs
GPGPU Testsystem
4 GB
17.2.6 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
ca. 350 PCs und andere Desktop-Workstations als Arbeitsplätze
14
Dell
Dual QuadCore 2,8 GHz
2
ca.
115
Dell
Intel Core i5 3,2 GHz
1
8 GB Benutzerarbeitsplätze LRZ
1-8 GB Mitarbeiter-Arbeitsplätze, incl. Operateure,
Hotline, Beratung, stud. Hilfskräfte, Windows
oder Linux
176
Anzahl
ca.
120
ca. 25
30
Anzahl
Hersteller
Typ
Dell
Intel Core i7 M 2.70 Ghz
Dell, Apple
Verschiedene
Dell
Intel Core i5 3,2 GHz
Hersteller
Typ
Anz.
Proz.
1
1-4
1
Anz.
Proz.
Hauptspeicher
Aufgabe
256MB - 8 Laptops für Präsentationen,
GB Arbeitsplätze für Mitarbeiter
Notebooks/
0,5-4 GB Benutzerarbeitsplätze für spezielle Geräte
(Multimedia ACAD-Arbeitsplätze, Scanner,
Multimedia, Videoschnittplatz)
4-8 GB Arbeitsplätze in Kursräumen
Hauptspeicher
Aufgabe
BVB- Server und Storage
9
Sun
SPARC Verschiedene
2-32
15
Sun
Verschiedene
1-8
26
FSC
Verschiedene
1-8
6
SUN
Storage FC und SCSI
16 TB Storage für Datenbanken
1
IBM
Storage
24 TB Storage für Datenbanken
16
HP Blades
Xeon 2,53 GHz
1-8
4-92 GB Zentrales Verbundsystem, Lokalsysteme (Datenbanken und OPACs)
8-32 GB Firewall, Suchmaschinen-Cluster
1-8 GB Suchmaschinencluster, OPACS, weitere Webdienste, Allegro Datenbanken, Windows und
Citrix Server, Mailserver, Netzüberwachung.
0,5-4 GB Webservice/-control, Suchmaschinen
Anzahl
Hersteller
Typ
177
Anz.
Proz.
Hauptspeicher
Aufgabe
Windows-Server
2
DELL
Xeon 2,53 GHz
1
24 GB SQL-Cluster
5
DELL
Xeon 2,4 GHz
2
16 GB Active Directory
9
VMware
Xeon 2,53 GHz
1-4
4
Vmware
Xeon 2,53 GHz
2
12
Vmware
Xeon 2,53 GHz
1-4
6
Dell
Xeon 2,53 GHz
2
11
DELL
Xeon 2,3 GHz
1-2
16 GB Facility Mgmt, Datenbanken, Storageserver,
Applikationsserver
29
Vmware
Xeon 2,53 GHz
1-2
8 GB Management Server, Applikationsserver, Softwareverteilung,
Sharepoint,
Monitoring,
Domänencontroller
Anzahl
Hersteller
Typ
Anz.
Proz.
16 GB Citrix Farm, Terminalserver Farm
4 GB IET-Infrastruktur
4-48 GB MS Exchange 2010, Forefront TMG
64 GB MS Exchange 2010
Hauptspeicher
Aufgabe
83 Linux-Server für AFS, Backup- und Archivierungsdienste
14
Advanced
Unibyte
Xeon 2,80 GHz
23
IBM
Xeon bis 3,00 GHz
2
SGI
Xeon 2,66 GHz
8
10
VMware
Xeon 2,53 GHz
1-8
4
Dell
Pentium III 1,0 GHz
2
0,25-2 GB AFS
13
Sun
AMD Opteron 2,59 GHz
4
bis 16 GB Backup, Archivierung
5
IBM
AMD Opteron
bis 2,59 GHz
2
6 GB Backup, Archivierung
12
Sun
Xeon 2,83 GHz
16
bis 74 GB Backup, Archivierung
Anzahl
Hersteller
Typ
1-2
2-64
Anz.
Proz.
2-4 GB AFS
2-132 GB Backup, Archivierung
8 GB NAS-Backup, Test
0,5-4 GB Webservice, Software-Management
Hauptspeicher
Aufgabe
35 Linux-Server für Maildienste
15
Advanced
Unibyte
Xeon bis 3,60 GHz
2-4
2-8 GB -
20
VMware
Xeon 2,53 GHz
1-2
1-4 GB -
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
58 Linux-Server für Webdienste
27
VMware
Xeon 2,53 GHz
1-4
0,5-8 GB Moodle, Proxy, Apache, Zope
31
Sun
AMD Opteron
bis 2,59 GHz
1-4
8-16 GB Apache, Zope
178
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
23 Linux-Server für Datenbanken
19
VMware
Xeon 2,53 GHz
4
Sun
Anzahl
Hersteller
Typ
1-2
0,5-16 GB MySQL
4
16 GB MySQL
Anz.
Proz.
Hauptspeicher
Aufgabe
48 Linux-Server für e-Directory-Dienste
41
VMware
Xeon 2,53 GHz
1-2
1-6 GB SIM
7
Sun
1-2
2-8 GB SIM
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
18 Linux-Server für Konsolzugänge und Leitwarten-PCs
5
Avocent
-
1
1
VMware
Xeon 2,53 GHz
2
5
Dell
Pentium III bis 1,4 GHz
2
5
Dell
Pentium 4 3,20 GHz
2
Dell
Core i5 3,20 GHz
Anzahl
Hersteller
Typ
- Serielle Konsolen
1 GB Konsole für externe Benutzer
0,25-2 GB Leitwarte, LOM-Gateway
1-2
1 GB Leitwarte
4
4 GB Leitwarte
Anz.
Proz.
Hauptspeicher
Aufgabe
Linux-Server für Grafik- und Multimedia-Dienste
2
Advanced
Unibyte
Xeon 2,80 GHz
2
2 GB Printing
3
SGI
Xeon 3,0 GHz
4
3 GB Grafik-Cluster
4
VMware
Xeon 2,53 GHz
2
Sun
Anzahl
Hersteller
Typ
1-2
0,5-2 GB Printing, Streaming
2
Anz.
Proz.
2 GB Printing
Hauptspeicher
Aufgabe
53 Linux-Server für Hosting und Housing externer Kunden
3
Advanced
Unibyte
Xeon bis 3,20 GHz
4
1
Sun
Xeon 3,0 GHz
4
45
VMware
Xeon 2,53 GHz
1
Dell
Pentium III bis 1,4 GHz
3
Sun
AMD Opteron
bis 2,59 GHz
1-8
2
2-4
4-16 GB e-Learning, Webservice
8 GB e-Learning
0,5-32 GB IntegraTUM-, BSB-, Hosting
- KDE
2-8 GB VMware-Server, Bibliotheksverwaltung
Anzahl
Hersteller
Typ
179
Anz.
Proz.
Hauptspeicher
Aufgabe
67 Linux-Server für verschiedene Dienste
5
Advanced
Unibyte
Xeon 2,80 GHz
2-4
51
VMware
Xeon 2,53 GHz
1-4
1
Dell
Pentium III 1,26 GHz
6
Sun
4
Dell
Xeon 2,67 GHz
2
1-2
24
2-4 GB Installation, Monitoring
0,5-4 GB Lizenzverwaltung, Monitoring, Tests
1 GB Nagios
2-4 GB VoIP, Up.Time, News, Splunk
24 GB VoIP, Monitoring
17.3 Netzkomponenten
17.3.1 Router
Anzahl Hersteller/Typ
Einsatz
Aktive Ports
10GE
Aktive
Ports 1GE
Aktive
Ports FE
Aktive
Ports
Ethernet
8
Cisco Catalyst 6509
Backbone-Router
50
240
8
0
4
Cisco Catalyst 6509
LRZ-Router
75
56
1
0
1
Cisco 7206VXR
Anbindung Triesdorf
0
2
0
0
1
Cisco 2821
Anbindung Straubing
0
0
2
0
1
Cisco 2911
Anbindung Fürstenfeldbruck
0
2
0
0
1
Cisco 1921
Anbindung Ingolstadt
0
2
0
0
18
Cisco 1811/1812
Standortanbindung
0
0
36
0
2
Cisco 1721
Standortanbindung
0
0
1
3
2
Cisco 891
0
0
4
0
1
Cisco 1802
0
0
2
0
5
Cisco 1921
Site2Site VPN
0
0
4
0
2
F5 BigIP 8900
Server Load Balancer
4
0
0
0
1
F5 BigIP 3400
Server Load Balancer
0
4
0
0
48
Router gesamt
129
306
53
2
17.3.2 Switches
Anzahl
2
253
214
171
1
13
11
Hersteller/Typ
HP E8212zl
HP E5406zl / E5412zl
HP E4204 / HP E4208vl
HP 4104gl / HP 4108gl
HP 4000
HP E6600-24XG/-24G-4XG
HP E6600-48G-4XG
4
HP E3800-48G-4G
4
1
14
HP 3500yl-24G-PoE+
HP 3500yl-48G-PoE+
HP E2910al-24G
verfügbare TP-Ports
verfügbare Glasfaserports
10/100/1000
10GE
100/1000
10GE
25.354
9
3.944
337
23.423
11.393
24
-
614
1.898
-
3
-
624
9
-
138
161
-
31
9
137
-
7
-
1.478
-
10
12
180
24
7
31
24
HP E2910al-48G
HP2900-24G
HP2900-48G
HP E2810-24G
17
HP E2810-48G
11
2
2
49
23
11
25
186
10
62
18
46
48
4
11
3
HP3400cl-48G
HP 6400cl-6XG
HP 6410cl-6XG
HP 2824
HP 2848
HP E2620-24
HP E2610-48 / -48pwr
HP E2610-24 / -24pwr
HP E2610-24/12pwr
HP E2615-8-PoE
HP E2915-8G-PoE
HP 2650
HP 2626 / HP 2626-pwr
HP 2600-8-pwr
HP E2510 / HP E2510G
HP 2524
1.656
72
-
39
1.371
-
21
-
523
-
5
6
-
16
-
8
2.271
-
9
-
286
11
6.365
-
99
-
782
-
18
-
3.488
-
96
-
264
74
-
12
1
-
1
Cisco Nexus7000
-
-
-
288
1.303
Switches gesamt
79.674
106
6.776
840
17.3.3 WLAN-Komponenten
Anzahl
Hersteller/Typ
Verwendung
Standards
939
HP MSM 310
Access Point
802.11b/g
Radios
1
10
HP MSM 310
Gebäudeanbindung
802.11b/g
1
94
HP MSM 320
Access Point
802.11a/b/g
2
1
HP MSM 320
Gebäudeanbindung
802.11a/b/g
2
450
HP MSM 422
Access Point
802.11a/g/n
2
6
HP MSM 422
Gebäudeanbindung
802.11a/g/n
2
498
HP MSM 460
Access Point
802.11a/g/n
2
51
HP MSM 466
Access Point
802.11a/g/n
2
4
HP MSM 466
Gebäudeanbindung
802.11a/g/n
2
1
HP MSC3200
Controller
6
HP M111
Wireless Client Bridge
2.060
2
802.11b/g
1
WLAN gesamt
17.3.4 Netz-Server
Anzahl
Hersteller/Typ
Verwendung
Betriebssystem
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/ISDN-Server,
SIP-Gateway
proprietär
2
Cisco ASA5580
Firewall
proprietär
Prozessoren Hauptspeicher
2
24 GB
181
1
Meinberg Lantime
NTP-Server
Linux
1
32 MB
14
Dell PowerEdge R610
DNS/DHCP-Server
Security-Server
VoIP-Server
Linux
96
268 GB
2
Sun Fire X4100
Radius
Linux
4
4 GB
2
Sun Galaxy
VoIP
Linux
2
8 GB
2
Sun Fire X4150
Netzmanagement
Linux
8
8 GB
1
Dell GX150
DSL-Server
Linux
1
256 MB
2
Sun Fire X2100
Bibliotheksproxy
Linux
2
2 GB
37
Server gesamt

2012 - LRZ

Transcrição

Documentos relacionados

Das Dienstleistungsangebot des LRZ

Bestellung zum Gewässerschutzbeauftragten/Abfallbeauftragten

Hören

Zur Ausfolgung von Legaten (Teil 2

Das Verlassenschaftsinventar (Teil 2)

Insights from the Global C-suite Study - The CHRO

primergy tx200 s3

So sichern Sie Ihren Datenschatz

Silicon Photonics, 400 G und 1T

IBM Flex System p260 und p460 Rechenknoten

Berufsschule Hochbautechnik Klassenstruktur Schuljahr 2011/12

Abmahnung eines Betriebsratsmitglieds/Anspruch auf Entfernung

Folien zu dem Vortrag von Dr. Brisch