2010 - LRZ

Transcription

2010 - LRZ

Leibniz-Rechenzentrum
der Bayerischen Akademie der Wissenschaften
Jahresbericht
2010
Juni 2011
Direktorium:
Prof. Dr. A. Bode (Vorsitzender)
Prof. Dr. H.-J. Bungartz
Prof. Dr. H.-G. Hegering
Prof. Dr. D. Kranzlmüller
LRZ-Bericht 2011-01
Boltzmannstraße 1
85748 Garching
UST-ID-Nr. DE811335517
Telefon:
Telefax:
E-Mail:
Internet:
(089) 35831-8000
(089) 35831-9700
lrzpost@lrz.de
http://www.lrz.de
Öffentliche Verkehrsmittel:
U6: Garching-Forschungszentrum
Jahresbericht 2010 des Leibniz-Rechenzentrums
Vorwort
1
........................................................................................................................................1
Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS) ........3
1.1
Kurse und Veranstaltungen ....................................................................................................3
1.1.1 Kursübersicht, Statistik 2010.....................................................................................3
1.1.2 Vorträge „Schattenseiten des Internet“......................................................................5
1.2
Software-Versorgung für Rechnersysteme außerhalb des LRZ .............................................6
1.2.1 Landesweiter ESRI Vertrag .......................................................................................6
1.2.2 Landesweiter Secunia Vertrag ...................................................................................7
1.2.3 Weitere neue oder geänderte Verträge ......................................................................7
1.2.4 Routinemäßige Verlängerung bestehender Verträge .................................................7
1.2.5 Status Microsoft Select-Plus Lizenzen ......................................................................7
1.2.6 Betrieb von Lizenzservern für externe Systeme am LRZ .........................................7
1.2.7 Verträge mit Instituten im MWN ..............................................................................7
1.2.8 Laufende Verhandlungen und Planungen..................................................................7
1.2.9 Zusammenfassung .....................................................................................................8
1.3
Benutzerverwaltung und Verzeichnisdienste .........................................................................8
1.3.1 Für LRZ-Systeme vergebene Kennungen .................................................................8
1.3.2 LRZ Secure Identity Management (LRZ-SIM) .......................................................10
1.3.3 TUM-Verzeichnisdienste ........................................................................................14
1.3.4 AAI-Föderationen: Shibboleth Identity Provider ....................................................16
1.4
E-Mail, Web-Dienste und Datenbanken...............................................................................18
1.4.1 E-Mail-Services .......................................................................................................18
1.4.2 Webdienste ..............................................................................................................22
1.4.3 Datenbanken ............................................................................................................26
1.5
Grafik, Visualisierung, Multimedia......................................................................................27
1.5.1 Virtual Reality (VR) ................................................................................................27
1.5.2 Streamingserver .......................................................................................................27
1.6
Serveradministration und Applikationsunterstützung ..........................................................27
1.6.1 Serveradministration in BDS ...................................................................................28
1.6.2 Service für das Münchner Wissenschaftsnetz .........................................................28
1.7
Desktop-Applikationsservices ..............................................................................................29
1.7.1 Sicherheitsdienste für Desktops im MWN ..............................................................29
1.7.2 Active Directory im Münchner Wissenschaftsnetz .................................................30
1.7.3 Desktop Management ..............................................................................................32
1.7.4 Server Management .................................................................................................34
1.7.5 Microsoft Office Sharepoint Services (MOSS) .......................................................35
1.7.6 Tätigkeiten im Rahmen der Berufsausbildung ........................................................36
1.8
Server- und Benutzerzertifizierung nach X.509 ...................................................................36
1.9
Bearbeitung von Missbrauchsfällen .....................................................................................37
1.9.1 Statistik der Missbrauchsfälle..................................................................................37
1.10 IT Bibliotheksverbund Bayern .............................................................................................42
1.10.1 Umsetzung Großgeräte-Antrag................................................................................43
1.10.2 Rosetta .....................................................................................................................44
2
Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS) ......................45
2.1
Entwicklung in der Datenhaltung .........................................................................................45
2.1.1 Überblick .................................................................................................................45
i
Inhaltsverzeichnis
ii
2.1.2
2.1.3
2.1.4
2.1.5
3
Archiv- und Backupsystem..................................................................................... 45
Langzeitarchivierung .............................................................................................. 52
Online-Speicher ...................................................................................................... 56
Daten- und Archivraum .......................................................................................... 62
2.2
Entwicklungen bei den Rechensystemen ............................................................................ 62
2.2.1 Höchstleistungsrechner in Bayern (HLRB II: SGI Altix 4700).............................. 62
2.2.2 Linux-Cluster .......................................................................................................... 70
2.2.3 Tests und Prototypen .............................................................................................. 70
2.2.4 Linux MPP Erweiterung ......................................................................................... 70
2.2.5 Remote Visualisierungsserver ................................................................................ 71
2.3
Aktivitäten zur Beschaffung des neuen Petascale-Rechners SuperMUC........................... 72
2.4
Software und User Support im Bereich Hochleistungsrechnen .......................................... 74
2.4.1 Software für Linux-Cluster und Höchstleistungsrechner ....................................... 74
2.4.2 Supportanfragen...................................................................................................... 75
2.4.3 Einführung des neuen Incidenttools ....................................................................... 75
2.4.4 Benutzerverwaltung ................................................................................................ 75
2.4.5 Kurse und Ausbildung ............................................................................................ 75
2.5
Öffentlichkeitsarbeit ............................................................................................................ 76
2.5.1 Supercomputing Konferenzen in Hamburg und New Orleans .............................. 76
2.5.2 Wissenschaft im Dialog/Tag der offenen Tür......................................................... 77
2.5.3 Berichtsband ........................................................................................................... 77
2.5.4 InSiDe und Quartl ................................................................................................... 77
2.5.5 Sonstige Aktivitäten im Umfeld des Hochleistungsrechnens ................................. 78
2.6
Projekte und Kooperationen ................................................................................................ 79
2.6.1 PRACE ................................................................................................................... 79
2.6.2 DEISA2 .................................................................................................................. 80
2.6.3 PROSPECT e.V. ..................................................................................................... 82
2.6.4 KONWIHR ............................................................................................................. 82
2.6.5 ISAR ....................................................................................................................... 83
2.6.6 EU Projekt Scalalife ............................................................................................... 83
2.6.7 Beteiligung an Workshops...................................................................................... 83
2.7
Tätigkeiten im Server-Betrieb ............................................................................................. 83
2.7.1 Linux-Serversysteme .............................................................................................. 83
2.8
Aktivitäten im Bereich „Verteilte Ressourcen“................................................................... 87
2.8.1 Initiative for Globus in Europe (IGE) ..................................................................... 88
2.8.2 D-Grid: Förderung „e-Science und vernetztes Wissensmanagement“ des
BMBF ..................................................................................................................... 88
2.8.3 EGI-InSPIRE .......................................................................................................... 90
2.8.4 MAPPER ................................................................................................................ 90
2.8.5 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3) .................. 90
2.8.6 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG) ................... 90
2.8.7 LRZ-Projekt „Eclipse4Grid“ .................................................................................. 91
2.8.8 Cloud-Computing ................................................................................................... 91
2.8.9 Projektanträge 7. EU-Forschungsrahmenprogramm „e-Infrastrukturen“ ............... 92
2.8.10 Betrieb der Grid-Infrastruktur................................................................................. 92
2.8.11 Sonstige Grid-Aktivitäten ....................................................................................... 92
2.9
Managed Hosting für Hochschulstart.de ............................................................................. 93
Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes .............................. 95
3.1
Betrieb des Kommunikationsnetzes .................................................................................... 95
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
4
Backbone-Netz ........................................................................................................98
Gebäude-Netze ........................................................................................................99
Rechenzentrumsnetz ..............................................................................................100
Wellenlängenmultiplexer ......................................................................................101
WLAN (Wireless LAN) ........................................................................................102
Wesentliche Netzänderungen im Jahr 2010 ..........................................................109
Netzausbau (Verkabelung) ....................................................................................110
Anbindung Studentenwohnheime..........................................................................110
3.2
Dienste................................................................................................................................113
3.2.1 Wählzugänge (Modem/ISDN)...............................................................................113
3.2.2 VPN .......................................................................................................................115
3.2.3 DFN-Roaming .......................................................................................................117
3.2.4 Unterstützung von Veranstaltungen ......................................................................118
3.2.5 Internet-Zugang .....................................................................................................122
3.2.6 Service Load Balancer (SLB) ................................................................................124
3.2.7 Proxies und Zeitschriftenzugang ...........................................................................124
3.2.8 Domain Name System ...........................................................................................125
3.2.9 DHCP-Server .........................................................................................................126
3.2.10 Voice over IP (VoIP) im Jahr 2010 .......................................................................127
3.2.11 Zugang über UMTS: Vodafone Sponsoring der Exzellenz Universitäten
TU München und Ludwig-Maximilians-Universität München .............................127
3.2.12 IPv6 im MWN .......................................................................................................127
3.3
Management .......................................................................................................................129
3.3.1 Weiterentwicklung und Betrieb der Netzdokumentation ......................................129
3.3.2 Netz- und Dienstmanagement ...............................................................................130
3.3.3 Überwachung der Dienstqualität des MWN mit InfoVista ...................................133
3.3.4 Action Request System (ARS) ..............................................................................135
3.4
Sicherheit............................................................................................................................139
3.4.1 NAT-o-MAT/Secomat ..........................................................................................139
3.4.2 Security Information & Event Management..........................................................140
3.4.3 Zentrale Sperrliste .................................................................................................141
3.4.4 Monitoring am X-WiN-Übergang .........................................................................141
3.4.5 Sicherheitswerkzeuge "Nyx" und "Nessi" .............................................................142
3.4.6 Virtuelle Firewalls .................................................................................................143
3.5
Projektarbeiten im Netzbereich 2010 .................................................................................143
3.5.1 D-GRID Projekt GIDS ..........................................................................................144
3.5.2 Customer Network Management ...........................................................................148
3.5.3 Géant E2E Link Monitoring ..................................................................................151
3.5.4 Géant I-SHARe .....................................................................................................152
3.5.5 Géant-Visualisierungswerkzeuge und Performance Monitoring...........................153
3.5.6 100GET-E3............................................................................................................156
Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen .......................................................159
4.1
Arbeitskreis Security ..........................................................................................................159
4.2
Arbeitskreis IT-Service-Management ................................................................................159
4.2.1 Aktivitäten im Bereich IT-Service-Management am LRZ ....................................160
4.2.2 Weitere Aktivitäten im Bereich IT-Service-Management .....................................161
4.3
Arbeitskreis Continuity ......................................................................................................161
4.4
Arbeitskreis Informationsmanagement ..............................................................................162
iii
Inhaltsverzeichnis
iv
5
Organisatorische Maßnahmen im LRZ ................................................................................... 163
5.1
Personalveränderungen 2010............................................................................................. 163
5.1.1 Zugänge ................................................................................................................ 163
5.1.2 Abgänge ................................................................................................................ 164
5.2
Gebäudemanagement und Gebäudebetrieb ....................................................................... 164
5.2.1 Erweiterung des LRZ (Rechner- und Institutsgebäude) ....................................... 165
5.2.2 Energieeffizienz .................................................................................................... 165
5.2.3 Personalausstattung der Hauswerkstätte ............................................................... 166
5.3
Dienstleistungskatalog....................................................................................................... 166
5.4
Mitarbeit in Gremien ......................................................................................................... 167
5.4.1 Abteilung „Benutzernahe Dienste und Systeme“ ................................................. 167
5.4.2 Abteilung „Hochleistungssysteme“ ...................................................................... 167
5.4.3 Abteilung „Kommunikationsnetze“...................................................................... 168
5.4.4 Abteilung „Zentrale Dienste“ ............................................................................... 168
5.5
Veranstaltungen am LRZ .................................................................................................. 168
5.6
Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen ..................... 169
5.6.1 Abteilung „Benutzernahe Dienste und Systeme“ ................................................. 169
5.6.2 Abteilung „Hochleistungssysteme” ...................................................................... 170
5.6.3 Abteilung „Kommunikationsnetze“...................................................................... 174
5.6.4 Abteilung „Zentrale Dienste“ ............................................................................... 175
5.7
Öffentlichkeitsarbeit .......................................................................................................... 176
5.8
LRZ als Ausbildungsbetrieb .............................................................................................. 177
5.9
Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten .................................... 177
5.10 Veröffentlichungen der Mitarbeiter 2010 .......................................................................... 178
6
Regelwerk des LRZ ................................................................................................................... 181
6.1
Satzung der Kommission für Informatik ........................................................................... 181
6.2
Mitglieder der Kommission für Informatik ....................................................................... 181
6.3
Benutzungsrichtlinien für Informationsverarbeitungssysteme .......................................... 181
6.4
Betriebsregeln des Leibniz-Rechenzentrums .................................................................... 181
6.5
Richtlinien zum Betrieb des Münchner Wissenschaftsnetzes (MWN) ............................. 181
6.6
Richtlinien zur Nutzung des Archiv- und Backupsystems ................................................ 181
6.7
Gebühren des Leibniz-Rechenzentrums ............................................................................ 181
6.8
Zuordnung von Einrichtungen zu LRZ-Betreuern ............................................................ 181
6.9
Betriebs- und Organisationskonzept für den Höchstleistungsrechner in Bayern (HLRB) 181
6.10 Nutzungs- und Betriebsordnung für den Höchstleistungsrechner in Bayern (HLRB) ...... 181
6.11 Mitglieder des Lenkungsausschusses des Höchstleistungsrechners in Bayern (HLRB) ... 181
7
Technische Ausstattung............................................................................................................. 183
7.1
Speicher ............................................................................................................................. 183
7.2
Rechner und Server ........................................................................................................... 184
7.2.1 Höchstleistungsrechner SGI Altix 4700 ............................................................... 184
7.2.2 Hochleistungs-Linux-Systeme .............................................................................. 185
7.2.3 Grid-Rechner ........................................................................................................ 188
7.2.4
7.2.5
7.3
Hochleistungs-Graphik-System .............................................................................188
Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner .......................................189
Netzkomponenten...............................................................................................................193
7.3.1 Router ....................................................................................................................193
7.3.2 Switches.................................................................................................................193
7.3.3 WLAN-Komponenten ...........................................................................................194
7.3.4 Netz-Server ............................................................................................................195
v
Jahresbericht 2010 des Leibniz-Rechenzentrums, Vorwort
1
Vorwort
Der Jahresbericht 2010 des Leibniz-Rechenzentrums (LRZ) der Bayerischen Akademie der Wissenschaften ist ein Beleg für das weitere quantitative und qualitative Wachstum dieser Einrichtung. ITDienstleistungen für Forschung, Lehre und Verwaltung werden für Kunden im Großraum München, in
Bayern, Deutschland und zunehmend auch international, vor allem in Europa, erbracht.
Besondere Schwerpunkte und neue Aufgabenstellungen des LRZ im Jahr 2010 waren insbesondere:
• Mit der Erweiterung der Rechner- und Institutsgebäude wurde Platz für den nächsten Höchstleistungsrechner SuperMUC, für ein neues Visualisierungs- und Virtual-Reality-Zentrum sowie für
neue Projektmitarbeiter – vor allem im Rahmen europäischer Projekte – geschaffen. Dabei wurde
besonderer Wert auf eine neuartige Infrastruktur für energieeffizientes (Super-)Computing gelegt,
das im Kontext der Beschaffung verschiedener Rechnersysteme zu einem neuen Themenschwerpunkt des LRZ wird. In Anwesenheit von Innenminister Joachim Herrmann konnte für die Gebäudeerweiterung am 18. Oktober mit zahlreichen prominenten Teilnehmern das Richtfest gefeiert werden.
• Mit der feierlichen Vertragsunterzeichnung zwischen LRZ und der Firma IBM GmbH wurde am
13.12.2010 eine 9-monatige intensive Auswahlphase für den neuen Höchstleistungsrechner SuperMUC im Rahmen eines Wettbewerblichen Dialogs erfolgreich abgeschlossen. In Anwesenheit
des Staatsministers Dr. Wolfgang Heubisch wurde ein Superrechner für das Gauss Centre for Supercomputing GCS e.V. als bayerischer bzw. deutscher Beitrag zur europäischen Infrastruktur
PRACE (Partnership for Advanced Computing in Europe) beschafft, der in der ersten Ausbauphase mit 3 PetaFlop/s (drei Billiarden Rechenoptionen pro Sekunde) zu den leistungsfähigsten
Rechnern der Welt zählen wird. Mit IBM wurde darüber hinaus eine wissenschaftliche Kooperation zum Thema Energieeffizienz vereinbart, die neben der Erprobung neuester Kühlungstechnik
auf Basis von Warmwasser auch spezielle Maßnahmen in Hardware und Software des Superrechners, sowie neue Betriebsstrategien umfasst. Das LRZ erprobt hier neue Techniken, die zukünftig vor allem in Hinblick auf hohe Energiekosten für weitere Bereiche des Rechnerbetriebs
von besonderer Bedeutung sind. Mehrere erfolgreich eingeworbene Drittmittelprojekte unterstützen diese Arbeiten des LRZ in den nächsten Jahren, die in enger Kooperation mit internationalen
Partnern, vor allem aber mit Lehrstühlen der Ludwig-Maximilians-Universität München und der
Technischen Universität München, durchgeführt werden.
• Durch die Stiftung für Hochschulzulassung, Dortmund, wurde das LRZ beauftragt, den Infrastrukturbetrieb und das Managed Hosting des „Dialogorientierten Serviceverfahrens“ für die
bundesweite Vergabe von Studienplätzen zu übernehmen. Nach der Konzeption und Beschaffung
der entsprechenden Hard- und Software-Konfigurationen konnte im Herbst bereits der Testbetrieb der Anwendung begonnen werden, die von der Fa. T-Systems MMS erstellt wurde. Die Beauftragung dieser weiteren überregionalen Aufgabe erfolgte zunächst bis 31. März 2012.
Den Mitarbeiterinnen und Mitarbeitern des LRZ möchte ich für ihre engagierte Arbeit danken. Mein besonderer Dank gilt aber auch der Leitung der Bayerischen Akademie der Wissenschaften, den zuständigen Ansprechpartnern im Bayerischen Staatsministerium für Wissenschaft, Forschung und Kunst sowie
den Mitgliedern des HLRB-Lenkungsausschusses und der Kommission für Informatik, die die Arbeit des
LRZ mit konstruktiver Kritik stets fachkundig unterstützt haben.
Persönlich danke ich insbesondere den Mitgliedern des Direktoriums des LRZ, den Kollegen H. J.
Bungartz, D. Kranzlmüller und H.-G. Hegering, die ihre große Fachkompetenz in die Leitung des LRZ
mit eingebracht haben. Der vorgelegte Jahresbericht geht wieder bewusst über das Zahlenwerk üblicher
Jahresberichte hinaus. Wir versuchen wie in den letzten Jahren, viele unserer Dienste und Geschäftsprozesse zu erklären und unsere Konventionen und Handlungsweisen zu begründen. Dies soll die Komplexität unserer Aufgabenstellung und das LRZ als Institution transparenter machen. Das LRZ nimmt aufgrund
seiner Größe und Organisationsform, 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 eng im Hochschulumfeld verankert sein. Das LeibnizRechenzentrum als das technisch-wissenschaftliche Rechenzentrum für die Münchner Hochschulen wird
2
Vorwort
sich auch in Zukunft den Anforderungen eines modernen IT-Kompetenzzentrums stellen, und das nicht
nur durch den zuverlässigen Betrieb von IT-Infrastruktur, sondern auch durch aktive Beteiligung an 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 bin überzeugt davon, dass es dem LRZ auch im Jahr 2010 erneut gelungen ist, die Erwartungshaltung
seiner Nutzer einerseits, aber auch seiner Finanzgeber andererseits zu erfüllen und seine Dienstqualität
und IT-Kompetenz erneut zu steigern. Ich freue mich auf die Zusammenarbeit mit Ihnen und die weitere
Entwicklung im Jahr 2011.
Univ.-Prof. Dr. Arndt Bode
Vorsitzender des Direktoriums
des Leibniz-Rechenzentrums
3
1 Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste
und Systeme (BDS)
1.1
Kurse und Veranstaltungen
Das LRZ bietet seinen Kunden regelmäßig mehr als 20 Kurse an, die sich in die Bereiche PCs und PCSoftware, UNIX/Linux, Internet, Hochleistungsrechnen und weitere Veranstaltungen einteilen lassen. Die
in den Tabellen 1 bis 5 aufgeführten Veranstaltungen wurden von ca. 900 Teilnehmern besucht. Zusätzlich boten externe Anbieter weitere Kurse an, so dass die Gesamtteilnehmerzahl weit über 1.000 liegt.
1.1.1 Kursübersicht, Statistik 2010
Wie schon in den vergangenen Jahren wurden die Kurse gut angenommen, die vom LRZ zum Thema
Hochleistungsrechnen angeboten wurden. Bei der Planung konnte stets davon ausgegangen werden, dass
alle Teilnahmewilligen, die einen Platz im Kurs erhalten, diesen auch wahrnehmen würden. Dies darf
beim übrigen Kursangebot leider nicht als selbstverständlich vorausgesetzt werden. Gerade bei den Kursen zu PCs und PC-Software ist der Unterschied zwischen der Zahl der Anmeldungen und der Zahl der
Teilnehmer nach wie vor groß. Dies hat hohen Verwaltungsaufwand für diese Kurse zur Folge, müssen
doch bei jeder Absage auf einen erteilten Kursplatz wieder alle organisatorischen Schritte für die Nachrücker durchlaufen werden.
Es zeigte sich, dass das Interesse an Kursen zu den aktuellen Microsoft Office-Produkten nach wie vor
groß war. 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.
Auf eine gedruckte Version des Kursprogramms wird seit 2010 verzichtet. Dies ermöglicht eine schnelle
Aktualisierung, falls Kurse kurzfristig abgesagt werden müssen bzw. zusätzliche stattfinden. Auf den
WWW-Seiten des LRZ ist immer die aktuellste Version zu finden.
Viele PC-Kurse verwenden als Kursunterlage Handbücher vom RRZN in Hannover. Diese Schriften sind
oftmals verbilligte Nachdrucke der Schulungsunterlagen vom Herdt-Verlag. Die Ersparnis ist besonders
für Studenten von Bedeutung. Eine regelmäßig aktualisierte Liste der verfügbaren Schriften ist ebenfalls
im Internet vorhanden.
Kurse zu PCs und PC-Software
2010
Dauer
Kurstitel
Anzahl
Stunden
Teilnehmer
Teilnehmer
(Stunden) Kurse insgesamt angemeldet teilgenommen
Textverarbeitung mit Word 2007 (Kompaktkurs)
10
5
50
170
140
Word 2007 lange Dokumente, wiss. Arbeiten
12
2
24
40
22
MS-Excel 2007 (Kompakt- u. Fortsetzungskurs)
10
9
90
290
220
9
2
18
60
35
Photoshop CS (Einsteigerkurs)
16
2
32
105
31
Access 2007
12
5
60
60
46
8
2
16
50
35
77
27
290
775
529
PowerPoint 2007 (Kompaktkurs)
SPSS (Spezialkurs)
Insgesamt:
Tabelle 1: Kurse zu PCs und PC-Software
Entwicklungen und Tätigkeiten im Bereich Benutzernahe Dienste und Systeme (BDS)
4
Unix-Kurse und Praktika
2010
Dauer
Kurstitel
Anzahl
Stunden
Teilnehmer
Teilnehmer
Einführung in die Systemverwaltung unter Unix
65
1
65
21
21
Insgesamt:
65
1
65
21
21
Tabelle 2: Kurse zum Themenbereich Unix
Auch im Jahr 2010 wurde - zusätzlich zum regulären Kursprogramm - die vorhandene, moderne Infrastruktur im Hörsaal, den Seminar- und Kursräumen für andere Veranstaltungen genutzt. Softwarefirmen
hatten die Gelegenheit, neue Produkte bzw. neue Versionen bekannter Produkte zu präsentieren. Dabei
standen wieder Beispiele für die Nutzung in Forschung und Lehre im Vordergrund.
Internet
2010
Kurstitel
Dauer
Anzahl
(Stunden)
Kurse
3
1
3
14
11
3
1
3
14
11
Barrierefreies Webdesign
Insgesamt:
Stunden
Teilnehmer
Teilnehmer
insgesamt angemeldet
teilgenommen
Tabelle 3: Kurse zum Thema Internet
Hochleistungsrechnen
2010
Dauer
Kurstitel
Anzahl
Stunden
Teilnehmer
Teilnehmer
Debugging serial and parallel applications with
Allinea DDT
5
1
5
12
11
Data Mining of XML Data Sets using R
7
1
7
6
6
Eclipse: C/C++ programming (with a slight
Fortran touch)
9
1
9
13
11
Advanced Fortran Topics
45
1
45
15
13
GPGPU Programming
21
1
21
32
27
Introduction to Molecular Modeling on Supercomputers
14
1
14
16
11
Einführung in C++ für Programmierer
45
1
45
33
26
3
2
6
22
16
High-Performance Computing with GPGPUs
21
1
21
21
17
Parallel Programming with Cilk
18
1
18
15
13
Parallel Programming with R
7
1
7
6
5
Scientific High-Quality-Visualisation with R
7
1
7
10
8
Visualisation of Large Data Sets on Supercomputers
7
1
7
8
8
Insgesamt:
209
14
212
209
172
Introd. to the Usage of High Perf. Systems,
Remote Visual. and Grid Facilities at LRZ
Tabelle 4: Hochleistungsrechnen
5
Weitere Veranstaltungen
2010
Dauer
Kurstitel
Anzahl
Stunden
Teilnehmer
Teilnehmer
Train the Trainer
7
2
14
21
11
Einführung in das Archiv- u. Backupsystem am
LRZ
7
1
7
100
100
Professioneller IT-Betrieb in mittleren und großen Umgebungen
3,5
1
3,5
40
25
Insgesamt:
17,5
4
24,5
161
136
Tabelle 5: Weitere Kurse
1.1.2 Vorträge „Schattenseiten des Internet“
Die große Zahl der gemeldeten und selbst entdeckten Missbrauchsfälle (siehe Kapitel 1.9) zeigt, dass das
Sicherheitsbewußtsein im Bereich der virtuellen Welt des Internet noch deutlich besser werden muss.
Deshalb veranstaltet das LRZ regelmäßig den Vortrag „Schattenseiten des Internet – Praktische Tipps zur
Vermeidung von Gefahren“ vor Teilnehmern des Münchner Wissenschaftsnetzes (weitere Details und die
Handouts der Vortragsfolien siehe www.lrz.de/services/security/gefahren/).
Abbildung 1: Themenbild des Vortrags
Außerdem bietet das LRZ diesen Vortrag im Rahmen seiner Öffentlichkeitsarbeit Schulen und anderen
interessierten Einrichtungen an. Dies ist möglich, da sich der Vortrag an Einsteiger auf dem Gebiet der
Internet-Sicherheit richtet. Für Eltern und Lehrer einerseits und Jugendliche ab 12 Jahren andererseits
6
stehen angepasste Varianten zur Verfügung. Die beiden Schwerpunkte des Vortrags behandeln Problembereiche, die Kinder, Jugendliche und Erwachsene gleichermaßen betreffen:
• In den letzten beiden Jahren wird das Thema „Abzocker im Internet“ relativ häufig in Presse und
Fernsehen behandelt. Dennoch fallen allein in Deutschland jährlich mehrere Hunderttausend Internet-Nutzer auf die vielen unseriösen Angebote herein. Etwa 40% der Opfer kennen ihre Rechte zu
wenig und zahlen deshalb die geforderten Beträge zwischen 60 und 200 Euro, obwohl dies überhaupt
nicht erforderlich wäre.
• Alle Nutzer des Internet unterliegen mehr oder weniger umfangreichen rechtlichen Pflichten. Ein
Verstoß dagegen (z.B. gegen das Urheberrecht) kann mehrere Tausend Euro kosten! Leider kennen
praktisch keine Jugendlichen und nur wenige Erwachsene diese Art von Gefahren.
Im Jahr 2010 wurden durch diesen Dienst des LRZ mehr als 1300 interessierte Zuhörer erreicht (Schulklassen und Eltern an mehreren Gymnasien).
1.2
Software-Versorgung für Rechnersysteme außerhalb des LRZ
Das LRZ liefert seinen Kunden Software-Lizenzen zu günstigen Konditionen. Mit der Bündelung der
Nachfrage über Instituts- und Hochschulgrenzen hinweg wird auch Verhandlungsmacht gebündelt. So
können oft wesentlich günstigere Konditionen für den Bezug von Lizenzen für Forschung und Lehre erreicht werden. Die Endkunden in den Instituten sparen dadurch nicht nur Zeit, sondern vor allem viel
Geld. Das LRZ verhandelt deswegen, wo möglich, in Absprache oder in Kooperation mit Instituten und
Hochschulen, teilweise auf das Münchner Wissenschaftsnetz (MWN) beschränkt, teilweise überregional,
geeignete Abkommen mit Händlern und Herstellern. Welche Software von welchen Nutzern zu welchen
Konditionen über das LRZ bezogen werden kann, ist auf der Webseite www.lrz.de/services/swbezug
dargestellt.
Tabelle 6 listet die wertmäßig umsatzstärksten Softwarepakete (nur Kauflizenzen) auf. Miet- und Subskriptionsmodelle (SPSS, Matlab, Novell, SAS) sowie Pauschal-Verträge (ESRI, Sophos) werden nicht in
dieser Tabelle erfasst. Die Zahlen zu Microsoft und Adobe sind geschätzt (die exakten Zahlen gehen über
die Kalenderjahresgrenzen hinweg).
Hersteller / Name
Beschreibung
Lizenzzahlen 2010
Bruttowert der 2010
beschafften Lizenzen
Microsoft
Applikationen, System- und ServerSoftware
28.000
Ca. 899.000 €
Adobe
Acrobat, Photoshop,
GoLive, Illustrator,
Premiere etc.
3.000
Ca. 474.000 €
Corel
Grafiksoftware
325
15.303,- €
Endnote
Literaturverarbeitung
393
42.061,74 €
Systat
Datenanalyse und
Datenpräsentation
42
14.025,- €
Tabelle 6: Die umsatzstärksten Softwarepakete
1.2.1 Landesweiter ESRI Vertrag
In Kooperation mit der FH Würzburg-Schweinfurt und der Universität Würzburg konnte ein landesweiter
Vertrag mit der Firma ESRI (ArcGis Geoinformationssysteme) abgeschlossen werden, in den die bestehenden Verträge der bayerischen Hochschulen und Unikliniken integriert werden konnten (auch der
Campusvertrag für das MWN wird zu gleichbleibenden Konditionen in den neuen Vertrag überführt).
7
Wichtigster Vorteil ist, dass nun auch kleine Hochschulen Lizenzen zu sehr günstigen Konditionen beziehen können. Außerdem werden dadurch Administration und Abrechnung vereinfacht, und somit Hochschulmitarbeiter entlastet. Neben dem LRZ versorgen sich nun elf weitere Hochschulen über diesen Vertrag. Für alle anderen Hochschulen und Unikliniken in Bayern besteht die Option zur späteren Teilnahme
zu definierten Konditionen.
1.2.2 Landesweiter Secunia Vertrag
In Kooperation mit u. a. der Universität Augsburg konnte ein landesweiter Vertrag mit der Firma Secunia
abgeschlossen werden, der elf Hochschulen die Nutzung der gleichnamigen Produktpalette zu einem pauschalen, sehr günstigen Preis ermöglicht. Secunia ist ein Schwachstellen- und Patchscanner, der installierte Programme identifiziert und fehlende Sicherheitspatches für Windows-Betriebssysteme und -Anwendungen aufzeigt.
1.2.3 Weitere neue oder geänderte Verträge
Im Berichtsjahr stand die Neuverhandlung von Verträgen für die Produkte Mathematica (MWN, Vertragspartner Additive), Amira (MWN, Vertragspartner VisageImaging), CoCreate (MWN, Vertragspartner Parametric Technology PTC) an. Die neu verhandelten Verträge bieten den Kunden des LRZ
insgesamt sehr günstige Konditionen.
1.2.4 Routinemäßige Verlängerung bestehender Verträge
Routinemäßig verlängert wurden u. a. der Adobe CLP Rahmenvertrag (bundesweit gültig), Mietverträge
zu SPSS (Großteil der bayerischen Hochschulen), Ansys, LabView, Matlab, und SAS (alle MWN-weit).
Für Adobe-Produkte musste das LRZ im Frühjahr den Handelspartner für die Versorgung des MWN
wechseln, da der bisherige Händler erheblich höhere Preise durchsetzen wollte. So konnten den versorgten Instituten empfindliche Preiserhöhungen erspart werden.
1.2.5 Status Microsoft Select-Plus Lizenzen
Die im Sommer 2009 abgeschlossenen Select-Plus Rahmenverträge brachten für die bayerischen Hochschulen, Universitäten und Unikliniken einige Änderungen in der Verwaltung u. a. der Lizenzschlüssel
mit sich. Hier war das LRZ beratend tätig, und hat zwischen den Einrichtungen und Microsoft vermittelt,
um die neuen Abläufe zu definieren und zu verstetigen. Das LRZ hat darüber hinaus 2010 einen so genannten KMS Server für die akademischen Einrichtungen des MWN eingerichtet, um die lokalen Administratoren bei der Aktivierung von Microsoft Installationen zu entlasten.
1.2.6 Betrieb von Lizenzservern für externe Systeme am LRZ
Das LRZ betreibt derzeit ca. 30 Lizenzserver, die für die Benutzer im MWN Netzwerklizenzen zur Verfügung stellen. Das angebotene Spektrum der Netzwerklizenzen beinhaltet vor allem technisch wissenschaftliche Software (Matlab, Mathematica, Maple, Ansys, Patran, ...). Der Betrieb von Lizenzservern am
LRZ erspart den Mitarbeitern in den Instituten den dezentralen und redundanten Aufbau eigener Server
und damit viel Arbeit.
1.2.7 Verträge mit Instituten im MWN
Im Sommer wurde ein Vertrag mit der Fakultät für Geowissenschaften der LMU geschlossen, der die
Versorgung der Institute dieser Fakultät mit ArcGis Produkten der Fa. ESRI vereinfacht und verbessert
(Flatrate für die gesamte Fakultät statt Einzelabrechnung nach Produkten und Lehrstühlen).
1.2.8 Laufende Verhandlungen und Planungen
Mit der Universität Würzburg wird die Verlängerung des bayernweiten Rahmenvertrags für Microsoft
Mietlizenzen (bekannt als "Microsoft Campus", heißt künftig „Enrollment for Education Solutions“) für
8
2011 vorbreitet, dafür und für die im Vorjahr geschlossenen Microsoft Select-Plus Rahmenverträge
(Kauflizenzen) werden Händlerausschreibungen (mit Würzburg als Vergabestelle) vorbereitet.
Gemeinsam mit dem Regionalen Rechenzentrums Erlangen (RRZE) arbeitet das LRZ an einem SPSS
Landesvertrag. Das ist erforderlich, da IBM, der neue Eigentümer der Firma SPSS, die bisherigen Mietverträge nicht verlängern wird, die SPSS separat jeweils mit dem RRZE und dem LRZ geschlossen hatte.
1.2.9 Zusammenfassung
Die umsatzstärksten Softwarepakete im letzten Jahr waren:
• Microsoft-Lizenzen im Rahmen der Select-Plus-Verträge
• Adobe- und Corel-Bestellungen im Rahmen des CLP-Vertrags
Bei Microsoft und Adobe/Corel-Bestellungen kümmert sich das LRZ im Tagesgeschäft lediglich um 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. 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: hier sind derzeit die höchsten Wachstumsraten zu verzeichnen. Da das LRZ hier einen
zentralen Lizenzserver für das MWN betreibt (und Lehrstühle bzw. Institute individuell abrechnet), ist allerdings auch der administrative Aufwand im Berichtszeitraum empfindlich gestiegen.
Der Umsatz im MWN erreichte 2010 ca 100.000 Euro.
• Bei etlichen weiteren Produkten lagen die Umsätze im fünfstelligen Bereich.
Für Einrichtungen mit zentralem Einkauf besteht die Möglichkeit, die am meisten nachgefragten Softwarelizenzen online zu bestellen. Hierzu zählen die Münchner Universitätskliniken mit ihrem jeweiligen
Zentraleinkauf, die Universität Augsburg, einige Fachhochschulen aus dem südbayerischen Raum sowie
einige kleinere Einrichtungen.
Darüber hinaus werden einige hundert Lehrstühle, Arbeitsgruppen und Institute im MWN durch das LRZ
individuell mit diversen Lizenzen versorgt, betreut und beraten.
Novell- und Sophos-Produkte (künftig auch ESRI- und Secunia-Produkte) werden den bayerischen Universitäten und Hochschulen nach einem festen Kostenschlüssel bereitgestellt, daher gibt es an dieser Stelle keine Umsatzzahlen (die ESRI-Produkte werden auf Campusebene mit den Instituten abgerechnet).
1.3
Benutzerverwaltung und Verzeichnisdienste
Bei der Vergabe von Kennungen an Hochschuleinrichtungen und Studenten arbeitet das LRZ sehr eng
mit den beiden Münchner Universitäten zusammen. Abschnitt 1.3.1 gibt einen Überblick über die derzeit
vergebenen Kennungen und ihre Verteilung auf die LRZ-Plattformen. In Abschnitt 1.3.2 wird die Weiterentwicklung des LRZ-Identity-Management-Systems (LRZ-SIM) beschrieben, dessen Datenbasis und
Konfiguration komplett auf LDAP-Verzeichnisdiensten basiert. Die an LRZ-SIM angebundenen Dienste
und deren Nutzer profitieren dabei von der direkten Kopplung mit den LMU- und TUM-seitigen Hochschulverzeichnisdiensten. Die für die TUM am LRZ entwickelte Verzeichnisdienst-Infrastruktur, ihren
Regelbetrieb und ihre Fortentwicklung beschreibt Abschnitt 1.3.3. Ein weiteres sehr dynamisches Arbeits- und Forschungsgebiet ist die Authentifizierungs- und Autorisierungsföderation des DFN (DFNAAI), in der das LRZ als Dienstleister und sogenannter Identity-Provider für die LMU und TUM fungiert
und hochschulintern wie auch föderationsweit an der Gestaltung aktiv mitwirkt (Abschnitt 1.3.4).
1.3.1 Für LRZ-Systeme vergebene Kennungen
1.3.1.1
An Hochschuleinrichtungen vergebene Kennungen
Die folgende Tabelle gibt einen Überblick über die vom LRZ an Hochschuleinrichtungen (via Master
User) vergebenen Kennungen, und zwar pro Dienst bzw. Plattform und mit Stand von Ende 2010.
9
Mail
Exchange
Sun- LinuxCluster Cluster
Einrichtung
VPN
Bayerische Akademie der Wiss. (ohne LRZ)
Ludwig-Maximilians-Universität München
Technische Universität München
Hochschule München
andere bayerische Hochschulen
Öffentlich-rechtliche Einrichtungen
sonstige Einrichtungen
Kooperationsprojekte aus dem Grid-Bereich
Nutzer des Bundeshöchstleistungsrechners
647 1.020
367
370
10.880 10.220
8.487 8.677
424
392
388
280
2.879 2.866
28
1
–
–
14
3
130
43
278
4.561
–
–
–
–
–
–
314
44
755
827
97
32
155
2
–
–
312
41
720
810
94
27
153
2
–
–
176
–
792
688
40
140
20
12
879
233
1.065
337
1.313
438
8
169
402
1
–
–
Gesamt
24.114 23.829
5.012
2.226
2.159
2.980
3.733
AFS
PC
Tabelle 7: Vergabe von Kennungen für LRZ-Plattformen
Für die TU München werden Exchange-Berechtigungen direkt über TUMonline vergeben, nicht über die
Master-User-Schiene.
Nicht in der Tabelle enthalten sind die Kennungen für den Bundeshöchstleistungsrechner, die SGI Altix
4700, da es hier häufig Kooperationen gibt und daher keine klare Zuordnung zu einer Einrichtung möglich ist. Ende 2010 waren für diesen Rechner insgesamt 2.536 Kennungen vergeben, davon 1.167 für
Projekte aus dem Grid-Bereich.
1.3.1.2
An Studenten vergebene Kennungen
Die Vergabe von Kennungen an Studenten erfolgt bei der Ludwig-Maximilians-Universität und bei der
Technischen Universität gekoppelt mit der Vergabe von Kennungen für das Web-Portal CampusLMU bzw.
das Campus-Management-System TUMonline. Für Studenten anderer Münchner Hochschulen erfolgt die
Vergabe individuell und direkt durch das LRZ.
Ende 2010 hatten knapp 85.000 Studenten (Vorjahr: ca. 82.000) eine Kennung, die u.a. für Mailzwecke
und für den VPN-Zugang ins MWN genutzt werden konnte. Hier die Aufteilung auf die Hochschulen mit
den meisten Kennungen:
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
51.903
31.248
1.042
205
105
42
20
20
16
78
Gesamt
84.679
Tabelle 8: Vergabe von Kennungen an Studenten
10
1.3.2 LRZ Secure Identity Management (LRZ-SIM)
Das neue zentrale LRZ Identity&Access-Management-System (IDM) mit dem Projektnamen LRZ-SIM
(„LRZ Secure Identity Management“) lief in seinem mittlerweile dritten Einsatzjahr stabil und zuverlässig. Die Flexibilität seiner Architektur zeigte sich bei der Programmierung vieler weiterer Automatismen
und Optimierungen für die Benutzerverwaltungsprozesse, die für erhöhten Benutzerkomfort, weniger
manuelle Erfassungsarbeit sowie auch für eine weitere Verbesserung der Datenqualität, Datenaktualität
und Datensicherheit sorgen. Die internen Strukturen und Betriebsabläufe wurden laufend weiterentwickelt und optimiert und eine Reihe weiterer LRZ-Systeme über LDAP-Authentifizierung oder Provisionierung von Benutzerdaten angebunden.
Um die zentrale Benutzerverwaltung weiter zu automatisieren, den manuellen Aufwand durch Mehrfachregistrierung und -pflege von Benutzern zu vermeiden und um Redundanzen und Inkonsistenzen weitest
möglich zu reduzieren, ist der Import von Benutzerdaten der beiden großen Münchener Universitäten und
ihren Berechtigungen weiter vorangebracht worden. Die Übernahme der Daten aus dem zentralen Verzeichnis der Ludwig-Maximilians-Universität (LMU) ist schon seit Längerem im Einsatz. Bei den Mitarbeiterdaten sind fakultätsweise nach individuellen Vereinbarungen weitergehende Datenimporte einzurichten. Die Anbindung an die TUM-Directorys ist nach intensiver Testphase gut vorbereitet, und wird
Anfang 2011 in Produktionsbetrieb gehen. Dabei werden dann alle TUM-Benutzer mit allen LRZrelevanten Berechtigungen in einem Zug nach LRZ-SIM übernommen werden können.
1.3.2.1
Überblick und aktueller Stand der Identity-Management-Architektur
Während die IDM-Kernarchitektur, wie sie im März 2008 in Produktionsbetrieb ging, beibehalten wurde,
gab es 2010 im Detail etliche Weiter- und Neuentwicklungen, sowohl beim Datenmodell als auch besonders beim LRZ-Identity-Management-Portal (Id-Portal), bei den angeschlossenen Datenquellen, bei den
Konnektoren und bei den angebundenen Systemen.
Abbildung 2 zeigt die aktuelle logische Struktur des IDM-Systems mit seinen Erweiterungen und Änderungen bis Ende 2010. Die einzelnen Verzeichnisdienste erfüllen mit einem für den jeweiligen Zweck
optimierten Datenschema unterschiedliche Aufgaben:
• Der Authentifizierungs-Satellit dient der Anbindung der vielfältigen LRZ-Dienste über LDAPAuthentifizierung und -Autorisierung.
• Der Applikations-Satellit ist Datenbasis für das Id-Portal mit Management-Funktionalität sowie
für LRZ-Plattformen mit Bedarf an Attributen, der über den Umfang des AuthentifizierungsSatelliten hinausgeht.
• Der Import-Export-Satellit regelt den Datenaustausch mit den beiden Münchner Universitäten
sowie auch mit der LRZ-Personaldatenbank.
• Das Metadirectory im Zentrum koordiniert den Abgleich der Datenbestände über Konnektoren
(dicke Pfeile).
• Ein durch die Diversifizierung der LRZ-Maildienste und -systeme notwendig gewordenes Mailforwarder-Verzeichnis ist Grundlage für die Annahme und Bearbeitung von E-Mails (Zustellungen, Weiterleitungen und Abwesenheitsnotizen).
• Neu hinzugekommen ist die Provisionierung eines zweiten Active Directorys für den EduroamDienst des DFN sowie Server für Webservices, über die momentan die Vergabe von LRZKennungen und Mailadressen kanalisiert wird.
Alle Verzeichnisse sind redundant und hochverfügbar implementiert. Angeschlossene Systeme können
über LDAP-Verbindungen direkt die Datenbestände in den Verzeichnissen nutzen (dünne Pfeile) oder
auf höherer Ebene die Webservices über SOAP-Requests ansprechen.
11
Abbildung 2: Architekturmodell und Integration des LRZ-Identity-Managements
1.3.2.2
Entwicklungen im Server- und Dienstbetrieb
Die umfangreiche produktive Server-Infrastruktur innerhalb von LRZ-SIM erforderte eine kontinuierliche
Aktualisierung der eingesetzten Software, um bei Releases und Patches auf dem aktuellen Stand zu bleiben, und zwar sowohl auf Betriebssystem-Ebene (SuSE Linux), auf Verzeichnisdienst-Ebene (Novell
eDirectory und OpenLDAP) als auch auf IDM-Ebene (Novell Identity Manager, iManager und Designer).
Um den unterbrechungsfreien Betrieb dauerhaft gewährleisten zu können, wurde der SoftwareLoadbalancer-Rechner dupliziert und mit einer aktuelleren Version samt Webfrontend ausgestattet. Alle
Konnektoren sind in Standby-Konfiguration auf jeweils einem weiteren Rechner installiert und können
bei Ausfall des Hauptservers, dessen Directory-Services oder dessen Konnektoren rasch für die Fortführung des Datenaustauschs aktiviert werden.
Parallel zu den Produktionsservern wurde auch die Testumgebung kontinuierlich auf dem aktuellen
Stand gehalten. Alle Testserver wurden virtualisiert und schrittweise mit neuen Versionen von Betriebssystem, Verzeichnisdienst- und IDM-Software ausgestattet. Sehr bewährt hat sich das Vorgehen, alle
Erweiterungen im Id-Portal und Neuimplementierungen von Konnektoren durchwegs zuerst in der Testumgebung zu entwickeln und dort ausführlich mit Real-Life-Datensätzen zu erproben.
Ein Schwerpunkt der Arbeit lag im Bereich IT-Sicherheit. Auf den LDAP- und Webservern von LRZSIM kommen nun durchwegs DFN-signierte Serverzertifikate zum Einsatz. Kontinuierliche Betriebssystem- und Serversoftware-Updates sorgen für die Basissicherheit. Neben selbst programmierten dedizierten Überwachungstools wurde das zentrale Monitoring mit Cacti und Nagios auf alle zentralen Server,
Konnektoren und Dienste ausgedehnt. Schließlich erfolgte eine unabhängige Sicherheitsüberprüfung des
Id-Portals durch das Bayern-CERT.
12
Schließlich konnte die Domain-Umstellung von lrz-muenchen.de auf lrz.de (für internetweit erreichbare
Server) bzw. sim.lrz.de (für Server, die nur aus dem LRZ- oder Münchner Wissenschaftsnetz erreichbar
sind) für alle Testrechner, Webserver und Shibboleth-Server durchgeführt und für die produktiven LDAPServer vorbereitet werden. Für den nahtlosen Übergang wurden sowohl in den neu beantragten Zertifikaten als auch im DNS die Namen mit den alten Domains als Aliase mitgeführt.
1.3.2.3
Identity Management und zentrale Benutzerverwaltung
Das Id-Portal ist die nach außen am deutlichsten sichtbare Komponente der LRZ-Benutzerverwaltung
und ermöglicht nicht nur Master Usern, alle Aufgaben rund um die Verwaltung der ihnen zugeteilten
Kennungen effizient zu erledigen, sondern dient auch als Self-Service-Oberfläche für alle Benutzer. Viele
Funktionen des Id-Portals konnten im Detail verbessert und benutzerfreundlicher gestaltet werden, nicht
zuletzt auch durch das Feedback aus der täglichen Benutzungspraxis durch die LRZ-Hotline, die LRZAdministratoren, die LRZ-Betreuer und die Master User.
Zusätzlich zum Id-Portal, dem Webserver für interaktiven Zugang, wurde ein Server für sogenannte
Webservices aufgesetzt, die im Rahmen des automatischen Datenaustauschs insb. mit TUM und LMU
erforderlich waren. Über reine LDAP-Anfragen hinaus sind hier Dienste mit mehr serverseitiger Programmlogik möglich, wie sie für die Generierung von Kennungen oder die Abfrage möglicher freier EMail-Adressen notwendig ist.
Auch bei der Datenqualität der in LRZ-SIM verwalteten Einträge konnten durch vielfältige Maßnahmen
Verbesserungen erzielt werden: Die Sammlung von Skripten zur Überprüfung des Datenbestands innerhalb eines Directorys sowie zwischen verschiedenen Directorys bzw. zwischen Directorys und angeschlossenen Plattformen wurde ständig erweitert. Die Überprüfungen zur Datenkonsistenz erwiesen sich
insbesondere auch bezüglich der automatisch importierten Benutzerdaten als hilfreich, da neben TUMund LMU-Konnektoren auch Daten der Grid-User-Administration (GUA) direkt per LDAP in LRZ-SIMVerzeichnisse geschrieben werden. Damit erfolgt die Eintragung dieser Grid-Benutzerdaten ohne erweiterte Prüfung, wie sie sonst über das Id-Portal, die IDM-Konnektoren oder die Webservices möglich sind.
Zu nennen sind hier die internen LRZ-IDs, die die Softreferenzen wechselseitig zwischen Kennungs-,
Personen-, Projekt- und Organisationsobjekten bilden und deren Konsistenz nicht vom LDAP-Server
erzwungen werden kann.
1.3.2.4
Integration von LRZ-Diensten und Plattformen
Im Laufe des Jahres konnten einige weitere LRZ-Dienste und -Plattformen erfolgreich an die LRZ-SIMVerzeichnisse angebunden und ins zentrale Identity&Access-Management integriert werden. Darunter
befanden sich Systeme mit sehr großer Benutzerzahl wie die Mail- und Groupware-Plattform Exchange
2010. Neu hinzu kam die Anbindung folgender Dienste:
• Die neue, zentrale LRZ-IT-Service-Management-Plattform (iET) verwendet LDAPAuthentifizierung und importiert Benutzerdaten per LDAP. Gespräche für spezielle Workflows
wie die Bestellung von virtuellen Servermaschinen und die dafür notwendigen Attribute haben
stattgefunden.
• Für das bereits an LRZ-SIM angebundene Netzverantwortlichenportal NeSSI wurden diejenigen
Netzverantwortlichen ermittelt, die noch keine LRZ-Kennung hatten. Die Berechtigungsvergabe
selbst und der Workflow in der Netzabteilung werden SIM-seitig mit einem eigens entwickelten
Webfrontend unterstützt.
• Ein Kernsystem des LRZ-Betriebs, das Netzkomponenten-Management für Switches, Router und
Gateways, wurden auf LDAP-Authentifizierung umgestellt. Dedizierte Gruppen zur Autorisierung auf einzelnen Komponenten sind ebenfalls über SIM-Attribute realisiert.
• Das Monitoring-System Cacti war bereits als Plattform in LRZ-SIM aufgenommen. Umgekehrt
wurde die Kopplung soweit ausgedehnt, dass für die LRZ-SIM-Verzeichnisdienste die LDAPAntwortzeit – eine wichtige und kritische Größe für nahezu alle angebundenen Systeme – in den
Cacti-Graphen online darstellbar ist.
• Jedes Projekt kann für die Nutzung des Backup- und Archivsystems TSM freigeschaltet werden,
Master User können selbst Kennungen zur TSM-Nutzung berechtigen. Details des Vergabeprozesses wurden verbessert, so dass z.B. auch bei der Deprovisionierung die Löschung von Kennungen mit aktiven TSM-Knoten verhindert wird.
• Mailattribute wurden nach Mandanten und Mailsystemen (TUM, LMU-Studenten, LMU-
•
•
•
•
•
13
Weiterleitungen, externe Studenten und über Master User verwaltete Benutzer) getrennt und können an Kennungen, die mehrfache Rollen erfüllen, auch entsprechend mehrfach vergeben werden.
Die Provisionierung des zentralen Microsoft Active Directorys (MWN-ADS) wurde auf einen
neuen Konnektor umgestellt (Novell Scripting Driver), mit dem auch Exchange-spezifische Vorgänge angestoßen werden können. Damit wurde die Voraussetzung für die Produktivführung von
Microsoft Exchange für LRZ-Kunden (insb. die LMU) geschaffen. Weiterleitungsadressen und
Abwesenheitseinstellungen wurden nach LRZ-SIM geholt, werden nun dort verwaltet und in ein
eigenes Forwarder-Directory provisioniert.
Für Eduroam, das System für komfortable europaweite VPN-Verbindungen, wurde ein weiteres,
lizenztechnisch günstig zu betreibendes Active Directory aufgebaut, das ebenfalls direkt aus
LRZ-SIM per Scripting Treiber befüllt wird.
In Zusammenarbeit mit der Gruppe HLR wurde der Workflow und das Webformular zur Beantragung von Linux-Cluster-Berechtigungen grundlegend neu gestaltet, um die Beantragung bei
den Master Usern zu bündeln und die manuelle Verwaltungsarbeit auf einen Genehmigungsklick
zu reduzieren.
Für die High-Performance-Computing-Plattformen wurde die Provisionierung der HPCDatenbank (MySQL) auf die relevanten Benutzerkennungen reduziert und damit eine deutliche
Erhöhung der Aktualisierungsfrequenz möglich. Darüber hinaus regelt ein neuer Prozess das Löschen von HPC-Projekten, unterstützt durch neue Attribute im Verzeichnis und neue Spalten in
der HPC-Datenbank, um dauerhaft die Zuordnung von Kennungen auch zu ehemaligen Projekten
verfolgen zu können.
Die Integration von Grid-Kennungen wurde vorbereitet und prototypisch für einen Teil der DEISA-Kennungen durchgeführt. Die Teilnahme an den Grid-Verbünden setzt voraus, dass deren jeweilige Benutzerverwaltungsinfrastrukturen verwendet werden. Um den doppelten Datenpflegeaufwand sowohl in den LRZ- als auch den jeweiligen Grid-Systemen einzusparen und die damit
verbundenen Fehlerquellen zu vermeiden, soll die LRZ-SIM-Kopplung mit Grid-Systemen weiter
ausgebaut werden.
1.3.2.4.1
CampusLMU-Anbindung
Die im vergangenen Jahr vollständig überarbeitete Ankopplung von LRZ-SIM an den CampusLMUVerzeichnisdienst wurde weiter ausgebaut: Die Menge der übermittelbaren Dateninhalte, insb. Mailattribute, wurde erweitert, um den von den Zielsystemen gebotenen neuen Möglichkeiten (mehrere Mailboxen, Exchange-Nutzung) Rechnung zu tragen.
Die von CampusLMU gesteuerte Berechtigungsvergabe für LRZ-Dienste umfasst neben fakultätsweit
vereinbarten Regeln (Autorisierung für VPN/Eduroam, Desktop-Management/PC, Mail und LinuxCluster) nun auch pro Kennung individuell von CampusLMU festlegbare Autorisierungen (Entitlements).
Dadurch werden die Workflows transparenter und im Support-Fall für den CampusLMU-Helpdesk besser
nachvollziehbar, da die Berechtigungen explizit im CampusLMU-Verzeichnis hinterlegt sind.
Eine neue erweiterbare Webservice-Schnittstelle auf LRZ-Seite bietet für CampusLMU zudem einen direkten, schnellen und sicheren Weg zur Abfrage relevanter Benutzerinformation (z.B. freie Mailadressen,
neue LRZ-Kennung). Das Anlegen eines LMU-Accounts im Rahmen der CampusLMU-Erstregistrierung
kann damit komplett abgeschlossen werden, ohne später dem Benutzer zusätzliche Aktionen am LRZ IdPortal abverlangen zu müssen.
1.3.2.4.2
TUMonline-Anbindung
Die Konzeption zur Provisionierung der relevanten Teile des TUMonline-Datenbestands in die LRZBenutzerverwaltung wurde auf technischer Ebene konkretisiert. Nach Klärung der datenschutzrechtlichen
Aspekte wurde aus den Erfahrungen der TUMonline-Migration ein Weg gefunden, wie zwar die
Identitäten (reale Personen) möglichst umfassend aus beiden Quellen konsolidiert werden können, dabei
aber für bestehende Kennungen und die daran gebundenen Ressourcen (z.B. Mailadressen,
Homedirectorys) ein für die Benutzer sanfter Übergang ohne Zeitdruck hin zu einheitlichen Kennungen
möglich ist. Damit wird für alle TUM-Angehörigen die Pflege der Stammdaten einheitlich über
TUMonline erfolgen und von dort übernommen werden können. Weitergehende Berechtigungen zu LRZDiensten werden dann nur noch den von TUMonline importierten und nicht den alten LRZ-Kennungen
zugeordnet werden.
14
Die Ankopplung von LRZ-SIM an den TUM-Administrationssatelliten befindet sich mittlerweile in intensiver Testphase und kann voraussichtlich bis Anfang 2011 produktiv genommen werden. Dadurch
werden TUM-Angehörige auch weitere LRZ-Dienste – über VPN, Mail und Online-Speicher hinaus –
ohne eine zweite LRZ-Kennung nutzen können. Für die lokalen Ansprechpartner an den Fakultäten, die
Master User, bedeutet dies Entlastung von viel Routine- und unnötiger Doppelerfassungsarbeit. Für das
LRZ wird es ein großer Fortschritt hinsichtlich der Aktualität und Gültigkeit der TUM-Benutzerdaten
sein.
1.3.2.5
Betriebszustand
Zusammenfassend kann festgestellt werden, dass auch das dritte Betriebsjahr des neuen IdentityManagement-Systems LRZ-SIM wie erwartet eine Menge Entwicklungsarbeit sowohl für interne Verbesserungen als auch für die Anbindung weiterer Plattformen und Dienste mit sich brachte. Darin zeigten
sich aber auch die flexible Erweiterbarkeit der Architektur und das Potential für die Nutzung der neuen
technischen Möglichkeiten. LRZ-SIM hat sich als moderne Identity&Access-Management-Lösung etabliert und wird in zunehmendem Maß auf Kundenseite wahrgenommen und geschätzt.
1.3.2.6
Kooperationen
Durch die aktive Teilnahme am ZKI-Arbeitskreis „Verzeichnisdienste“ und am bayerischen Arbeitskreis
„Meta-Directory und AAI“, sowohl in Tagungen als auch über Videokonferenzen, konnte hochschulübergreifend Kompetenz, Wissen und Erfahrung für die Optimierung von Implementierungsdetails genutzt
werden. Der Austausch von Konzepten und Erkenntnissen ist ein wichtiger Baustein dafür, dass das LRZ
sowohl hinsichtlich der Anzahl der zu verwaltenden Benutzer als auch der zur Verfügung gestellten
Dienste und Rechnerplattformen eine der im deutschen Hochschulumfeld aufwändigsten
Identity&Access-Management-Lösungen mit sehr hohen Anforderungen erfolgreich betreibt.
1.3.2.7
Ausblick
Der wichtigste erste Schritt für weitere Arbeiten wird die Produktivführung der TUMonline-Anbindung
sein. Nach der langen und intensiven Vorbereitungsphase und den erfolgreichen Tests ist hier mit keinen
größeren Hindernissen zu rechnen.
Eine weitere Planung betrifft die Implementierung und den Einsatz von Gruppen als Autorisierungsgrundlage für Benutzer etlicher LRZ-Dienste. Neben einer Schema-Erweiterung wird die Hauptarbeit auf
Design und Implementierung des Frontends im Id-Portal liegen. Schließlich ist für nachgelagerte Systeme
und Verzeichnisse, die nicht einfach über LDAP authentifizieren, die Aufbereitung und Übergabe dieser
zusätzlichen Daten zu planen und zu programmieren.
Parallel dazu ist die Unterstützung von Funktionsobjekten zu planen, insbesondere für die stark nachgefragten Shared Mailboxen und Mailverteilerlisten für Exchange. Wie bei den Gruppen wird sich die
Struktur an den schon in den TUM-Verzeichnissen implementierten Objekten orientieren.
Die positiven Erfahrungen mit virtuellen Servern sollen für einen wichtigen LRZ-internen Dienst, den
ID-Server, genutzt werden. Dessen Virtualisierung, zusammen mit einer Migration der Datenbasis auf
eine SQL-Datenbank, sollte noch vor der Rechenzentrumserweiterung abgeschlossen werden.
Die schon vorbereiteten OpenLDAP-Authentifizierungs-Server werden nach eingehender Testphase die
Umstellung der restlichen Mailsysteme mit großem Benutzerbestand von Kerberos- auf LDAPAuthentifizierung erlauben, samt all den damit möglichen, wesentlich differenzierteren Autorisierungsoptionen.
1.3.3 TUM-Verzeichnisdienste
Nach dem planmäßigen Auslaufen der DFG-Förderung des Projekts IntegraTUM Ende 2009 (vgl. Bode,
A., Borgest, R.: Informationsinfrastrukturen für Hochschulen, Springer Verlag 2010) wurden die am LRZ
für die TUM entwickelten und betriebenen Hochschulverzeichnisdienste in der optimierten dritten Version in den Regelbetrieb überführt. Trotz des reduzierten Personals war der nahtlose Übergang bei der
Versorgung und Umstellung auf die neu konzipierte und vollständig vom neuen Campus-ManagementSystem TUMonline gespeiste Directorystruktur für die Vielzahl angebundener Systeme zu bewerkstelligen.
1.3.3.1
15
Weiterentwicklung von Datenmodell und Konnektoren
Entgegen der ursprünglichen Planung musste das System der TUM-Directorys kontinuierlich weiterentwickelt werden, um die große Anforderungspalette auf Seiten der Datenabnehmer nach und nach abzudecken. Das Datenmodell für die Speicherung von Identitäten und Autorisierungsgruppen, aber auch von
Lookup-Tabellen für Studiengänge, Studienabschlüsse und Einrichtungen, musste in einigen Details erneut angepasst werden. Dies lag in neuen Erkenntnissen über die tatsächlichen von TUMonline provisionierten Werte begründet. Allerdings konnte eine abschließende Klärung der wichtigsten autorisierungsrelevanten Dateninhalte leider noch nicht erreicht werden, so dass hier auch zukünftig noch Änderungen
notwendig werden.
Im Einzelnen wurden folgende Anpassungen und Weiterentwicklungen an der Verzeichnisstruktur
vorgenommen:
• Nach eingehender Abstimmung mit der TUM konnte eine Schnittstelle und Schemastruktur zur
Erweiterung der Verzeichnisdienste um Gruppen und Funktionsobjekte (speziell Shared Mailboxen für Exchange) festgelegt werden.
• Mit den neuen Objektklassen im Schema wurde auch eine Anpassung der Konnektoren zu den
Satellitenverzeichnissen und zu den abnehmenden Systemen erforderlich.
• Die automatische Dateneinspeisung in das MWN-weite Microsoft Active Directory (MWN-ADS)
musste für diese neuen Objekte, die u.a. auch in der dort angeschlossenen Zielplattform Exchange
nötig sind, erweitert werden. Seit 2009 erfolgt diese Provisionierung mit dem Novell Scripting
Driver und nachgelagerter Power-Shell-Skripte, deren Programmierung durch die LRZ-PCGruppe und in enger Abstimmung mit dem LRZ-Mail-Team erfolgt.
• Bei dem ebenfalls aus TUMonline provisionierten Orgbaum konnte das Problem gelöst werden,
wie ein dauerhaft eindeutiger Name mit dem Wunsch nach Umbenennung von Einrichtungen
vereinbar ist: Für das Naming-Attribut einer Einrichtung wird deshalb die von TUMonline erzeugte OrgUniqueId verwendet, so dass der Langname und auch das Kürzel ohne technische Seiteneffekte fast beliebig geändert werden dürfen.
Im Sommer 2010 wurde ein Audit der TUM-Directorys durch eine externe Beraterfirma durchgeführt.
Es bescheinigte insgesamt eine hohe Kompetenz und Praxistauglichkeit bei Design, Implementierung und
Betrieb der TUM-Directorys. Vorschläge für Verbesserungen betrafen einerseits die LDAPAnbindungsmöglichkeiten für Linux/Unix-Systeme, andererseits Details wie eine Passwort-Policy, die
sich nach Abstimmung mit dem Directory-Team jetzt überwiegend an den vom Bundesamt für Sicherheit
in der Informationstechnik (BSI) empfohlenen Vorgaben orientiert.
Für Vorbereitungen und Tests zum Aufbau eines zukünftigen zentralen Syslog-Servers am LRZ wurden
die TUM-Verzeichnisse entsprechend konfiguriert, um die nötigen Log-Daten der LDAP-Server wie auch
der IDM-Konnektoren verfügbar zu machen. Das Directory-Team war am LRZ-internen Workshop zur
Evaluation des Syslog-Frontends Splunk ebenfalls beteiligt.
Schließlich sei noch auf den Betrieb des Shibboleth Identity Providers für die TUM (TUM-IdP)
hingewiesen, für den aufwändigere Anpassungen wegen Moodle- und Typo3-Hosting und besonders für
Wiki-Spaces in enger Abstimmung mit dem TUM IT-Service-Zentrum (ITSZ) erfolgte, siehe dazu auch
Abschnitt 1.3.4.3.
1.3.3.2
Angebundene Systeme
Viele Einrichtungen können zur Authentifizierung ihrer Benutzer an lokalen Rechnern und Diensten
direkt den zentralen Authentifizierungsserver nutzen. So konnten im Laufe des Jahres 2010 wieder viele
neue Kunden für diesen Authentifizierungsdienst gewonnen werden. Zu den neuen Kunden zählen
Lehrstühle und Einrichtungen aus allen TUM-Fakultäten, insbesondere auch Informatik, Mathematik,
Medizin, Sport, Wirtschaftswissenschaften sowie Bau- und Vermessungswesen.
Zunehmend mehr Betreiber von IT-Diensten an der TUM, von Webservern über CIP-Pools bis hin zu
komplexen Content-Management-Systemen, haben die Vorteile von TUM-weit einheitlichen Kennungen
erkannt und ihre Systeme an die zentralen Authentifizierungsserver angeschlossen. Trotz der umfangreichen Entwicklungs- und Beratungstätigkeit und entsprechend wenig Zeit für Systemadministration konnte
dank der redundant ausgelegten Architektur und des Kundenzugangs über Service Load Balancer ein
äußerst stabiler Betrieb der Verzeichnisdienste gewährleistet werden.
16
Schließlich wurde auch rechtzeitig die Verfahrensbeschreibung für die Speicherung der Daten in den
einzelnen Verzeichnisdiensten und die Weitergabe an nachgelagerte Systeme für die ermittelten
Datenflüsse und das aktuelle Architekturkonzept angepasst und vom Datenschutzbeauftragten der TUM
für den Endausbau der Verzeichnisdienste genehmigt.
1.3.3.3
Ausblick
Auf Wunsch der TUM ist die Zuständigkeit und Verantwortung für den Dienstbetrieb der TUMVerzeichnisdienste seit 1.1.2011 an das TUM IT-Service-Zentrum übergegangen. Die Servermaschinen
mit Betriebssystem und Load-Balancer-Anbindung stellt nach wie vor das LRZ.
Die tatsächliche Übergabe wird jedoch 2011 schrittweise erfolgen müssen; ein Betriebs- und Entwicklerteam auf TUM-Seite, das die Aufgaben der bisherigen, am LRZ tätigen Mitarbeiter übernimmt, konnte
nicht rechtzeitig aufgebaut werden. Die neuen TUM-Mitarbeiter müssen die einzelnen Bereiche der Directory- und Systemadministration nun ohne längere Einarbeitungsphase primär in Grundzügen verstehen, um die Kontinuität des Betriebs gewährleisten zu können. Zu ihren Aufgaben wird mittelfristig auch
die Fortführung der neuesten Entwicklungen bei Gruppen und Funktionsobjekten, später ggf. auch bei
weiteren Dienstberechtigungen gehören, also durchaus Major Changes zusätzlich zum gewöhnlichen
Tagesgeschäft des Dienstbetriebs.
1.3.4 AAI-Föderationen: Shibboleth Identity Provider
Über die Rechenzentrums- und Hochschulgrenzen hinaus kommt dem föderierten Identity Management
(FIM) auf Basis der Software Shibboleth steigende Bedeutung zu.
Das LRZ betreibt seit 2008 im Rahmen der Authentifizierungs- und Autorisierungsinfrastruktur des DFNVereins (DFN-AAI) auf Basis der Software Shibboleth (https://www.aai.dfn.de/der-dienst/foederation)
die Identity-Provider-Dienste (IdP) für die TUM, die LMU und das LRZ selbst. Die ShibbolethInfrastruktur erlaubt die universelle Nutzung einer Vielzahl von Webdiensten und Webanwendungen
lokaler und externer Anbieter mit der lokalen TUM-, CampusLMU- bzw. LRZ-Kennung und bietet darüber
hinaus die Möglichkeit des Single Sign-On.
1.3.4.1
Betrieb und Administration der Identity Provider
Mit dem Update auf die Shibboleth-IdP-Version 2.1.5 auf allen Servern kurz nach Freigabe wurde die
aktuellste und sicherste Version installiert. Die Verfügbarkeit der Identity-Provider wird durch entsprechende Konfigurationserweiterungen für Nagios laufend überwacht, um einen stabilen, unterbrechungsfreien und performanten Betrieb zu gewährleisten.
Der Ausbau der IdP-Server zu jeweils einem IdP-Cluster war noch nicht notwendig. Die bestehenden IdPServer erwiesen sich als erstaunlich leistungsfähig, trotz z.B. Bestrebungen der TUM, Shibboleth auch für
die Authentifizierung an TUM-lokalen Anwendungen einzusetzen.
Da sich immer wieder spezielle Anforderung einzelner Service-Provider bezüglich Attribut-Ermittlung
und -Filterung ergeben, ist für Entwicklung und Versuche ein neuer IdP-Testserver aufgesetzt worden,
um den Produktionsbetrieb nicht zu stören.
1.3.4.2
DFN-AAI
Die Zahl der deutschlandweit verfügbaren Webdienste in der DFN-AAI-Föderation wächst kontinuierlich, sowohl bei Hochschul- und Forschungseinrichtungen als auch bei kommerziellen Angeboten von
Verlagen und Software-Anbietern. Bei der technischen Koordination der Single-Sign-on-Authentifizierung mit Shibboleth war die Beratung und Unterstützung für Bibliotheken und andere Dienstbetreiber an
den Hochschulen durch das LRZ ein gefragter, aber ohne weiteres Personal nur unzureichend leistbarer
Service.
In einer eigenen Föderation bietet der DFN einen Short Lived Credential Services (SLCS,
https://slcs.pca.dfn.de/gridshib-ca) für Grid-Dienste an, der seit 2009 bereits den LRZ-Benutzern zur
Verfügung stand. In diese Föderation konnten Anfang 2010 nach den vertraglichen Vorbereitungen auch
die Identity-Provider für TUM und LMU aufgenommen werden, wodurch nun ein wesentlich größerer
Personenkreis einen unkomplizierten Zugang zu der sehr sicheren Authentifizierungsvariante über
persönliche Zertifikate hat.
1.3.4.3
17
Universitätslokale Angebote
Die Shibboleth-Technologie und damit die am LRZ gehosteten Identity-Provider-Server für TUM und
LMU kommen verstärkt für universitätsinterne Webdienste zum Einsatz, z.B. für das TUM-Wiki, für
zentrale Anmeldeverfahren oder für Lehrstuhl-Informationssysteme. Eine wesentliche Triebfeder ist die
höhere Sicherheit (Passwörter gelangen nicht zum Service-Provider) und Vertraulichkeit (Benutzer geben
ihre Daten in jedem Einzelfall selbst frei), die die Shibboleth-Technologie gegenüber herkömmlicher
LDAP-Authentifizierung bietet.
Für die lokalen Service Provider waren jedoch teils dedizierte Konfigurationen zur Datenbereitstellung
und -freigabe nötig, die über das übliche Maß in der DFN-AAI hinausgingen. Zum einen erhalten die
ebenfalls am LRZ für TUM und LMU gehosteten E-Learning-System-Instanzen (Moodle) und ContentManagement-Angebote (Typo3) jeweils einen über den Default-Umfang hinaus gehenden Attributsatz
vom IdP. Zum anderen wurde in einem Pilotprojekt die Konstruktion dynamischer synthetischer Attribute
für das TUM-Wiki (ein spezieller Username aus Vorname, Nachname und TUM-Kennung oder E-MailAdresse) erprobt und produktiv geführt.
Weiterhin eignet sich die Shibboleth-Authentifizierung für Dienste, die sowohl TUM- als auch LMUBenutzern offen stehen sollen (z. B. E-Learning-Angebote für gemeinsame Studiengänge), da vorab kein
aufwändiger Austausch von Benutzerdaten erforderlich ist. In der IdP-Konfiguration waren diese Attributfreigaben wechselseitig für die jeweils andere Hochschule jedoch zu berücksichtigen und geeignet zu
konfigurieren.
1.3.4.4
Virtuelle Hochschule Bayern (vhb)
Nach der schon im Vorjahr möglichen Online-Registrierung bei der vhb mit Shibboleth-Authentifizierung
ist die Anmeldung zu vhb-Kursen nun ebenfalls für alle Studenten von in der DFN-AAI organisierten
Hochschulen produktiv geführt.
Für den dritten Baustein, die Shibboleth-Authentifizierung für den Kurszutritt selbst, zeichnet sich nun
organisatorisch wie technisch ein höherer Koordinations- und Implementierungsaufwand ab. So musste
ein Konzept gefunden werden, das sowohl die Belange der vhb umsetzt (zuverlässige Nachverfolgbarkeit
der Kursbuchung und -nutzung) als auch den nahtlosen Parallelbetrieb für alle teilnehmenden Hochschulen beim Übergang vom bisherigen proprietären auf das neue standardbasierte Autorisierungsverfahren
berücksichtigt. Nach intensiven Tests am LRZ hat sich aufgrund von Einschränkungen der ShibbolethArchitektur herauskristallisiert, dass eine Anbindung eines zentralen vhb-LDAP-Servers an alle Hochschul-IdPs nicht in Frage kommt – zu groß wären Verfügbarkeits- wie auch Datenschutzprobleme. Vielmehr ist die Provisionierung der vhb-Kursbelegungsdaten direkt in die IDM-Systeme der Hochschulen
unumgänglich (s. Abbildung 3) und befindet sich bereits in der Testphase.
Unterstützt wird diese maßgeblich vom LRZ und der vhb gestaltete Entwicklung durch den bayerischen
Arbeitskreis „Metadirectory und AAI“ und die Begleitung durch das Bayerische Staatsministerium für
Wissenschaft, Forschung und Kunst.
Schließlich musste noch in einem anderen Bereich im vhb-Umfeld eine Sonderlösung gefunden werden,
und zwar für vhb-Kurse auf Moodle-Instanzen der LMU, zu denen der Zugang schon jetzt nur noch über
Shibboleth möglich ist. Für Studenten, deren Heimathochschulen noch keinen Shibboleth-IdP betreiben,
wurden Sonderkennungen im LMU-Zweig des Import-Export-Satelliten von LRZ-SIM angelegt.
1.3.4.5
Ausblick
Ein arbeitsintensiver Bereich zeichnet sich bei der Implementierung und Koordination für den Shibboleth-Zugang zu vhb-Kursen ab. Das gefundene Konzept der Kursbelegungsdaten-Übernahme in die einzelnen IDM-Systeme der Hochschulen muss durch Beispielimplementierungen von Webservices und
Beratung durch das LRZ begleitet werden, ebenso wie die Erweiterung der IdP-Konfiguration zur Auslieferung und Filterung der Kursdaten an die relevanten Kurs-Service-Provider.
Auf Initiative des TUM IT-Service-Zentrums wird die Planung und Etablierung von koordinierten Workflows bei Changes am TUM-IdP als weitere Aufgabe anfallen.
18
Abbildung 3: Kursbuchung und Kurszutritt über das vhb-Portal mit Übernahme der Kursbuchungsdaten
in die lokale Identity-Management-Datenbasis (hier LDAP-Server, Schritt 4 oben links)
Quelle: W. Hommel (LRZ), A. Hummel (vhb)
1.4
E-Mail, Web-Dienste und Datenbanken
1.4.1 E-Mail-Services
1.4.1.1
Anbindung des Mail-Forwarders an die Benutzerverwaltung LRZ-SIM
Nachdem in 2009 der Mail-Forwarder aufgebaut und an die Benutzerverwaltung TUMonline angebunden
wurde, um unter den Domains tum.de bzw. mytum.de Mailboxen sowohl auf dem MyTUM-Mailserver als
auch auf dem Exchange-Server haben zu können, wurde in 2010 auch die Verbindung zwischen der Benutzerverwaltung LRZ-SIM (Secure Identity Management) und dem Forwarder aufgebaut, um eine Verbindung zwischen dem POP/IMAP-Server mailin.lrz.de und Exchange herzustellen. Es wurden dazu die
Informationen über Weiterleitungen und Abwesenheitsnotizen, die bisher lokal am POP/IMAP-Server
gehalten wurden, nach LRZ-SIM transferiert und sind dort für Dienste des Id-Portals einfach zugreifbar
(z.B. Self Services für Benutzer oder Anzeigefunktionen für die LRZ-Hotline bei der Bearbeitung von
Problemen). Außerdem wurde die Möglichkeit geschaffen, für jede Mailbox festzulegen, auf welchem
Message Store (mailin oder Exchange) sie sich befinden soll. Diese Informationen werden dann dem
Forwarder über ein dediziertes Directory zur Verfügung gestellt. Der Forwarder kann somit entscheiden,
ob eine E-Mail an einen der beiden Message Stores geschickt werden soll und/oder an einen externen
Mailserver. Gleichzeitig übernimmt er die Benachrichtigung eines Senders, wenn der Empfänger eine
Abwesenheitsnotiz geschaltet hat.
1.4.1.2
Anbindung von Exchange an das zentrale Identity Management des LRZ
Mit der Anbindung des Mail-Forwarders an LRZ-SIM war eine der Voraussetzungen erfüllt, um Exchange für weitere Nutzer im MWN, insbesondere für die Bayerische Akademie der Wissenschaften und die
LMU München, bereitstellen zu können. Dazu musste aber zusätzlich auch Exchange an LRZ-SIM angebunden werden. Auch hier waren wiederum umfangreiche Arbeiten notwendig, um die Daten zwischen
19
LRZ-SIM und dem Active Directory zu synchronisieren und Mailboxen auf Exchange automatisch einzurichten oder zu löschen. Erste Pilotnutzer waren die Verwaltung der BAdW und die Tierärztliche Fakultät
der LMU, deren Lehrstühle ab Juni sukzessive vom bisherigen Mailsystem mailin auf Exchange umgezogen wurden.
1.4.1.3
Aufbau einer Exchange 2010 Umgebung
Parallel zu den Umzügen auf Exchange wurde ab Mai damit begonnen, eine Exchange 2010 Umgebung
aufzubauen und die Migration von der bisherigen Version (Exchange 2007) vorzubereiten. Während die
alte Umgebung nur für bis zu maximal 5.000 Nutzer ausgelegt war und so langsam an ihre Grenzen stieß,
wurde die neue für bis zu 20.000 Nutzer konzipiert und komplett auf virtuellen Maschinen realisiert. Die
Migration fand wie geplant Ende Oktober statt und verlief ohne größere Schwierigkeiten. Mit Exchange
2010 steht nun auch Benutzern, die nicht die Microsoft-Anwendungen Outlook bzw. Internet Explorer
verwenden, die vollständige Funktionalität zur Verfügung, z.B. bei Verwendung von Firefox und der
Web-Anwendung OWA (Outlook Web App).
1.4.1.4
Aufbau eines neuen Mailinglisten-Servers
Ein weiteres wichtiges Projekt war der Aufbau eines neuen Mailinglisten-Servers auf Basis des Produkts
Mailman. Damit wurde der in die Jahre gekommene Majordomo-Server abgelöst. Mailman bietet gegenüber Majordomo hauptsächlich den Vorteil, dass sowohl für Listen-Administratoren als auch für Nutzer
der Listen eine Web-Oberfläche zur Verfügung steht, über die die gewünschten Einstellungen bequem
vorgenommen werden können. Der Umzug auf den neuen Server wurde auch dazu genutzt, unter den bis
dato existierenden Listen gründlich aufzuräumen: ca. 300 Listen, die schon lange nicht mehr benutzt
wurden, wurden gelöscht. Zur automatischen Migration der Mailinglisten wurde eine Reihe von Programmen entwickelt. Trotzdem waren wegen der Komplexität der Migration und der verschiedenartigen
Modelle der Listenverwaltung in Majordomo und Mailman zahlreiche manuelle Nacharbeiten notwendig.
1.4.1.5
Massenmail-System für Hochschulstart
Aus dem Projekt Hochschulstart kam die Anforderung, an einem Tag alle Studenten, die sich um einen
Studienplatz beworben haben, über das Ergebnis per Mail zu informieren. Dabei wird davon ausgegangen, dass das dafür notwendige Massenmailsystem in der Lage ist, 400.000 E-Mails innerhalb von 24
Stunden zu versenden. Dies war über die vorhandene Infrastruktur nicht zu erreichen, so dass ein separates Massenmailsystem auf Basis von zwei virtuellen Mailservern aufgebaut wurde. Alle E-Mails, die
durch das Massenmailsystem laufen, werden mit einer DKIM-Signatur versehen, damit die Zielsysteme
die Integrität des Mailheaders, insbesondere die Absendemailadresse überprüfen können. Bei manchen
ISPs ist dies Voraussetzung, damit sie Massenmails in diesem Umfang akzeptieren. Die aufgebauten Systeme wurden intensiven Lasttests unterworfen, um die geforderte Performance sicherstellen zu können.
Um Erfahrungen im Produktionsbetrieb des Systems zu erhalten, wurde der neu aufgebaute MailinglistenServer an das Massenmailsystem angebunden. In Zukunft soll das System auch für den Massenversand
von E-Mails von Nutzern der ans MWN angeschlossenen Organisationen genutzt werden. Diese Kunden
werden auf Antrag autorisiert, dieses System zu nutzen.
1.4.1.6
Statistiken
1.4.1.6.1
Spam- und Virenabwehr
Das Gros der Spam- und Viren-Mails wird bereits von den Postrelays, die für die Annahme von E-Mails
aus dem Internet zuständig sind, durch die dort implementierten Abwehrmechanismen abgewiesen. Die
angenommenen E-Mails werden von den Postrelays über die Mailrelays an ein Cluster von ScanRechnern weitergeschickt. Dort werden Viren-Mails ausgefiltert (und die Empfänger darüber informiert)
und die verbleibenden E-Mails markiert, ob es sich vermutlich um Spam-Mails handelt oder nicht. Diese
Markierung kann dann dazu verwendet werden, die betreffenden E-Mails durch Konfiguration entsprechender Regeln im eigenen Mailprogramm auszufiltern.
In der folgenden Graphik ist die Entwicklung von ausgefilterten Viren-Mails, markierten Spam-Mails und
regulären erwünschten E-Mails (Ham-Mails) für die Jahre 2006 bis 2010 graphisch dargestellt. Dabei
sind nur die E-Mails berücksichtigt, die aus dem Internet angenommen wurden, also ohne die abgewiesenen Spam- und Virenmails. Wie man sieht, ist der Anteil der Ham-Mails seit Jahren relativ konstant. Der
20
Anteil an Viren-Mails ist seit einiger Zeit so klein, dass man ihn in der Graphik nicht mehr erkennen
kann. Die Werte liegen bei ca. 88 erkannten Viren pro Tag (Vorjahr: 80).
7000000
6000000
5000000
4000000
Ham
3000000
Spam
Viren
2000000
1000000
0
Jan Apr Jul Okt Jan Apr Jul Okt Jan Apr Jul Okt Jan Apr Jul Okt Jan Apr Jul Okt
Abbildung 4: Monatliches Ham-, Spam- und Virenaufkommens in den Jahren 2006 bis 2010
1.4.1.6.2
Relaydienst
Am Übergang vom Internet in das Münchner Wissenschaftsnetz (MWN) ist an den Routern der Port für
das SMTP-Protokoll für fast alle Rechner gesperrt. Nur einige ausgewählte Mailserver – neben den 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 164 Mailserver im MWN mit insgesamt 426 verschiedenen
Maildomains in Anspruch.
Mailserver
Domains
im MWN
Einrichtung
andere Hochschulen und hochschulnahe Einrichtungen
49
100
28
107
220
117
Gesamt
177
444
Tabelle 9: Nutzung des E-Mail-Relaydienstes
1.4.1.6.3
Mailhosting (virtuelle Mailserver)
Das LRZ bietet Hochschul- und hochschulnahen Einrichtungen, die keinen eigenen Mailserver betreiben
wollen, an, den Maildienst am LRZ zu „hosten“. Es wird dann eine virtuelle Maildomain eingerichtet, in
der sich der Name der betreffenden Einrichtung widerspiegelt (z.B. jura.uni-muenchen.de) und Angehörige dieser Einrichtungen erhalten entsprechende Mailadressen. Die zu den virtuellen Domains gehörenden Mailboxen können sich sowohl auf dem POP/IMAP-Server mailin.lrz.de, als auch auf dem vom LRZ
betriebenen Exchange-Server befinden. Die Entscheidung, an welchen Server eine E-Mail auszuliefern
ist, übernimmt der sogenannte Forwarder, der sich die notwendige Information dafür aus der jeweiligen
Benutzerverwaltung holt.
21
Seit Ende des Jahres 2010 unterstützt TUMonline organisationsspezifische Maildomains, d.h. neben den
Mailadressen mit den Domains mytum.de und tum.de können Administratoren einer TUMOrganisationseinheit, z.B. ein Lehrstuhl oder auch eine ganze Fakultät, weitere Maildomains für ihre
Nutzer konfigurieren. Seitdem dies möglich ist, werden neue TUM-Maildomains nur noch in TUMonline
angelegt. Alte virtuelle Maildomains auf den POP/IMAP-Servern des LRZ werden sukzessive dorthin
migriert. Die zugehörigen Mailboxen liegen dann entweder auf dem MyTUM-Mailserver oder auf dem
Teil des Exchange-Servers, der zu TUMonline gehört. Auch hier sorgt der Forwarder dafür, dass eine EMail auf dem richtigen Mailserver landet.
Aus Sicht des LRZ handelt es sich beim TUM-Mailserver um einen einzigen Mailserver mit beliebig
vielen Aliasdomains. Daher die „1“ in der Spalte „virtuelle Mailserver“ in der untigen Tabelle.
Ende 2010 waren am LRZ 227 (Vorjahr: 228) virtuelle Mailserver eingerichtet. Eine Aufteilung auf die
Hauptnutzer ist der folgenden Tabelle zu entnehmen:
Einrichtung
virtuelle
Mailserver
Domains
93
56
1
42
35
137
113
24
75
48
227
397
Technische Universität München (LRZ-SIM)
Technische Universität München (TUMonline)
Bayer. Akademie der Wissenschaften (inklusive LRZ)
Gesamt
Tabelle 10: Betrieb virtueller Mailserver
1.4.1.6.4
Nutzung der Message-Store-Server
1.4.1.6.4.1
Nutung der POP/IMAP-Server
Ende 2010 gab es 119.489 Mailboxen (Vorjahr: 111.764) auf einem der fünf POP/IMAP-Server des LRZ.
Nachfolgend eine Aufteilung nach Server bzw. Benutzergruppen:
POP/IMAP-Server für …
… Mitarbeiter der vom LRZ bedienten Einrichtungen (Mailserver „mailin“):
8.187
7.388
1.066
Hochschule München
256
andere bayerische Hochschulen
205
andere wissenschaftliche Einrichtungen
2.255
… die Fakultät Physik der Technischen Universität München
… das myTUM-Portal der Technischen Universität München
… Studenten der Ludwig-Maximilians-Universität München (CampusLMU)
… Studenten anderer Münchner Hochschulen
Gesamt
19.357
2.982
43.719
51.903
1.528
119.489
Tabelle 11: Nutzung der POP/IMAP-Messagestores
1.4.1.6.4.2
Anzahl
Benutzer
Nutzung des Exchange-Dienstes
22
Im Jahr 2010 wurde der Benutzerbetrieb für den Exchange-Dienst auf die Ludwig-MaximiliansUniversität ausgeweitet (zunächst pilotmäßig für die Fakultät Tiermedizin). Ende 2010 gab es auf dem
Exchange-Cluster 5.012 Mailboxen (Vorjahr: 1.634), die sich wie folgt verteilten:
ExchangeMailboxen
Einrichtung
Bayerische Akademie der Wissenschaften
278
4.561
43
130
Gesamt
5.012
Tabelle 12: Nutzung des Exchange-Dienstes
1.4.1.6.5
Weiterleitungs-Service
Der oben bereits erwähnte Forwarder, der für die Verteilung von E-Mails an den richtigen Message Store
zuständig ist, übernimmt neben individuell eingerichteten Weiterleitungen auch einen Weiterleitungsservice für ganze Domains, zu denen es keine Mailboxen gibt. Bei der LMU handelt es sich dabei um die
Domain uni-muenchen.de bzw. lmu.de, bei der TUM um die Domain alumni.tum.de.
Einrichtung
Weiterleitungen
15.376
3.989
Gesamt
19.365
Tabelle 13: Nutzung des Weiterleitungsdienstes für Maildomains
1.4.1.6.6
Nutzung von E-Mail-Verteilerlisten
Wie weiter oben bereits erwähnt, wurde der Mailinglisten-Dienst des LRZ im Dezember 2010 auf das
Produkt Mailman umgestellt. Diese Umstellung wurde auch zum Anlass genommen, gründlich aufzuräumen: Insgesamt wurden 304 Listen, die schon lange nicht mehr benutzt wurden, gelöscht.
Ende 2010 gab es 453 E-Mail-Verteilerlisten (Vorjahr: 661), die sich wie folgt verteilten:
E-MailVerteilerlisten
Einrichtung
112
159
145
37
Gesamt
453
Tabelle 14: Nutzung von E-Mail-Verteilerlisten
1.4.2 Webdienste
Schwerpunkt beim Webhosting war 2010 der Ausbau des E-Learning für beide Universitäten, die jeweils
nach relativ kurzer Pilotphase in den Produktionsbetrieb übergegangen sind, die TUM hochschulweit, die
LMU mit einigen Fakultäten. Vor allem für diese Anwendungen wurde Shibboleth als neuer Dienst eingerichtet.
23
Außerdem wurden die schon bestehenden Content-Management-Systeme Fiona für LRZ und BAdW
sowie Typo3 für die TUM weiter ausgebaut.
1.4.2.1
E-Learning
Im Bereich der Lehre an den Hochschulen ist ein klarer Trend zur verstärkten Nutzung von E-LearningSystemen zu erkennen. Dadurch erhöhte sich auch die Nachfrage nach geeigneten Webumgebungen zur
Realisierung deutlich. Somit wurden die im Vorjahr begonnenen Pilot-Projekte in diesem Bereich zu
produktiven Lernumgebungen ausgebaut.
1.4.2.1.1
Moodle TUM
Die umfangreichste Installation wurde für die TUM umgesetzt, die sich zum TUM-weiten Einsatz von
Moodle entschieden hat. Betrieben wird die Lernplattform am LRZ in einer eigens dafür eingerichteten
Webumgebung, bestehend u.a. aus dedizierten Webservern, Dateisystemen und Datenbanken. Dabei
konnten die bereits bestehenden Konzepte für die Einrichtung von Webservern weitgehend auf das neue
System übertragen werden, so dass es sich trotz Eigenständigkeit gut integriert. Der technische Betrieb
wird vom LRZ in enger Absprache mit den Zuständigen an der TUM (ITSZ Medienzentrum) erbracht.
Die Betreuung auf Applikations-Ebene, insbesondere die direkte Unterstützung der Moodle-Nutzer, liegt
bei der TUM. Zum TUM-Moodle-System gehören mehrere Komponenten: Die zentrale Lernplattform
selbst sowie ein Staging-System, das sowohl für Tests und Entwicklung, als auch für Support und Schulung verwendet wird.
1.4.2.1.2
Moodle LMU
Bei der LMU erfolgt keine Zentralisierung auf eine gemeinsame Moodle-Umgebung, sondern es werden
nach und nach einzelne Moodle-Instanzen nach den aktuellen Bedürfnissen der Fakultäten und Lehrstühle
eingerichtet. Um eine allzu große Vielfalt zu verhindern, werden die Einrichtung und die Grundkonzepte
der LMU-Moodle-Instanzen über den Leiter des Bereichs „Virtuelle Hochschule“ an der LMU koordiniert. Derzeit sind sechs Moodle-Instanzen für die LMU in Betrieb, die etwa zur Hälfte bereits produktiv
eingesetzt werden.
1.4.2.2
Neues Dienst-Angebot im Webhosting: Shibboleth
Die Nutzung der E-Learning-Systeme ist nur nach einem erfolgreichen Login durch nutzungsberechtigte
Personen möglich. Gerade im Bereich E-Learning ist dieser Nutzer-Kreis jedoch oft nicht mehr auf die
Hochschule beschränkt, an der ein Online-Kurs angeboten wird. Insbesondere über die VHB (Virtuelle
Hochschule Bayern) werden zahlreiche Kursteilnehmer bayernweit auf Online-Kurse verteilt. Um die
Verwaltung dieser Gast-Hörer auf technischer Ebene im E-Learning-System zu vereinfachen, wird sowohl auf den TUM- als auch den LMU-Moodle-Instanzen Shibboleth eingesetzt:
• Shibboleth ermöglicht Nutzern, die nicht in die lokalen Verwaltungsstrukturen eingebunden sind,
sich dennoch als berechtigte Nutzer in einer Moodle-Instanz anzumelden. Der Moodle-Nutzer
wird in einem Shibboleth-fähigen Moodle für den Login-Prozess zu seinem eigenen „Herkunftsort“, seinem sogenannten Identity-Provider geschickt, kann sich dort mit seinen gewohnten Zugangsdaten ausweisen und wird dann wieder zurück zum Moodle geschickt. Dabei werden die
notwendigen Eckdaten wie Name, Vorname, Loginname, Email-Adresse usw. automatisch an das
Moodle übermittelt und in die lokale Moodle-Verwaltung aufgenommen.
• Shibboleth ist außerdem ein Single-Sign-On-Verfahren. Das heißt, dass man nach einem Login
beispielsweise in Moodle automatisch auch in einer anderen Applikation (z.B. einem Wiki, einem
Hochschulportal. usw.) angemeldet ist, die ebenfalls Shibboleth-fähig ist.
Auch für die Nutzer des TUM-Typo3-Systems (siehe weiter unten) soll Shibboleth zum Einsatz kommen.
Derzeit wird an der TUM unter Mithilfe des LRZ ein entsprechendes Typo3-Modul entwickelt. Hier würde insbesondere auch die Single-Sign-On-Komponente zum Tragen kommen: Dozenten und andere Content-Provider der TUM wären automatisch an der Lern-Plattform und auf den Webseiten, die sie verwalten, angemeldet, um Kurse zu ändern und Webseiten-Inhalte zu erstellen und anzupassen. Je mehr Shibboleth-fähige Applikationen hinzukommen, umso interessanter wird dieser Aspekt natürlich.
Um Applikationen Shibboleth-fähig zu machen, müssen eine Reihe von technischen Voraussetzungen
erfüllt sein. Insbesondere muss applikationsseitig ein sogenannter Service-Provider betrieben werden, der
zwischen der Applikation und dem Identity-Provider vermittelt. Der Betrieb solcher Service-Provider
24
muss auf den Systemen laufen, auf denen auch die Applikationen liegen und wird daher als weitere Leistung im Rahmen des Webhosting erbracht. Im Fall von LMU und TUM ergibt sich außerdem die Situation, dass auch der Identity-Provider vom LRZ betrieben wird (siehe Bericht Identity Management), so
dass hier gute Bedingungen zur Koordination zwischen beiden Komponenten herrschen. Da die Komplexität des gesamten Shibboleth-Systems viele Absprachen erfordert, ist dies ein großer Vorteil.
1.4.2.3
Typo3
Die TUM unterstützt für die Webauftritte ihrer Fakultäten, Lehrstühle und Einrichtungen das ContentManagement-System Typo3 und bietet dazu die Installation dieser Applikation und den Support auf einer
vom LRZ bereitgestellten und gepflegten Webumgebung. Die Vorbereitungen und Absprachen hatten
bereits im Vorjahr begonnen (wie berichtet). Das Gesamtsystem ist im Berichtsjahr mit Erfolg und in
großem Umfang in Produktion gegangen. Es wurden bisher über 200 neue Webserver in dieser Umgebung eingerichtet (siehe auch Statistik).
1.4.2.4
Performance der Webhosting-Umgebung
Durch die zahlreichen neuen Webserver, die intensiven Gebrauch von Datenbanken machen – Moodle
und Typo3 sind die am häufigsten eingesetzten Produkte dieser Art – haben sich neue Ansprüche an das
Webhosting ergeben. Waren Zugriffe von den Webservern auf die Datenbanken früher eher die Ausnahme, so sind sie jetzt die Regel. Dadurch werden die Netzlaufzeiten von Datenpaketen zwischen Datenbank und Webserver relevant, während dies früher kaum eine Rolle spielte. Dies kann bei komplexen
Setups zu deutlichen Leistungseinbußen im Gesamtsystem führen. Dieser Effekt erhöht sich noch
dadurch, dass die meisten Zugriffe personalisiert sind – nach erfolgtem Login werden Webseiten entsprechend dem Nutzerprofil individuell angepasst ausgeliefert –, so dass die üblichen Caching-Methoden
wenig bis gar nicht einsetzbar sind. Dabei ist es für das Laden einer Webseite oft von untergeordneter
Bedeutung, ob viele oder nur wenige Nutzer das System nutzen, da allein zur Zusammenstellung einer
einzigen Webseite hunderte von Verbindungen benötigt werden, deren Gesamtlaufzeit sich zu einer fühlbar langen Zeit aufaddiert, je langsamer die Netzanbindung ist. Und nicht nur die Laufzeiten zur Datenbank spielen dabei eine Rolle, sondern auch die Laufzeiten zu den Webdaten, die auf dem Dateisystem
abgelegt sind.
Die auf diesem Gebiet im Berichtsjahr gewonnenen Erkenntnisse müssen daher verwendet werden, um
die Webumgebung den veränderten Bedingungen anzupassen und dem Nutzer weiterhin einen zeitgemäß
ausreichend schnellen Zugang zu den Applikationen zu gewährleisten. Eine maschinelle Aufrüstung ist
sicherlich auch notwendig, wird aber alleine nicht ausreichen. Dem Problem mit schnelleren Netzen zu
begegnen ist ebenfalls keine Lösung, da die technischen Möglichkeiten hier bereits weitgehend ausgeschöpft sind. Daher müssen sowohl die Datenbanken als auch die Dateisysteme netztechnisch näher an
die Webserver gebracht werden, um die Laufzeiten zu verringern. Das erfordert Änderungen im Webhosting-Konzept, die sowohl für bereits bestehende als vor allem auch für neue Webserver-Pools berücksichtigt und umgesetzt werden müssen. Der Zeitgewinn kann durch ein günstiges Setup durchaus einen
Faktor 10 ausmachen.
1.4.2.5 Webhosting – Statistik
Auf die zentralen WWW-Server am LRZ wurde im Jahr 2010 durchschnittlich ca. 51 Millionen Mal pro
Monat (also etwa 19 Mal pro Sekunde) zugegriffen. Diese Zahl ist allerdings aus mehreren Gründen nur
bedingt aussagekräftig. Zum einen ist eine echte Zählung der Zugriffe gar nicht möglich, da auf verschiedenen Ebenen Caching-Mechanismen eingesetzt werden (Browser, Proxy). Andererseits werden nicht
Dokumente, sondern „http-Requests“ gezählt. Wenn also z. B. eine HTML-Seite drei GIF-Bilder enthält,
so werden insgesamt vier Zugriffe registriert.
Die folgende Tabelle zeigt die durchschnittliche Zahl der Zugriffe und den durchschnittlichen Umfang
der ausgelieferten Daten pro Monat; die Daten sind nach den vom LRZ betreuten Bereichen aufgeschlüsselt. Die Zahlen für das LRZ enthalten auch die Zugriffe auf persönliche WWW-Seiten von Hochschulangehörigen. Zusätzlich wird die Zahl der Seitenaufrufe, das ist die angeforderte Zahl der „echten“ Dokumente, genannt. Als echte Dokumente gelten dabei Textdokumente, also keine Bilder oder CGISkripte.
Die Zahl der Webserver hat sich gegenüber 2009 um 283 erhöht; das sind mehr als 50%; dieser Anstieg
ist fast ausschließlich dem Typo3-Projekt der TUM zuzuschreiben, das eine Vielzahl kleiner Webserver
25
umfasst. Der Umfang der ausgelieferten Daten stieg etwas stärker an als die Zahl der Zugriffe, nämlich
um 25% auf ca. 2,3 TByte pro Monat.
Zugriffe
in Mio.
Seitenaufrufe
in Mio.
Einrichtungen im Münchner Hochschulnetz
Einrichtungen im Münchner Wissenschaftsnetz
Sonstige
17,20
4,69
17,52
2,76
2,52
0,88
5,94
6,89
0,65
1,76
0,86
0,28
0,20
0,44
835,9
224,2
741,6
40,5
249,4
152,1
112,3
Gesamt
51,51
11,08
2356,1
Server
Datenumfang
in GByte
Tabelle 15: Monatliche Zugriffe auf die WWW-Server am LRZ
Ende 2010 unterhielt das LRZ 16 virtuelle WWW-Server für eigene Zwecke. Für Hochschulen und hochschulnahe Einrichtungen wurden insgesamt 814 (Vorjahr: 531) virtuelle WWW-Server betrieben.
Einrichtung
Webserver 2010 Webserver 2009
Einrichtungen aus dem Münchner Hochschulnetz
(z. B. Hochschule für Politik)
Einrichtungen aus dem Münchner Wissenschaftsnetz
(z. B. Zoologische Staatssammlung München)
Andere (z. B. Bayerisches Nationalmuseum)
16
114
541
27
24
16
112
273
27
26
29
26
63
51
Gesamt
814
531
Tabelle 16: Anzahl virtueller WWW-Server
Die Unterstützung der Applikationsplattform Zope wurde weiter zurückgefahren. Zum Jahresende gab es
noch insgesamt zwölf unabhängige gehostete Sites, und zwar zehn individuelle Zope-Instanzen mit individuellen Sites (meist Plone), sowie eine TUM-Zope-Instanz mit zwei elevateIT-Sites.
1.4.2.6
Content-Management für das LRZ selbst und die BAdW
Das Content-Management-System Fiona der Fa. Infopark wird seit Mitte 2007 für die Verwaltung der
Inhalte des Webauftritts der Bayerischen Akademie der Wissenschaften verwendet. Nachdem im April
2009 auch der Webauftritt des LRZ auf dieses System umgestellt und dabei überarbeitet wurde, folgte im
September 2010 der interne Webserver. Das bestand aus zwei größeren Komplexen:
• Die enthaltene Dokumentation sollte übernommen werden. Anders als beim externen Webserver
ein Jahr vorher wurde nicht der gesamte Altbestand an Webseiten mitsamt seiner Gliederung
übernommen. Vielmehr orientiert sich die Gliederung jetzt am für das IT-Servicemanagement
neu entworfenen Dienstebaum, und es sollen nur aktuelle Texte übernommen und dabei auf ihre
Richtigkeit überprüft werden. Diese Aufräumaktion in enger Zusammenarbeit mit dem Arbeitskreis Informationsmanagement wird sich bis ins Jahr 2011 hinziehen.
• Bestandteil des alten internen Webservers war auch der Publisher, also das bisherige ContentManagement für Extern- wie Internserver. Das ist zwar mit der Migration des Internservers im
26
Prinzip überflüssig geworden, einige speziellere Funktionen (E-Mail-Verteiler, LRZMitteilungen) konnten aber nicht sofort ersetzt werden und werden noch bis ins Jahr 2011 in Betrieb bleiben.
Auch im Berichtsjahr lag nicht nur der Betrieb der Fiona-Software und der zugrundeliegenden Systeme,
sondern auch die Unterstützung der Redakteure aus der BAdW und Anpassungen der Konfiguration an
deren Wünsche beim LRZ. Hervorzuheben ist besonders die Schulung von Mitarbeitern der BAdW in der
Nutzung und Konfiguration dieser Software. Mit der Schelling-Kommission wurde die pilotmäßige Migration des Webauftritts einer Kommission der BAdW nach Fiona vorbereitet.
1.4.3 Datenbanken
MySQL-Datenbanken sowie Oracle-Datenbanken bilden den Schwerpunkt der Datenbankdienste. Daneben wird Microsoft Access als Frontend verwendet und mehrmals im Jahr Kurse hierzu angeboten. Die
Anzahl der Server, die MySQL-Datenbanken im Netz anbieten, wuchs auf 15 Einheiten an, so dass sich
die Anzahl der darauf laufenden Instanzen auf 25 (Vorjahr 15) erhöhte. Einzelne Datenbanken wie z.B.
die Patentdatenbank überschreiten zwischenzeitlich die 1 TB Datenbankgröße. Neben der CMSInstallation Fiona werden diverse Clientanwendungen für MySQL (WordPress, Moodle, Typo3, Joomla!
etc.) unterstützt. Die für virtuelle Webserver der Münchener Hochschulinstitute eingerichtete Datenbankinstanz wurde auf einen VMware-Rechner migriert.
Diese Instanz umfasst 357 Schemata (Einzeldatenbanken) welche zum Datenmanagment der virtuellen
Webserver benötigt werden. Hierbei handelt es sich um die MySQL Version 4.1. Seit Dezember 2010
werden allerdings Webserverdatenbanken ausschließlich mit der MySQL-Version 5 angeboten und installiert. Für die Version 5.0.51 wurden im letzten Jahr 167 Datenbanken zusätzlich angelegt.
Wie bei allen anderen MySQL-Anwendungen am LRZ zuvor wird auch hier ein 7×24h-online-Betrieb
durchgeführt; ausgenommen davon sind Wartungsfenster. Diese neu installierten Datenbanken dienen
sowohl als Backend-Datenbanken für die Typo3-Anwendungen der TUM und LMU als auch für allgemeine Anwendungen (Drupal, Joomla! etc).
Zusätzlich zu den vorhandenen Standarddatenbanken basierend auf MyISAM-Tabellen gewinnt der Einsatz von transaktionsbasierten Tabellen in MySQL mit der zugehörigen InnoDB-Engine immer mehr an
Bedeutung und wird im LRZ zunehmend standardmäßig eingesetzt. Eine Besonderheit hierbei sind die
wesentlich aufwendigeren Sicherungs- und Restoreverfahren, die im MySQL-Umfeld zusätzliche Software wie InnoDB-Hotbackup bzw. ZManda benötigen. Diese Software wurde ebenfalls angeschafft, installiert und sodann in wichtigen Projekten eingesetzt. Anzuführen wären hier insbesondere die Lernplattform Moodle der TU/ LMU sowie das Projekt Hochschulstart.
Speziell die letzten genannten Projekte, die eine hohe Stabilität als auch Performance benötigen, wurden
jeweils mit kommerzieller Enterprise-Software ausgestattet, wodurch ein bestmöglicher Support gewährleistet ist.
Darüberhinaus wurden im Jahre 2010 Datenbanken für verschieden Inhouse-Awendungen MySQLDatenbanken benötigt und installiert. Hierbei ist vor allem die aktuelle HPC Anwendung zu nennen. Für
diese wurde eine neue Datenbank mit Replikation installiert. Das Projekt befindet sich derzeit im Teststadium und wird etwa Mitte 2011 in Produktion gehen.
Das Dienstangebot bei den Oracle-Datenbanken blieb weitgehend unverändert. Zwei neue Rechner für
Oracle-Instanzen wurden beschafft, um ältere aus der Wartung fallende Maschinen zu ersetzen. Einige
Dienste der Oracle-Instanz (z.B. das Trouble-Ticket-System des LRZ) liefen parallel unter der Anwendung Action Request Software (ARS) sowie dem neu beschafften System iET ITSM-Solution. Dieses System arbeitet mit der Datenbank Microsoft SQL Server als Datenbank-Engine und löst im März 2011 das
bisherige Trouble-Ticket-System ab.
Am Jahresende 2010 betrieb das LRZ 25 Instanzen (Vorjahr: 15) von MySQL (2× MySQL 4.1 und 23×
MySQL 5), die etwa 1,5 TB-Byte Daten (Vorjahr: 600 G-Byte) verwalten. Damit werden unter anderem
357 virtuelle Webserver (Vorjahr: 280) versorgt. Darüber hinaus finden die MySQL-Services hausintern
in 34 Projekten intensiven Gebrauch. Auch die Performancedaten des HLRB II werden in einer MySQLDatenbank verwaltet und dadurch konsolidiert im Internet angezeigt. Die MySQL-Datenbankserver verarbeiten derzeit permanent ca. 1200 Anfragen aus dem Netz pro Sekunde (Vorjahr: 1000).
1.5
27
Grafik, Visualisierung, Multimedia
1.5.1 Virtual Reality (VR)
Die bisherige Ausstattung des LRZ zur immersiven Visualisierung wissenschaftlicher Daten, deren
Hauptbestandteil eine Zwei-Flächen-Holobench ist, genügt nicht mehr den Anforderungen der Benutzer.
Eine umfangreiche Bedarfserhebung unter Lehrstuhlinhabern aus vielen Fachbereichen von LMU und
TUM zeigte die Notwendigkeit, auch zukünftig eine angemessene Ausstattung zur immersiven Visualisierung zur Verfügung zu stellen. Insbesondere sind mittlerweile Projekte in Planung, die nur in einer
echten Virtual-Reality-Umgebung realisiert werden können, bei der der Benutzer von der Projektion fast
vollständig umgeben wird. Ein solcher Projektionsraum (der häufig als CAVE bezeichnet wird) ist seiner
Natur nach ein interaktiver Arbeitsplatz für einen oder wenige Wissenschaftler. Daneben gibt es auch
noch Bedarf für großflächige stereoskopische Präsentationen vor Gruppen im Rahmen von wissenschaftlichen Veranstaltungen.
Deshalb wurde in 2010 ein Forschungsgroßgeräteantrag ausgearbeitet, in dem ein Visualisierungszentrum
mit einer entsprechenden Ausstattung beantragt wird: eine fünfseitige CAVE mit Projektion auf die Seitenflächen, Boden und Decke, sowie eine großformatige 3D-Powerwall. Im Erweiterungsbau des „Zentrums für Supercomputing“ wurde hierfür ein entsprechender Raum vorgesehen, der die spezifischen Anforderungen der beiden komplexen Projektionsanlagen erfüllt. Insbesondere wird in diesem neuen Visualisierungszentrum durch die außergewöhnliche Raumhöhe eine Bodenrückprojektion der CAVE ermöglicht werden, die jeglichen störenden Schattenwurf vermeidet, den Eindruck der Immersion verbessert
und eine echte Besonderheit darstellt.
1.5.2 Streamingserver
Das LRZ betreibt seit 2001 einen Streamingserver. Die Nutzung dieses Servers hat in den letzten Jahren
kontinuierlich zugenommen. Insgesamt liegen derzeit auf dem Streamingserver mehrere tausend Filmbeiträge mit einem kumulierten Datenvolumen von 935 GByte – annähernd eine Verdoppelung in den vergangenen 12 Monaten.
Die einzelnen Filme sind meist Aufzeichnungen von Vorträgen oder Vorlesungen mit einer Länge von
80-90 Minuten, aber auch teilweise kürzere Lehrvideos, die zum Beispiel die Ausbildung in der Medizin
unterstützen. Vorlesungsaufzeichnungen werden normalerweise in drei Varianten erstellt und abgelegt,
als hochaufgelöstes Video mit einer Bandbreite von ca. 1 Mbit/s, als niedriger aufgelöstes Video mit ca.
400 Kbit/s und einer Variante, die nur aus der Tonspur besteht und nur eine Bandbreite von ca. 50 Kbit/s
benötigt.
Der bisherige Darwin-Streamingserver basiert auf QuickTime und für die Wiedergabe der Medieninhalte
ist das QuickTime-Plugin notwendig. Es wurde wiederholt nach einer weiteren Streaming-Lösung nachgefragt, bei der für die Wiedergabe stattdessen das Flash-Plugin zum Einsatz kommt. Dazu wurde im
vergangenen Jahr ein Mediaserver von Wowza Media Systems aufgebaut, der seit dem Wintersemester in
Produktionsbetrieb ist.
1.6
Serveradministration und Applikationsunterstützung
Der Betrieb von Serversystemen für Internetdienste erfordert eine Reihe von Arbeiten, die inhaltlich eher
zum Betriebssystem oder zur systemnahen Software gehören, die aber auf das Applikationsportfolio am
jeweiligen Serversystem zugeschnitten sind. Ob dabei das Serversystem eine physische Maschine ist oder
aber eine virtuelle, spielt auf dieser Ebene kaum eine Rolle. Zu diesen Aufgaben gehören beispielsweise
• die Auswahl des erforderlichen Betriebssystemumfangs, je nach den Voraussetzungen der geplanten Anwendungen,
• die Deaktivierung von nicht benötigten Netzdiensten aus Sicherheitsgründen und weitere Sicherheitsmaßnahmen wie Zugangsbeschränkungen und Security-Patches,
• die Überwachung der Verfügbarkeit und der Funktion auf Applikationsebene,
• die Messung der Systemauslastung unter Berücksichtigung der Erfordernisse der Applikationen
zum Tuning und zur proaktiven Ressourcenplanung,
• die Erstellung von Operateuranleitungen zur Problembehebung,
28
die Unterstützung und Beratung der mit der Applikation betrauten Mitarbeiter, um eine optimale
Nutzung des Systems zu erreichen sowie
• die Fehlersuche an der Schnittstelle zwischen Applikation und Betriebssystem.
Da diese Systemadministration sowohl mit dem eigentlichen Rechnerbetrieb (Installation und Deinstallation, Installation eines Basis-Betriebssystems, Firmware, Anbindung ans Rechnernetz, hardware- und
netznahe Funktionsüberwachung) als auch mit der Applikationsadministration eng verwoben ist, können
diese Aufgaben im einen oder im anderen Bereich angesiedelt sein, und es ist in jedem Fall eine enge
Zusammenarbeit erforderlich. Die Ansiedlung beim Rechnerbetrieb bietet sich an, wenn die Applikationen von den Endbenutzern oder von den Kunden des LRZ eingebracht werden (Mitarbeiter-Arbeitsplätze,
Hosting/Housing, High-Performance-Computing), wenn eine hohe Anzahl gleichartiger Systeme vorliegt
oder wenn die Applikationsadministratoren dem Betrieb organisatorisch benachbart sind. Bei den Netzdiensten mit ihrem eher individuellen Applikationsprofil hat es sich bewährt, die Systemadministration
organisatorisch im Umfeld der Applikationen anzusiedeln.
•
1.6.1 Serveradministration in BDS
Der Abteilung BDS oblag Ende 2010 die Administration folgender Serversysteme:
• 38 (Vorjahr 21) virtuelle Maschinen mit Linux-Betriebssystem
• 33 (unverändert) physische Maschinen mit Linux-Betriebssystem
• 15 (Vorjahr 20) physische Maschinen mit Solaris-Betriebssystem
• 211 (Vorjahr 160) Serversysteme für die IT-Infrastruktur des Bibliotheksverbundes Bayern (Details siehe Kapitel 1.10; diese Systeme werden in diesem Abschnitt nicht mehr betrachtet)
Diese Maschinen wirken im Umfeld der Webservices (Webserver, Content-Management, verschiedene
Backendserver), der Datenbanken, der Lizenzverwaltung und weiterer Netzdienste (FTP, Groupware). Sie
beherbergen auch einige Dienste der Rechnerüberwachung und -steuerung (OVO, Konsolserver, Administratorengateways) sowie des Netzmanagements und der Netzüberwachung.
Bei den virtuellen Systemen liegt der Rechnerbetrieb bei der Betreibergruppe der VMWare-Systeme in
der Abteilung HLS; bei den physischen Systemen werden die Maschinen von den Systemadministratoren
auch betrieben.
Im Jahr 2010 ist neben den oben erwähnten Daueraufgaben folgendes durchgeführt worden:
• Mehrere Dienste wurden von realer Hardware unter Solaris oder Linux auf virtuelle VMWareMaschinen verlagert oder neu auf virtuellen Maschinen eingerichtet. Das spiegelt sich auch im
gewachsenen Anteil virtueller Maschinen wider, wie er aus den Zahlen oben hervorgeht.
• Die MySQL-Serverlandschaft wurde stark erweitert und auch neu strukturiert. Hintergrund ist die
bedeutende Ausweitung des Angebots der E-Learning-Plattform Moodle für die beiden Universitäten und des Content-Management-Systems Typo3 für die TUM. Allein hier sind acht weitere
virtuelle Maschinen hinzugekommen.
• Die E-Learning-Plattform Moodle insbesondere für die TUM hat darüber hinaus den Aufbau von
sieben weiteren Servermaschinen erfordert.
• Das Server- und Dienstmonitoring auf Applikationsebene, insbesondere mittels Nagios, wurde
wesentlich ausgebaut und um eine Visualisierung der anfallenden Daten ergänzt.
• Außerdem wurden die Anforderungen der Systemadministration in abteilungsübergreifende Arbeitskreise eingebracht (siehe Kapitel 4):
• Mit dem Arbeitskreis Informationsmanagement (siehe Abschnitt 4.4) wurden die Vorschläge zur
Verbesserung des LRZ-Informationsmanagements weiter konkretisiert. Insbesondere wurde der
Dienstebaum, wie er künftig dem Incident-Management zugrundeliegen wird, als Grundlage der
Struktur in die interne Dokumentation eingeführt.
• Mit dem Arbeitskreis Continuity (siehe Abschnitt 4.3) wurden die Vorgehensweisen bei geplanten und ungeplanten Betriebsunterbrechungen weiter spezifiziert.
1.6.2 Service für das Münchner Wissenschaftsnetz
Wie schon in den Vorjahren gibt es Daueraufgaben nicht nur beim Betrieb der obengenannten Server,
sondern darüberhinaus als Dienst im gesamten Münchner Wissenschaftsnetz:
•
•
•
•
•
1.7
29
Verteilung von Software im Rahmen des Sun Campus-Vertrages, Beratung der Anwender im
MWN in Bezug auf den Sun Campus-Vertrag,
Unterstützung der Anwender bei der Nutzung der LRZ Lizenzserver; speziell bei Ansys und Matlab ist der Unterstützungsbedarf sehr hoch,
Unterstützung bei Beschaffung, Installation und Konfiguration von Hardware und Software,
Unterstützung und Beratung von Systemadministratoren im MWN bei Problemen zu Hardware
und Software („bootet nicht mehr“, „Platte defekt, was tun?“, ...) sowie
Unterstützung von Systemadministratoren im MWN bei Security-Problemen oder bei Hackervorfällen
Desktop-Applikationsservices
Die zentralen Themen gruppieren sich nach wie vor um den Aufbau und Betrieb von Infrastrukturdiensten im Münchner Wissenschaftsnetz. Dazu gehört der Betrieb von Windows Servern für interne und externe Kunden, die Anbindung des „Speichers für die Wissenschaft“ an Arbeitsplatzrechner unter
Windows und Linux, die Nutzung eines MWN-weiten Active Directories für Arbeitsplatzrechner bei
Institutionen in einem delegierten Administrationsmodell, dem Aufbau eines mandantenfähigen Softwareverteilungstools und der Nutzung von Sharepoint 2010 als Kollaborationsplattform. Weitere (Pilot-)
Kunden aus LMU und TUM konnten für diese Dienste im Life-Cycle-Management von Arbeitsplatz-PCs
gewonnen werden. Insbesondere wird auch die LRZ-eigene PC-Landschaft (Pool, Kursräume, Spezialarbeitsplätze, Mitarbeiter-PCs, Server) nach und nach in die neue Management-Infrastruktur aufgenommen
und dort betrieben. Das dient nicht zuletzt der Erfahrungssammlung für das eigene Dienstportfolio.
1.7.1 Sicherheitsdienste für Desktops im MWN
1.7.1.1
Antiviren-Service
Auf der Grundlage eines Landesvertrages über die Antiviren-Software der Fa. SOPHOS hat das LRZ eine
Service-Infrastruktur zur automatischen Verteilung und Installation von SOPHOS-Virensignaturen für
alle Nutzer im Münchner Wissenschaftsnetz eingerichtet, verbunden mit entsprechenden Beratungsleistungen zur Nutzung für Endbenutzer und CID-Betreibern in Bayern.
In ersten Quartal 2010 wurde die Infrastruktur von der Version 7.x auf die Version 9.x gehoben. Dadurch
können nun auch 64-bit Systeme unterstützt werden. Das LRZ war dabei das erste der bayrischen UniRechenzentren und konnte die gewonnen Erfahrungen weitergeben. Der neue Sophos Server wird als
virtuelle Instanz im LRZ-VMware-Cluster betrieben.
Die Anzahl der monatlichen Zugriffe verdeutlicht Abbildung 5. Es ist zu berücksichtigen, dass PCClientsysteme oft mehrmals am Tag zugreifen. Als jeweils ein Client werden auch sog. Proxys gezählt,
die wiederum eine Weiterverteilung der Daten an ihre PC-Clientsysteme ermöglichen. Die tatsächliche
Zahl von Clients wird auf ca. 25.000 geschätzt (weiterführende Serviceinformationen siehe:
http://www.lrz.de/services/security/antivirus/).
1.7.1.2
Windows Software Update Service
Als weiterer Basisservice für das automatische Update von Windows-Betriebssystemen und Microsoft
Applikationen wie Internet Explorer oder Office wird der „Windows Software Update Service“ (WSUS)
als MWN-weiter Dienst angeboten. Der Service ist seit Längerem mit guten Erfahrungen innerhalb des
LRZ in Gebrauch und kann auch von allen Endkunden im MWN über das LRZ benutzt werden. Der
Dienst wurde aktiv von rund 6.500 Rechnern genutzt. Die hohe Akzeptanz des Service im Münchner
Wissenschaftsnetz verdeutlicht auch Abbildung 6 (weiterführende Serviceinformationen siehe:
http://www.lrz.de/services/security/mwnsus)
30
Abbildung 5: Zugriffe auf den Antiviren-Service im November 2010
Abbildung 6: Zugriffe auf den Windows Software Update Service im Jahr 2010
1.7.2 Active Directory im Münchner Wissenschaftsnetz
Als weiteren, großen Infrastrukturdienst betreibt das LRZ für das MWN ein mandantenfähiges Active
Directory (AD). Der Aufbau des zentralen, MWN-weiten AD wurde im Jahr 2007 im Rahmen der Bereitstellung von Exchange und der Fileservices auf Basis von NetApp mit CIFS notwendig.
Dieses AD ist so angelegt, daß einzelne, große Institutionen wie LMU, TUM oder die BAdW voneinander getrennt agieren können. Ziel ist es dabei, Synergien bei der Administration von Desktop-PCs zu erschließen und Verbesserungen 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, Gruppen, Funktionskennungen oder auch Ressourcen für Exchange 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
31
Terminalserver auf Basis von Windows Server 2003 und 2008 zur Verfügung gestellt. Die Einrichtung
dieser Organisationsstrukturen wurde in 2008 für die TU München umgesetzt und wird stetig in 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 Metadirectories (SIM, TUM) am LRZ gepflegt.
Dabei kommen Softwarelösungen der Firma Novell zum Einsatz.
Mit diesem Active Directory können alle Clients ab Windows 2000 verwaltet, Mac OS X und LinuxSysteme integriert werden. Momentan sind aus den drei großen Mandanten TUM, LMU und BAdW rund
1850 Rechner im AD integriert. Es wurden bisher rund 232 (160) Teiladministratoren aus 181 (105) Einrichtungen registriert und in 2010 haben sich an der Infrastruktur rund 13.000 verschiedene Nutzer angemeldet. Dabei wurden Dienste wie das Ablagesystem oder die Groupware Exchange genutzt.
In 2010 fand der Upgrade der Domäne auf Windows 2008 R2 statt. Dabei wurde die Anzahl der Domänen Controller auf drei reduziert. Hinzu kamen zwei Read only Domain Controller (RODC) an den Außenstellen in Martinsried und Weihenstephan. Die RODCs gewährleisten auch bei einem Ausfall der
Netzanbindung an das LRZ eine Anmeldung an den Clients.
1.7.2.1
Provisionierung der Benutzer in das Active Directory
Seit 2009 erfolgt die Provisionierung der Benutzerkonten der TU München aus den Metadirectories in das
Active Directory durch den Identity Manager Driver for Scripting von Novell, der Attributsänderungen an
vom LRZ selbstentwickelten Powershell Skripten an die AD-Seite übergibt. Dadurch wird eine enorme
Flexibilität beim Verarbeiten und der Fehlerbehandlung von Ereignissen erreicht.
In 2010 wurden die Skripte angepasst, um weitere Funktionen erweitert, die Anbindung eines weiteren
Metadirectories (LRZ-SIM) realisiert und für die Versorgung eines weiteren Active Directories eduroam.mwn.de übertragen.
1.7.2.1.1
LRZ-SIM
Auf der Codebasis des IntegraTUM-Treibers wurden eigene Scripte für LRZ-SIM realisiert. Die wichtigste Erweiterung war hierbei, dass nun nicht nur Benutzerobjekte, sondern auch andere Objekte verarbeitet werden können. Dies war notwendig, da die Abbildung der Projekte in der Nutzerverwaltung von
LRZ-SIM AD-seitig in Universal-Gruppen erfolgt.
Außerdem mussten in vielen Bereichen die Funktionen von IntegraTUM angepasst werden, da die Daten
in den beiden verschiedenen Directories einem unterschiedlichen Prozessablauf unterliegen. Bestes Beispiel ist hier das Löschen von Objekten, welches in LRZ-SIM zu einer direkten Löschung führt. Im IntegraTUM-Treiber führt hingegen eine Änderung des Dienststatus zu einer Löschung im AD.
1.7.2.1.2
IntegraTUM
Der Treiber wurde überarbeitet und die Funktionalität, dass beliebig verschiedene Objekte im Treiber
verwendet werden können, aus dem LRZ-SIM Treiber übernommen. Dies geschah mit der Zielsetzung,
im IntegraTUM-Treiber Objekte wie Gruppen oder Funktionsobjekte zu verarbeiten. Damit wurde die
Voraussetzung geschaffen, um Exchange-relevante Objekte wie Verteiler und Shared Mailboxen über die
in 2011 geplanten Erweiterungen in TUMOnline zu provisionieren.
1.7.2.1.3
Eduroam
Für Eduroam konnte der LRZ-SIM Treiber im Wesentlichen übernommen werden, da eduroam hier auch
über das LRZ-SIM-Metadir provisioniert wurde. Der Umfang der verarbeiteten Attribute wurde auf das
Nötigste beschränkt, wodurch der Code deutlich gekürzt werden konnte.
In allen Treibern hat die erweiterte Fehlerbehandlung Einzug gehalten. Dies beinhaltet u.a. die Einführung von Fehlercodes, Vereinheitlichung der Fehlermeldungen und eine Überarbeitung des Loggings. Ein
wichtiges neues Feature ist, dass nun der Treiber abgebrochene Ereignisse erkennt und diese dann als
Fehler ausgibt. Fehlermeldungen werden in der Windows Ereignisanzeige protokolliert. Eine direkte Benachrichtigung der Verantwortlichen erfolgt per E-Mail. bzw. wird über einen lokalen Agenten an den
zentralen SCOM (System Center Operation Manager) weitergeleitet. Mit Hilfe eines Daily-Reports werden alle Ereignisse des Tages mit Statusangabe zusammengefasst und in einem eigenen Logfile gespeichert.
32
1.7.2.2
Active Directory Lightweight Directory Services - ADLDS
Mit ADLDS bietet Microsoft die Möglichkeit, eine veränderbare Kopie eines Active Directories auf einem eigenständigen Server zu betreiben. Dabei kann nicht nur der Datenbestand selbst verändert werden,
sondern auch das Schema beliebig erweitert werden. Änderungen werden aber nicht in das QuellVerzeichnis zurück geschrieben. Diese Technologie wurde für die Telefonanlage am LRZ verwendet. Die
VoIP-Telefone am LRZ lesen über einen LDAP-Zugriff aus dem ADLDS passend zur Telefonnummer
den Vor- und Nachnamen aus und zeigen diesen im Display der Telefone an. Dabei wurde das Format der
Telefonnummern aus dem Quell AD für die Telefonanlage angepasst. Eine zweite ADLDS-Instanz wurde
für die Anbindung der Druckabrechnungssoftware Pcounter am ITW der TUM aufgebaut, kam aber dann
nicht mehr zum Einsatz.
1.7.2.3
Network Policy Server - NPS
In 2010 wurden die Möglichkeiten des NPS von Microsoft näher untersucht. Der NPS bietet die Möglichkeit einer Authentifizierung oder Autorisierung von Geräten oder Nutzern gegenüber einem Netzwerk
Server, wie z.B. für IEEE 802.1x. In zwei Bereichen kam die Technik in 2010 unabhängig voneinander
zum Einsatz.
1.7.2.3.1
Eduroam
Der Dienst Eduroam ermöglicht Studenten und Hochschulmitarbeitern den Zugang zum Internet über
WLAN über eine 802.1x Authentifizierung. Dabei werden Benutzerdaten, die auf der Client-Seite eingegeben werden, über das Netzwerk versendet und in einem extra dafür aufgebauten Active Directory eduroam.mwn.de und zwei installierten und konfigurierten NPS-Servern geprüft. Den Dienst nutzen im Jahr
2010 rund 300 verschiedene Nutzer.
1.7.2.3.2
MAC-Adress Authorization im LRZ Pool
Um den Zugriff ins Netz im öffentlichen LRZ Pool von unbekannten Geräten zu verhindern, waren bislang MAC-Adressen fest an den jeweiligen Switchen hinterlegt. Mit der Umstellung auf NPS werden nun
die MAC-Adressen der Rechner als Benutzerobjekte im Active Directory hinterlegt. Meldet sich ein Gerät an den jeweiligen Switchen, prüfen diese die Berechtigung, am Netz teilzunehmen gegenüber dem
Active Directory ab. Die Verwaltung der Berechtigung konnte so ins AD verlagert und die notwendigen
Rechte für die Verwaltung der Switches reduziert werden. In den nächsten Monaten sollen weitere Pools
umgestellt und der Dienst an Externe weitergegeben werden.
1.7.3 Desktop Management
Die PC-Gruppe hat unterschiedliche Modelle für die Bereitstellung von aktuellen WindowsArbeitsplätzen für verschiedene Kundengruppen entwickelt. Die Lösungen reichen dabei vom vollwertigen Mitarbeiterarbeitsplatz über Terminalserverlösungen für Mitarbeiter bis zum virtuellen Desktop für
Testzwecke. Für Studenten werden sowohl vollwertige Rechnerpools als auch auf Terminalserverlösungen basierende Pools angeboten. Im Rahmen des MWN-AD wird der Light-Desktop angeboten, bei dem
Institutionen Rechner in die Infrastruktur integrieren können und so die Vorteile des zentralen MWN-AD
für das Desktopmanagement mitnutzen können, ohne selbst die Infrastruktur zu betreiben. Die Administration der integrierten Instituts-PCs übernehmen dabei wie bisher die lokalen Administratoren. Die verschiedenen Rechnergruppen setzen sich zahlenmäßig Ende 2010 wie in Tabelle 17 gezeigt zusammen.
Bei den Kunden für den Remote Desktop Management Service in der ADS/LRZ-Domäne fanden in 2010
einige Umrüstungen statt:
• LMU BIO: Aufbau eines Rechnerpools mit Windows 7
• BAdW: laufende Modernisierung der Hard- und Softwareausstattungen
• LRZ:
o laufende Modernisierung der Hard- und Softwareausstattung an den Clients
o Beginn der Windows 7 Verteilung
o Umzug der Clients in das MWN-AD
o Umstellung von Pool und Kurs auf Windows 7
Auch im Jahr 2010 wurden viele Stunden für Kundenberatung erbracht, um das Angebot des zentralen
Speichers und des „Desktop Light“ vorzustellen.
Light Desktop
LRZ
33
Pool und Kurs
Fully Managed Desktop
57 (57)
193 (189)
BAdW
171 (173)
TUM
1272 (582)
37 (37)
LMU
153 (117)
35 (27)
HMT
60 (60)
HFF
8 (8)
Summen
1425 (699)
197 (189)
364 (362)
Tabelle 17: Clients im MWN-AD
1.7.3.1
System Center Configuration Manager (SCCM)
Um das Deployment und Management von Windows Desktops und Serversystemen zu optimieren, wurde
der im vergangenen Jahr in Produktion gesetzte System Center Configuration Manager weiter ausgebaut
und in die vorhandene Infrastruktur integriert.
Der SCCM ist ein Produkt von Microsoft, das zu einer Vielzahl von Management-Produkten der System
Center-Familie gehört. Er ermöglicht ein Betriebssystemrollout als Bare-Metal Variante (auf einem leeren
System) sowie als in-place Upgrade oder Neuinstallation über ein bereits vorhandenes System. Im letzteren Fall werden dabei auch Einstellungen und Nutzdaten migriert. Desweiteren ist es möglich, Software
auf die gemanagten Clients zu installieren, aktualisieren oder deinstallieren. Ein integriertes Reporting
gibt Aufschluss über die Erfolgsrate des Rollouts und etwaige aufgetretene Fehler. Zudem wurde im Jahr
2010 das Patchmanagement über den WSUS integriert, so dass alle Clients mit den jeweils aktuellen Patches von Microsoft versorgt werden.
Ein weiteres Ziel war es, das Produkt für eine Nutzung durch Teiladministratoren des MWNs freizugeben. Obwohl der SCCM in der aktuellen Version 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. Für die Erprobungsphase konnten hierzu einige Lehrstühle
gewonnen werden, um mit deren Feedback den Dienst weiter zu verbessern.
Insgesamt gibt es nun je nach Gegebenheit und Anforderung mehrere Varianten für Administratoren, ihre
Systeme zu managen und installieren:
• Erstellung eines Muster-PCs: Hierbei erstellt der Administrator einen Muster-PC, der anschließend als Image „aufgezeichnet“ wird. Dieses Image kann nun in relativ kurzer Zeit auf eine Vielzahl von Rechnern wieder aufgebracht werden. Das Verfahren eignet sich in erster Linie bei
Pools und Kursräumen, kann aber auch bei einer Erst-/Grundinstallation von Mitarbeiterrechnern
eingesetzt werden.
• Bare-Metal Installation mit definiertem Software-Portfolio
• Einspielen von Software-Paketen auf eine (Teil-)Menge der administrierten Rechner
• Einsehen von Inventarinformationen, Hardwarekonfigurationen
Software-Pakete, die sich bereits im Software Repository befinden, können jederzeit benutzt werden entsprechende Lizenzierung durch den Kunden vorausgesetzt. Software, die nicht vorhanden ist (in der
Regel Spezialsoftware von Fakultäten), wird für den Kunden paketiert und nach Aufwand in Rechnung
gestellt. Das LRZ übernimmt bei gemanagten PCs zudem die Aktualisierung von Standardsoftware, die
aus Sicherheitsgründen aktualisiert werden muss (z.B. Mozilla Firefox, Adobe Flash).
Um das verfügbare Software Repository stets aktuell zu halten und an die Bedürfnisse der Nutzer auszurichten, wurden im vergangenen Jahr durchgehend Software-Pakete aktualisiert sowie neue Software in
das Repository eingepflegt. Insgesamt stehen derzeit 313 reine Software-Pakete bereit (Treiber-Pakete
und Betriebssysteme nicht eingerechnet).
34
Innerhalb des LRZ und der BAdW hat der SCCM den alten Deployment-Mechanismus über Microsoft
Remote Installation Services (RIS) und Windows Deployment Services (WDS) im Jahr 2010 vollständig
ersetzt. Dabei werden sowohl die Mitarbeiter-PCs und -Laptops als auch Serversysteme und virtuelle
Maschinen über den SCCM installiert und gemanaged.
Insgesamt, d.h. MWN-weit, werden vom System Center Configuration Manager 489 Systeme (im Vorjahr 370) verwaltet.
Für 2011 ist eine kontinuierliche Verbesserung des Dienstes vorgesehen. So sollen ein höherer Automatisierungsgrad beim Deployment und Management erreicht werden. Ebenso soll die Mandantenfähigkeit
weiter verbessert werden und die Bedienung für Administratoren vereinfacht werden.
1.7.4 Server Management
Die PC-Gruppe betreut im Rahmen ihrer Tätigkeit auch zahlreiche Serversysteme. Zum einen zur Erbringung der Hintergrunddienste für den Clientbetrieb, wie das MWN-AD, Exchange oder die Softwareverteilung SCCM, zum anderen für andere Abteilungen oder für externe Kunden.
Das letzte Jahr stand dabei im Zeichen der zunehmenden Server-Virtualisierung. Neue Server werden nur
noch als virtuelle Instanzen in Betrieb genommen und zahlreiche Server auf physischer Hardware wurden
virtualisiert. Dabei konnten Neuanschaffungen von Hardware, die aus der Garantie gelaufen war, vermieden und auch Stromkosten eingespart werden. Bislang sind die Erfahrungen mit den virtualisierten Maschinen zufriedenstellend. Nachfolgend werden einige der wichtigsten Veränderungen in 2010 im Bereich
des Server Managements angeführt.
1.7.4.1
MS-SQL-Server Cluster
Mit der Einführung des LRZ-VMware-Cluster wurde ein MS-SQL-Server Cluster auf Basis der Microsoft
Cluster Services aufgebaut. Dabei wurde der Speicher für die Datenbanken über iSCSI angebunden. In
den letzten Monaten kam es aufgrund von Netz- und NAS-Wartungen immer wieder zu größeren Unterbrechungen in der Verfügbarkeit des Clusters und der VMware-Management Werkzeuge. Um diese Abhängigkeiten aufzulösen, wurde in 2010 ein neues Cluster aus zwei physischen Maschinen auf Basis von
MS-SQL 2008 R2 aufgebaut. Der Storage für die Datenbanken ist nun lokal angebunden. Somit wurde
eine weitestgehende Abhängigkeit vom zentralen NAS und vom Netz aufgelöst. Die Datenbanken selbst
werden entweder gespiegelt betrieben oder bei Datenbanken, wo dies nicht notwendig ist, werden diese
nur auf einem der beiden Server betrieben. Mithilfe von internen Methoden des SQL-Servers werden
dann die Datenbanken gesichert, bereinigt und anderen Wartungsschritten unterzogen. In 2011 sollen
weitere MS-SQL-Datenbanken von älteren Systemen auf den leistungsfähigeren zentralen MS-SQLDatenbankcluster umgezogen werden.
1.7.4.2
Citrix-Terminalserverfarm
In 2010 stand die Erneuerung der auf Windows 2003 basierenden Citrix Farm an. Auf Basis von VMware
wurden fünf virtuelle Server mit Windows 2008 x64 und Citrix Xenapp 5.5 aufgebaut. Drei der Server
dienen dabei als Applikationsserver, ein Server fungiert als Webserver, der die Clients über https an die
Applikationsserver weiterleitet und nun die veröffentlichten Anwendungen auch über ein Webinterface
zur Verfügung stellt. Der fünfte Server agiert als Secure Gateway und ermöglicht den Zugriff auf die
Citrix-Farm von außerhalb des MWN. Damit ist es den Mitarbeitern möglich, von überall auf ihre Daten
bzw. „gepublishten“ Applikationen zuzugreifen und somit die Flexibilität zu erhöhen.
1.7.4.3
Exchange 2010
Im Rahmen der Migration auf 2010 war die PC-Gruppe intensiv in den Neuaufbau und die Migration der
Exchange Infrastruktur eingebunden. Wichtigstes Ziel hierbei war das Auflösen von Abhängigkeiten von
Hardware und Netz und die Aktualisierung der Betriebssysteme mit Windows 2008 R2. So konnte durch
die Virtualisierung sämtlicher Serversysteme eine größere Flexibilität von Systemressourcen (CPU und
Memory) und eine erhöhte Datensicherheit durch Snapshots gewonnen werden. Mit der Einführung von
Database Availability Groups (DAG) in Exchange 2010 wurde auch das fehleranfälligere Single Copy
Cluster von Exchange 2007 abgelöst.
1.7.4.4
35
iET ITSM
Das LRZ ist derzeit dabei, ein IT-Servicemanagement nach ISO/IEC20000 aufzubauen. Hier wurde als
Tool-Unterstützung das Produkt „iET ITSM“ von iETSolutions ausgewählt. Neben der Betreuung der
Systeme ist die PC-Gruppe zudem im LRZ Entwicklungsteam vertreten und kümmert sich um die Integration und Anpassung des Tools.
Um einen langfristigen und stabilen Betrieb zu gewährleisten, wurde zu Beginn des Jahres ein Betriebskonzept entwickelt und der Aufbau der Serversysteme durchgeführt. Für in-House-Entwicklungen und
Anpassungen am Tool wurden hierzu zunächst Entwicklersysteme installiert. Später folgten jeweils ein
Test-, Schulungs- und Produktionssystem. Alle Systeme können über eigens konzipierte Updatemechanismen auf den neuesten Stand gebracht werden. Damit im Tool immer aktuelle Kunden- und KontaktDaten vorliegen, wurde hierfür eine Schnittstelle zu LRZ-SIM (Secure Identity Management) als Ort der
Wahrheit für Kundendaten programmiert. Des Weiteren wurde die Nutzer-Authentifizierung im Tool an
LRZ-SIM gebunden. Somit können sich die Mitarbeiter (via Client) und Kunden (via Webportal) mit
ihren persönlichen Kennungsdaten anmelden.
Der Fokus von Anpassungen im Tool wurde im Jahr 2010 auf das Incident Management gelegt. Hierfür
wurden die Formulare angepasst, Abfragen geändert und weitere Anforderungen gemäß der LRZProzessdefinition umgesetzt. Als Pilotgruppe testete die Linux-Cluster-Gruppe (und später zusätzlich
noch die HLRB-Gruppe) das Incident Management, das im Jahr 2011 das bisherige Ticketsystem ablösen
soll.
Parallel dazu wurde in einer Arbeitsgruppe, die sich aus allen Abteilungen zusammensetzte, ein CMDBKonzept sowie deren Integration in iET ITSM entwickelt. Das Konzept wurde dazu in mehreren Proof-ofconcepts auf Tauglichkeit und Erweiterbarkeit getestet und wird im Jahr 2011 umgesetzt.
1.7.4.5
VMware Infrastruktur
Die PC-Gruppe ist auch am Betrieb der virtuellen Infrastruktur des LRZ beteiligt. Zum Einen erfolgt das
Deployment von virtuellen Windows-Maschinen (Servern und Clients) ausschließlich durch die PCGruppe. Hierfür wird wie oben bereits beschrieben SCCM eingesetzt. Zum Anderen obliegt der Gruppe
die Administration des zentralen vCenter-Servers, der für das Management der ESX-Hosts zuständig ist.
Hier wurde im vergangenen Jahr ein Upgrade auf vSphere Version 4.1 vorgenommen sowie die dahinter
liegenden Verwaltungsdatenbanken auf das neue SQL-Cluster verschoben.
Seit vergangenem Jahr wurden die Kompetenzen weiter ausgebaut, so dass es nun einen Ansprechpartner
in dieser Gruppe für die gesamte VMware-Administration gibt. Dies dient auf der einen Seite der Entlastung der Gruppe COS, die diese Aufgabe bisher alleine bewältigt hat, und sorgt andererseits für größere
Redundanz bei etwaigen Störungen. Um die Kompetenzen nachhaltig auszubauen, nahmen zwei Mitglieder an einer Schulung für vSphere 4.1 teil, die die Basis für die Zertifizierungsprüfung zum VMware
Certified Professional (VCP) bildet. Die Zertifizierungsprüfung ist für das Jahr 2011 geplant.
1.7.5 Microsoft Office Sharepoint Services (MOSS)
In 2009 wurde mit dem Aufbau einer Kollaborationslösung auf Basis von MOSS 2007/2010 begonnen
und in 2010 fortgesetzt. Ziel ist zum einen die Ergänzung der Groupwarelösung von Exchange
2007/2010, da hier die public Folder entfallen sind und diese durch MOSS ersetzt wurden. Zum anderen
bietet MOSS die Möglichkeit, für Gruppen die Zusammenarbeit zu verbessern, um z.B. gemeinsam an
Dokumenten zu arbeiten oder die Zusammenarbeit besser über Gruppenkalender, Besprechungsbereiche,
Benachrichtigungen, Wikis oder gemeinsame Aufgaben zu organisieren. Es gibt auch die Möglichkeit,
komplexere Prozesse in Workflows abzubilden, die häufig in Verwaltungen zum Einsatz kommen. Der
Zugriff auf die Ressourcen erfolgt webbasiert.
Auf der bereits in 2009 aufgebauten MOSS-2007-Farm wurden weitere Sites angelegt, um weitere Erfahrungen in der Zusammenarbeit zu gewinnen. Zu Beginn des dritten Quartals 2010 wurde die neue Version
von MOSS 2010 veröffentlicht. Nach den bereits erfolgversprechenden Tests mit den Vorversionen des
Produktes mit verbesserten Verwaltungs- und Bedienoberflächen wurde im Sommer rasch eine neue
Farm auf Basis von MOSS 2010 aufgebaut. Es handelt sich dabei um einen Datenbankserver mit MSSQL 2008 und einem dedizierten Server für die MOSS-Installation. Die Sites sind von außerhalb über ein
Forefront Threat Management Gateway (TMG) zugänglich.
36
Da der Dienst auch kostenpflichtig für Externe angeboten wird, wurde großes Augenmerk auf die Abtrennung einzelner Mandanten (TUM, LMU, BAdW, LRZ-SIM) gelegt. Dies wird über eine Auftrennung
der Mandanten im AD und verschiedene Proxy Accounts abgebildet. Aus dem Alltagsbetrieb ergab sich
eine Auftrennung der einzelnen Sites in eigene Datenbanken, Ressource Pools und IIS-Websites mit individuellen Ports. Das erhöht die Modularität und es können so einzelne Sites unabhängig voneinander
gesichert und wieder hergestellt werden. In enger Zusammenarbeit mit den Site-Nutzern fanden verschiedene Anpassungen von Sites statt.
Der Nutzerkreis umfasste zum Ende des Jahres 2010 neben mehreren Sites für die Gruppenkoordination,
Ausbildung und Hotline auch Sites für die Koordination zweier bayernweiter Arbeitskreise und auch zur
Koordination mit externen Dienstleistern des LRZ für den neuen Höchstleistungsrechner. Zwei zahlende
externe Kunden konnten auch gewonnen werden. Eine besondere Herausforderung stellte dabei eine
komplexe Migration einer MOSS 2007 Site von einem externen Altsystem in die LRZ-Installation dar.
1.7.6 Tätigkeiten im Rahmen der Berufsausbildung
Der PC-Gruppe waren in 2010 zunächst vier und dann, ab September, drei Auszubildende der Fachrichtung Fachinformatiker Systemintegration (FISI) zugeordnet. Die Auszubildenden sollen dabei den Alltag
eines Systemadministrators kennenlernen und auch projektorientiert arbeiten. Zwei Auszubildende konnten im Frühjahr/Sommer 2010 erfolgreich ihre Abschlussprüfung ablegen. Ein Auszubildender wurde
vom LRZ übernommen. Die Themen der Abschlussarbeiten ergaben sich aus dem aktuellen Arbeitsumfeld und umfassten zum einen den Aufbau eines NPS Servers und zum anderen die Umstellung der Kursräume auf Windows 7 mit den entsprechenden Anpassungen im MWN-AD und dem SCCM.
Seit Anfang Oktober werden die Auszubildenden auch in der Hotline/Beratung eingesetzt. Voran ging
eine intensive Schulung der Auszubildenden zu den wichtigsten Diensten am LRZ sowie eine allgemeine
Schulung im Umgang mit Kunden am Telefon.
Im Rahmen eines zweiwöchigen Austausches im Herbst 2010 mit dem Wissenschaftszentrum Weihenstephan (WZW) vermittelten die Auszubildenden am LRZ den Gästen vom WZW die vorher selbst über den
Sommer erworbenen Kenntnisse zu Installation und Betrieb eines Active Directory.
Weitere, wichtige Aufgaben der Auszubildenden in 2010 waren:
• Migration der LRZ-Rechner in die neue Domäne ads.mwn.de
• Softwarepaketierung
• Erarbeiten von Dokumentation für den allgemeinen Betrieb
• Mitarbeit im Life-Cycle Management der Rechner am LRZ
• vierwöchiges Praktikum in der LRZ-Netzwartung
1.8
Server- und Benutzerzertifizierung nach X.509
Das LRZ ist mit mehreren Zertifizierungs- und Registrierungsstellen (CAs und RAs) in die Zertifizierungshierarchie „Global“ der Public-Key-Infrastruktur des Deutschen Forschungsnetzes (DFN-PCA)
eingebunden, deren Wurzelzertifikat von einer kommerziellen CA (T-TeleSec Trust Center der Deutschen
Telekom AG) beglaubigt wird. Damit gibt es dann keine Notwendigkeit für die Endbenutzer, das Wurzelzertifikat explizit durch Import als vertrauenswürdig zu kennzeichnen, wenn das schon vom Hersteller der
Software erledigt wurde.
Das LRZ betreibt im Rahmen dieser Hierarchie eine Zertifizierungsstelle (CA) und Registrierungsstelle
(RA) sowie für die beiden Münchner Universitäten jeweils eine Registrierungsstelle.
Insgesamt gibt es am LRZ vier Registrierungsstellen, die derzeit neue Zertifikate ausstellen:
• eine RA für die Bayerische Akademie der Wissenschaften einschließlich des LRZ selbst sowie
für solche Einrichtungen im Münchner Wissenschaftsnetz, die keine eigene CA betreiben (102
neue Zertifikate im Jahr 2010)
• eine Server-RA für die TU München (72 neue Zertifikate im Jahr 2010)
• eine Server-RA für die LMU München (103 neue Zertifikate im Jahr 2010)
• eine Server- und Nutzer-RA für das Grid-Computing im Münchner Wissenschaftsnetz und an der
Universität der Bundeswehr München (zusammen 128 neue Zertifikate im Jahr 2010)
37
Die drei erstgenannten gehören dabei jeweils zu einer CA bei der jeweiligen Einrichtung; die Grid-RA
gehört zu einer CA, die von der DFN-PCA betrieben wird.
1.9
Bearbeitung von Missbrauchsfällen
Das LRZ ist bei der DENIC eG (d.h. bei der Registrierungsstelle für Domains unterhalb der Top-LevelDomain „DE“) als Ansprechpartner für Domains des Münchner Wissenschaftsnetzes (MWN) eingetragen
(u.a. für uni-muenchen.de, lmu.de, tu-muenchen.de und tum.de). Ähnliches gilt für die IP-Netze, die dem
LRZ zugeteilt wurden. Damit ist das LRZ Anlaufstelle für sehr viele Anfragen und Beschwerden, die
diese Domains bzw. IP-Adressen betreffen.
1.9.1 Statistik der Missbrauchsfälle
Im Jahr 2010 nahm die Zahl der entdeckten Missbrauchsfälle gegenüber dem Vorjahr wieder zu (siehe
Abbildung 7). Zum Einen kommen wegen der weitgehenden Kriminalisierung der Szene (d.h. der „VirenBastler“, Spammer und Hacker) nahezu ausschließlich „qualitativ hochwertige“ Schädlinge und AngriffsTools (Malware) zum Einsatz. Zum Anderen ist das Sicherheitsbewußtsein bzw. -verhalten zu vieler
MWN-Benutzer nach wie vor unzureichend. Diesem setzt das LRZ diverse sicherheitsrelevante Dienste
entgegen (siehe Abschnitt 1.7.1).
3000
Gemeldete Fälle
1860
Vom LRZ selbst entdeckte Fälle
2500
1362
2000
1319
1500
1085
500
0
792
377
1000
44
53
85
243
930
64
309
324
944
572
239
292
258
916
393
1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010
Abbildung 7: Missbrauchsfälle im MWN
Die insgesamt 2.776 Abuse-Fälle des Jahres 2010 betrafen 3.124 MWN-Rechner. In diesem Rahmen
erhielt das LRZ 1.227 Hinweise, Beschwerden, Anfragen usw. von außerhalb.
Zum Glück verletzten nur bei ganz wenigen Sicherheitsvorfällen MWN-Benutzer absichtlich die Nutzungsregeln; der überwiegende Teil der Fälle betraf Rechner,
• die von Würmern, trojanischen Pferden, Botnet-Drohnen usw. befallen wurden; die eingedrungenen Schädlinge versuchten dann ihrerseits, sich weiter zu verbreiten, oder der Rechner wurde
zu einem Teilnehmer an einem Botnet und verursachte danach Schäden (z.B. durch Versenden
von Spam-Mails).
• die über aktuelle Sicherheitslücken angegriffen, kompromittiert und dann für weitere Angriffe
missbraucht wurden.
38
Art der Vorgänge
Fälle mit rechtlichen Aspekten:
Verletzungen des Urheberrechts
Sonstige Fälle
Teilsumme
Sonstige kompromittierte Rechner:
DFN-CERT: Automatische Warnungen
Port-/Vulnerability-Scans
Sonstige Beschwerden (u.a. DoS)
DFN-CERT: Sonstige gemeldete Fälle
Teilsumme
Organisatorische Vorgänge:
Aktualisierung der Monitoring-Ausnahmelisten
Sonstige Fälle
Teilsumme
Fälle im Bereich „E-Mail“:
Sonstige Mail-Fälle
Spam-Versand über kompromittierte Rechner
Unberechtigte Spam-Beschwerden
Hinweise auf / Fragen zu Phishing-Aktionen
Teilsumme
Sonstige Fälle
Summe der gemeldeten Fälle
Involvierte
Eingegangene
Anzahl
Rechner /Benutzer Beschwerden,
der Fälle
des MWN
Anfragen usw.
649
2
651
677
2
679
686
2
688
173
5
4
3
185
471
5
5
3
484
173
8
6
3
190
26
9
35
30
7
37
3
8
11
11
8
7
4
30
15
916
3
8
‒
–
11
9
1.220
23
22
7
15
67
15
971
Tabelle 18: Missbrauchsfälle, die dem LRZ gemeldet wurden, oder organisatorische Vorgänge
Ca. 30% der bearbeiteten Fälle gehen auf Beschwerden, Hinweise, Anfragen usw. zurück, die dem LRZ
von außerhalb geschickt wurden, oder auf organisatorische Vorgänge (siehe Tabelle 18). Bei diesen Fällen sind folgende Punkte besonders erwähnenswert:
• Bei ca. 70% dieser gemeldeten Fälle handelt es sich um Verletzungen des Urheberrechts. Diese
Beschwerden haben seit 2008 drastisch zugenommen (siehe Abbildung 8).
Dabei werden Beschwerde-Mails von Organisationen verschickt, die im Auftrag von amerikanischen oder europäischen Rechte-Inhabern die wichtigsten File-Sharing-Netze kontinuierlich nach
Verletzungen des Urheberrechts durchsuchen. Selbst wenn diese Fälle bis jetzt noch keine juristischen Konsequenzen haben, sind es keine Kavaliersdelikte; auch nach deutschem Recht ist es
verboten, urheberrechtlich geschütztes Material (überwiegend Filme und MP3s und teilweise
auch Software) in File-Sharing-Netzen anzubieten. Unabhängig davon verstößt es auch gegen die
Nutzungsordnung des LRZ bzw. MWN.
• Das DFN-CERT beobachtet und analysiert eine Reihe von Quellen, um Probleme zu entdecken,
die sich auf Systeme der DFN-Anwender beziehen. Darüber hinaus werden eigene Sensoren betrieben, um die Informationsbasis weiter auszudehnen. Das DFN-CERT sammelt, korreliert und
normiert diese Daten und stellt jedem DFN-Anwender den Zugriff auf diejenigen Daten zur Verfügung, die die eigene Einrichtung betreffen.
Das LRZ nutzt seit März 2009 diesen Dienst „Automatische Warnungen“ und erhält in diesem
Rahmen entsprechende Hinweis-Mails. Da an das MWN mehr als 80.000 Endsysteme angeschlossen sind, trifft beim LRZ an vielen Werktagen eine Warnung ein, die meist mehrere auffällig gewordene IP-Adressen enthält.
39
800
Fälle
700
Beschwerden
686
617
600
649
570
500
400
267
300
239
200
100
0
9
21 37
20 28
9 10
2003
2004
2005
2006
9
44
54
2007
2008
2009
2010
Abbildung 8: Fälle wegen Verletzung des Urheberrechts
•
•
•
•
Bei den Monitoring-Verfahren (siehe unten) gibt es zwangsläufig jeweils eine Ausnahmeliste mit
Rechnern, bei denen das auffällige Verhalten legitim ist. Die Aktualisierung dieser Listen betraf
überwiegend das „Mail-Monitoring“, weil es relativ viele legitime Ursachen für ein erhöhtes
Mail-Aufkommen gibt:
o Inbetriebnahme eines neuen Mail-Servers/-Gateways oder Servers für Mail-Verteiler
o Regelmäßiges Verschicken von Rundbriefen mit vielen Empfängern
o Verschicken von Benachrichtigungen durch ein System, das die korrekte Funktion / Verfügbarkeit von Diensten oder Rechnern überwacht
Das LRZ geht i.a. aktiv auf die Betreiber von Rechnern zu, bei denen das Mail-Aufkommen vermutlich legitim ist (z.B. wenn im DNS-Namen die Zeichenfolge „mail“ vorkommt). Dies ist
auch der Grund dafür, dass die Fälle dieser Gruppe nur selten von LRZ-Kunden initiiert werden.
Früher kam es häufiger vor, dass ein Rechner mehrere Monate oder evtl. sogar Jahre am InternetÜbergang gesperrt blieb, weil sich niemand gemeldet hat. In diesen Fällen wurde dann das Entsperren in einem gesonderten Fall bearbeitet.
2010 gab es nur noch drei derartige Fälle (Teil der „sonstigen organisatorischen Fälle“), weil diese Sperren inzwischen nach 90 Tagen automatisch aufgehoben werden. Das LRZ hat die Erfahrung gemacht, dass nach 3 Monaten die Rechner meistens gesäubert oder neu installiert wurden.
Traf dies nicht zu, wurden die Rechner erneut gesperrt.
Bei den unberechtigten Spam-Beschwerden treten im wesentlichen zwei Fälle auf:
o Wenn ein Mail-System (z.B. die Mail-Server des LRZ) eine einmal angenommene EMail nicht zustellen kann, muss es laut Norm den Absender in einem Non-DeliveryReport (NDR) darüber informieren. Hat ein Spammer die eigene Mail-Adresse als Absender von Spam-Mails missbraucht, erhält man manchmal NDRs zu diesen Spam-Mails,
die man gar nicht selbst verschickt hat; in diesem Fall ist man ein indirektes Opfer des
Spammers.
Manche Empfänger fühlen sich durch diese nicht selbst ausgelösten NDRs derart belästigt, dass sie sich beim Betreiber des korrekt arbeitenden Mail-Systems beschweren.
o Manchmal erhält das LRZ Beschwerden über E-Mails, die nach Ansicht des LRZ einen
legitimen bzw. seriösen Inhalt haben. In diesen Fällen handelte es sich meist um Rundbriefe einer Organisation des MWN oder um Beiträge eines seriösen Newsletters. Manche Nutzer tragen sich selbst bei einem Newsletter ein, vergessen dies dann aber nach einiger Zeit und fühlen sich dann von Beiträgen des betreffenden Newsletters belästigt.
Auch 2010 wurden mehrere Phishing-Angriffe auf Mail-Accounts von MWN-Teilnehmern
durchgeführt. Meist melden sich dann freundlicherweise MWN-Teilnehmer, um das LRZ auf
40
diese Angriffe aufmerksam zu machen.
Leider hat sich immer noch nicht überall herumgesprochen, dass man nach einer Aufforderung
per E-Mail niemals Account-Daten herausgeben darf. Entsprechende Schutzeinrichtungen bei
den Mail-Systemen des LRZ verhindern aber, dass gestohlene Mail-Accounts in großem Umfang
zum Versenden von Spam-Mails missbraucht werden können.
Zu den von außerhalb gemeldeten Fällen kamen weitere, auf die das LRZ im Rahmen der Netzüberwachung selbst aufmerksam wurde (siehe Tabelle 19). Die Monitoring-Verfahren am Internet-Übergang
(d.h. am Übergang vom MWN zum X-WiN) sind trotz ihrer Einfachheit erstaunlich wirksam; folgende
Indikatoren eignen sich erfahrungsgemäß sehr gut, um (sehr wahrscheinlich) kompromittierte Rechner zu
entdecken:
• Bei der ersten Gruppe ist der Indikator derart treffsicher, dass das LRZ riskiert, die auffällig gewordenen Rechner automatisch am Internet-Übergang zu sperren; die zuständigen Netzverantwortlichen werden selbstverständlich ebenso automatisch sofort davon verständigt.
o Der Rechner ist mit einem der folgenden Schädlinge infiziert:
 Trojaner „Bredolab“
 Wurm „Conficker“
 Trojaner „Gozi“
 Botnet-Drohne „Mariposa“
 Botnet-Drohne „Torpig“
 Virus „Sality“
o „SSH-Angriff“ durch einen MWN-Rechner. In diesen Fällen öffnet der MWN-Rechner
innerhalb kurzer Zeit viele SSH-Verbindungen zu anderen Rechnern im Internet. Ein
kompromittierter MWN-Rechner
 sucht dabei nach Rechnern mit einem aktiven SSH-Server, d.h. es handelt sich
um einen SSH-Scan.
 versucht sich per SSH bei einem anderen Rechner anzumelden. Dabei werden
Kennungen ausprobiert, die bei vielen Systemen vorhanden sind (wie z.B. „root“,
„admin“ oder „guest“). Als Passwort testet man eine Liste von Wörtern, die sehr
oft als Passwort verwendet werden; es handelt sich also um einen Angriff auf
„schlechte“ Passwörter. Es ist erschreckend, wie häufig man auf diese einfache
Art in einen Rechner einbrechen kann.
o Auf dem Rechner läuft ein FTP-Server, der auf einem Nicht-Standard-Port arbeitet (d.h.
nicht auf dem allgemein üblichen Port 21).
• Bei den restlichen Indikatoren werden Benachrichtigungs-Mails vorformuliert; ein Mitglied des
Abuse-Response-Teams entscheidet jedoch jeweils, ob die E-Mail auch abgeschickt und der
Rechner evtl. zusätzlich gesperrt werden soll.
o Der MWN-Rechner öffnet innerhalb kurzer Zeit viele Mail-Verbindungen zu anderen
Rechnern im Internet. Diese MWN-Rechner sind fast immer kompromittiert, wobei der
Rechner zum Versenden von Spam- oder Phishing-Mails missbraucht wird.
Dieses Monitoring-Verfahren wird kurz als „Mail-Monitoring“ bezeichnet.
o Der MWN-Rechner öffnet innerhalb kurzer Zeit extrem viele Verbindungen zu anderen
Rechnern im Internet. Durch zusätzliche Indikatoren kann man erkennen, ob es sich
wahrscheinlich um einen massiven Port-Scan oder um einen Denial-of-Service-Angriff
(DoS) handelt.
o Der Rechner fällt durch einen außergewöhnlich hohen Datenverkehr auf. Es handelt sich
dabei auch manchmal um Rechner, die für die Verteilung urheberrechtlich geschützter
Daten missbraucht wurden.
o Ein aktiver SSH-Server eines MWN-Rechners wird extrem oft kontaktiert. In diesen Fällen ist der MWN-Rechner (noch) nicht kompromittiert, sondern das Opfer eines Angriffs
auf „schlechte“ Passwörter (siehe oben). Das Abuse-Response-Team weist den Ansprechpartner des MWN-Rechners auf den erfolgten Angriff hin und gibt ihm den Rat, in
den Log-Meldungen des SSH-Servers nach erfolgreichen Anmeldevorgängen zu suchen;
es könnte sich dabei um einen Einbruch handeln.
Nur im Falle eines „SSH-Angriffs“ durch einen MWN-Rechner erfolgt die automatische Sperre sofort bei
der ersten Auffälligkeit. Bei den übrigen Monitoring-Verfahren mit einer automatisierten Reaktion wird
eine dreistufige Eskalation durchgeführt:
41
1. Der Rechner fällt zum ersten Mal auf:
Eine Informations-Mail wird verschickt.
2. Nach mindestens einem Tag fällt der Rechner erneut auf:
Eine Erinnerungs-Mail wird verschickt.
3. Nach mindestens einem weiteren Tag fällt der Rechner noch einmal auf:
Der Rechner wird gesperrt und eine entsprechende Benachrichtigung verschickt.
Zu den aufgeführten Indikatoren gibt es natürlich jeweils eine Ausnahmeliste von bekannten „sauberen“
Rechnern, die dadurch vor einer Sperre geschützt werden.
Verfahren,
durch das die verdächtigen Rechner entdeckt wurden
Explizit erkannte Schädlinge:
Wurm „Conficker“
Trojaner „Bredolab“
Trojaner „Gozi“
Botnet-Drohne „Mariposa“
Botnet-Drohne „Torpig“
Sonstige Botnet-Drohnen
Virus „Sality“
Teilsumme
Sonstige Monitoring-Verfahren:
NAT-o-MAT (schwere Fälle)
Mail-Monitoring
„SSH-Angriff“ durch einen MWN-Rechner
FTP-Server auf einem Nicht-Standard-Port
Port-Scans
DoS
Extrem hoher Datenverkehr
„SSH-Angriff“ auf einen MWN-Rechner
Sonstige Angriffe
Teilsumme
False Positives:
Sonstige False-Positives
Mail-Monitoring
Teilsumme
Summe der vom LRZ selbst endeckten Fälle
Anzahl
der Fälle
Anzahl
der Rechner
499
249
174
128
65
8
6
1.129
502
249
174
128
65
8
6
1.132
427
125
68
38
25
9
9
7
4
712
427
161
68
38
25
9
9
7
9
753
15
4
19
1.860
15
4
19
1.904
Tabelle 19: Kompromittierte Rechner, die vom LRZ selbst entdeckt wurden
Neben den Monitoring-Verfahren am Internet-Übergang verbessert auch noch der sogenannte „NAT-oMAT“ (siehe Kapitel 3.4.1) durch automatisierte Mechanismen die Sicherheit des MWN. Es handelt sich
dabei primär um ein transparentes NAT-Gateway, das bei den Rechnern mit privater IP-Adresse nicht
konfiguriert werden muss. Zusätzlich zur Adressumsetzung sorgt ein „AutoMAT“ für eine Bandbreitenregelung und verhindert weitgehend Angriffe auf andere Rechner durch Port-Scans, DoS und SpamVersendung: Der NAT-o-MAT blockt automatisch kompromittierte Rechner, die den Betrieb beeinträchtigen, und veranlasst den Besitzer eines derartigen Rechners durch geeignete Hinweise, seinen PC zu
säubern.
In schweren Fällen schickt der NAT-o-MAT außerdem noch eine Hinweis-Mail an die zuständigen Netzverantwortlichen. In der Statistik werden nur diese Fälle gezählt.
In den folgenden Fällen sperrt der NAT-o-MAT einen Rechner nach einer Vorwarung dauerhaft; das
Aufheben der Sperre muss danach durch ein Mitglied des Abuse-Response-Teams erfolgen.
• Einer der folgenden Schädlinge wird erkannt: Bredolab, Conficker, Gozi, Torpig, Sality
42
• SSH-Angriff
• FTP-Server auf einem Nicht-Standard-Port
Seit 2006 wirkt sich der NAT-o-MAT nicht mehr nur auf Rechner mit privaten IP-Adressen aus, die
Dienste im Internet in Anspruch nehmen wollen. Durch ein geeignetes Policy-based-Routing werden
auch sämtliche VPN- und Einwahlverbindungen (Modem, ISDN und M-net) zwangsweise durch den
NAT-o-MAT geleitet. Dementsprechend nahmen auch die vom NAT-o-MAT erkannten Missbrauchsfälle drastisch zu.
Bei den selbst entdeckten Fällen (siehe oben, Tabelle 19) sind folgende Punkte besonders erwähnenswert:
• Der Wurm „Conficker“ tauchte im Oktober 2008 auf und treibt seit dieser Zeit auch im MWN
sein Unwesen. Zu Beginn verbreitete sich Conficker ausschließlich über eine kritische Schwachstelle, durch die er selbständig von außen in einen Windows-Rechner eindringen konnte. Microsoft stellte schon Ende Oktober 2008 einen Security-Patch zum Schließen dieser Lücke bereit.
Spätere Versionen von Conficker können sich zusätzlich noch über Netz-Laufwerke und Wechseldatenträger (wie z.B. USB-Sticks) verbreiten.
Auch nach mehreren Monaten nahm im MWN die Zahl der Neuinfektionen nicht ab. Deshalb
wurde 2009 ein spezialisiertes Intrusion-Detection-System (IDS) in Betrieb genommen, mit dem
man infizierte Rechner finden kann. Das IDS wurde später erweitert, um auch noch andere
Schädlinge erkennen zu können.
Trotz dieser Maßnahmen war Conficker im MWN auch 2010 immer noch sehr aktiv.
• Auch 2010 waren die Spammer wieder sehr aktiv und haben viele kompromittierte Rechner im
MWN dazu missbraucht, Spam-Mails zu verschicken (siehe das Mail-Monitoring). Dabei ist es
keine Seltenheit, wenn ein Rechner mehr als 20.000 Spam-Mails pro Stunde verschickt.
• Leider kann man bei den Monitoring-Verfahren, die beim LRZ eingesetzt werden, False-Positives
nicht ganz vermeiden.
Im Falle des Mail-Monitoring handelte es sich z.B. um lange Zeit vollkommen unauffällige
Rechner, die plötzlich ein ungewöhnliches Mail-Aufkommen zeigten. In diesen Fällen gab es
auch keine Hinweise für eine legitime Mail-Quelle: Die Rechner hatten weder einen aussagekräftigen DNS-Namen noch konnte auf dem Mail-Port ein Mail-Server kontaktiert werden.
Zum Glück war in den meisten dieser Fälle das verdächtige Mail-Aufkommen der betroffenen
Rechner nicht besonders hoch; die zuständigen Netzverantwortlichen wurden deshalb überwiegend nur informiert und die Rechner nicht sofort gesperrt. Es handelte sich meist um erst kürzlich in Betrieb genommene Mail-Server oder -Gateways oder um Rechner, von denen nur relativ
selten (oder auch nur einmalig) Rundbriefe, Einladungen usw. an sehr viele Empfänger verschickt wurden.
1.10 IT Bibliotheksverbund Bayern
Seit Mai 2008 ist das Rechenzentrum der Verbundzentrale des Bibliotheksverbundes Bayern (BVB) in
das LRZ integriert. Es handelt sich mittlerweile um insgesamt 211 Betriebssysteminstanzen (Solaris,
Linux, Windows), die teils auf physischen Maschinen, teils auf virtuellen realisiert sind. Ende 2009 wurden 143 Betriebssysteminstanzen gezählt, damit sind also in 2010 68 Betriebssysteminstanzen dazugekommen. Die physischen Maschinen und die Wirtssysteme für die virtuellen Solaris-Systeme werden
dabei vom BVB-IT-Team betrieben, während die virtuellen Linux- und Windows-Systeme auf der
VMWare-Farm des LRZ (siehe Abschnitt 2.7.1.1) laufen. Die Betreuung der Anwendungen geschieht
nicht durch das LRZ, sondern durch die Verbundzentrale des BVB in der Bayerischen Staatsbibliothek.
Zum einen dienen die Systeme als „Lokalsysteme“ der angeschlossenen Bibliotheken (alle Fachhochschulbibliotheken, sechs Universitätsbibliotheken, viele weitere staatliche Bibliotheken) und verwalten
die Datenbanken mit den Katalogen, die Such- und Bestellmöglichkeiten (OPAC) für die Bibliotheksnutzer, die Verwaltung der Ausleihe und zahlreiche weitere Dienste. Zum anderen wird eine Verbunddatenbank von über 1 Terabyte Größe betrieben, die mit den lokalen Datenbanken abgeglichen wird, und die
zur Suche im gesamten Verbund und für die Fernleihe aus anderen Bibliotheken gebraucht wird. Die
eingesetzte Software ist hauptsächlich SISIS als Bibliothekssystem und Sybase als Datenbank auf den
Lokalsystemen sowie Aleph als Bibliothekssystem und Oracle als Datenbank auf den Verbundsystemen.
Als Suchmaschine wird Fast eingesetzt. Viele weitere Softwareprodukte für die zentrale Fernleihe, für
kontextsensitive Verlinkung, für Web-Oberflächen, zur Digitalisierung, zur Langzeitarchivierung und für
andere Aufgaben werden daneben eingesetzt.
43
Die Verbundsysteme und die Lokalsysteme dienen hauptsächlich den Bibliotheken des Bibliotheksverbundes Bayern (BVB) und des Kooperativen Bibliotheksverbundes Berlin-Brandenburg (KOBV), mit
dem eine enge Zusammenarbeit besteht. Nur einzelne Bibliotheken außerhalb dieses Bereiches werden
mitversorgt.
1.10.1 Umsetzung Großgeräte-Antrag
1.10.1.1
Lokalsystemcluster
Die Ablösung der bis zu acht Jahre alten Rechner der lokalen Bibliothekssysteme war dringend notwendig. Drei der mit Mitteln eines Großgeräte-Antrags beschafften Rechner vom Typ Sun M5000 wurden zu
einem hochverfügbaren Cluster zusammengeschlossen. Auf diesem Cluster wurden virtuelle Solaris Betriebssysteminstanzen (Solaris Container) installiert und hochverfügbar gemacht. Dorthin wurden die
einzelnen lokalen Bibliothekssysteme migriert. Momentan werden auf diesem Lokalsystemcluster 66
solcher Solaris Container betrieben.
Die flexible Verteilung der Dienste auf die Container ermöglichte auch eine Umstellung des Betriebskonzeptes für den Hosting Betrieb der lokalen Bibliothekssysteme. So wurde eine Trennung von Datenbank
und Weboberfläche erreicht. Dadurch konnte die Netzsicherheit erhöht werden und erreicht werden, daß
die einzelnen Bibliotheken ihre OPAC-Weboberflächen anpassen und mit eigenen Zertifikaten für den
verschlüsselten Zugang (https) ausstatten konnten. Außerdem wurden Skripte erstellt, die Klone der produktiven lokalen Bibliothekssysteme erzeugen. Dies war vor allem ein Wunsch der Universitätsbibliotheken, die bei umfangreichen Änderungen an den Datenbeständen ein Testsystem benötigen.
1.10.1.2
Verbundsystemcluster
Auf Seiten des Verbundsystems ist schon seit 2004 ein System auf Basis von Solaris Cluster und Oracle
RAC (Real Application Cluster) im Einsatz. Auch hier stand eine Erneuerung der Hardware mit zweien
der Rechner vom Typ Sun M5000 aus Großgeräte-Mitteln an. Zusätzlich mussten Betriebssystem, Clustersoftware, Datenbanksoftware und auch die Anwendungssoftware Aleph500 in neuen Versionen installiert werden. Daher wurde das System von Grund auf neu installiert und der Umstieg auf die neue Hardund Software durch eine Datenmigration realisiert. Durch den Einsatz von Zonenclustern und capped
Containers konnte einerseits ein hochperformanter Datenbankcluster aufgebaut werden und andererseits
konnte eine Lizenzkostenerweiterung für die Datenbanklizenzen vermieden werden.
Das neue System wurde auch gleich in einen Netzbereich mit providerunabhängigen IP-Adressen gelegt
und somit die Ausfallwahrscheinlichkeit weiter vermindert.
1.10.1.3
Suchmaschinencluster Verbundsystem
Die Ende 2009 beschafften Bladesysteme für den Suchmaschinencluster wurden 2010 in Betrieb genommen. Die Performance wurde durch den Einsatz der neuen Hardware weiter verbessert. Durch die erweiterten Resourcen konnten auch weitere Suchindizes für andere Suchkriterien auf die Verbunddatenbank
erzeugt werden.
1.10.1.4
Neuaufbau Citrix Farm
Die Citrix Farm für die Nutzung der bibliothekarischen Spezialsoftware (Alephclient, Sisisclient, WinIBW) wurde komplett neu auf Basis von XenApp 5 64bit auf vier virtuellen Maschinen der zentralen
VMWare Farm aufgebaut. Für die meisten Nutzer ging ein Wechsel der Anwendungssoftware auf eine
neue Version einher mit dem Wechsel auf die neue Citrix Farm. Der Umstieg verlief daher ohne Einschränkungen. Die alte Hardware (neun Server in einem Blade-Chassis) konnten abgeschaltet werden.
1.10.1.5
Migration und Update CDROM-Server Farm
Auch die Hardware der CDROM-Server war veraltet. Hier wurden virtuelle Maschinen in die Umgebung
(Citrix mit Erweiterungssoftware von H+H) einkonfiguriert und die CDROM Datenbanken sukzessive
von H+H auf die neuen Rechner umgezogen. Die alte Hardware konnte abgeschaltet werden.
Außerdem wurden zwei virtuelle VMWare Maschinen zur Installation künftiger CDROM Datenbanken
erstellt. Durch die Nutzung von Snaphots unter VMWare konnte erreicht werden, daß die Installation von
weiteren CDROM Datenbanken deutlich vereinfacht wurde.
44
1.10.2 Rosetta
Ende 2009 hat sich die Bayerische Staatsbibliothek für das Produkt "Rosetta-Digital Preservation System" der Firma ExLibris zur Verwaltung der digitalen Langzeitarchive entschieden. Das LRZ ist hier in
vieler Hinsicht strategischer Partner: Es stellt nicht nur die Server- und Archivtechnik, sondern wird voraussichtlich auch durch den Betrieb der Technik des Bibliothksverbundes Bayern künftig mit dem Betrieb von weiteren Instanzen der Software für die anderen Mitgliedsbibliotheken betraut werden.
Für die Projektphase wurde eine Schulungsumgebung unter VMWare bereitgestellt. Außerdem wurden
VMWare Maschinen für die „Worker-Server“ der Test- und Produktivumgebung installiert. Für die künftige Produktivumgebung wurde auch ein Oracle Datenbankcluster auf zwei physischen Rechnern installiert.
45
2 Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)
2.1
Entwicklung in der Datenhaltung
2.1.1 Überblick
Die Architektur der Speichersysteme gliedert sich im Wesentlichen in zwei Bereiche,
• den Bereich der Massenspeicher der Archiv- und Backupsysteme mit ihren Bandbibliotheken
(Abschnitt 2.1.2), auf die sich unter anderem die Langzeitarchivierung (Abschnitt 2.1.3) abstützt,
• und in den Bereich der Onlinespeicher (Abschnitt 2.1.4), bei denen wiederum zwischen NAS
(Network Attached Storage)- und SAN (Storage Area Network)-basiertem Datenspeicher unterschieden wird.
Für Sicherungssysteme zweiter Ordnung sowie für die Archivierung von großen Datenmengen sind Bänder als Datenträger unverzichtbar. Der Umfang der in den Bandbibliotheken des LRZ gespeicherten Daten wuchs im Jahr 2010 von 9.000 Terabyte auf 14.700 Terabyte an. Um den Zuwachs zu bewältigen
wurden in erheblichem Umfang neue Kassetten beschafft und ein weiteres Archiv- und Backupsystem
bestehend aus einer Bandbibliothek, Plattenspeichern, Servern und Netzinfrastruktur wurde im Datenund Archivraum installiert. Durch das neue System wurde ein technisch veraltetes System aus dem Jahre
2003 abgelöst.
Eine zusätzliche große Herausforderung in diesem Umfeld war der Übergang auf ein neues SoftwareRelease und der dadurch bedingte grundlegende Wechsel der Datenbank-Architektur. Die Migration von
8 Milliarden Datenbankeinträgen zog sich über mehrere Monate und konnte im Herbst erfolgreich abgeschlossen werden.
Die Zusammenarbeit mit der Bayerischen Staatsbibliothek wurde weiter ausgebaut. Dabei fungiert das
LRZ als IT Service Provider in den Bereichen Serverhosting, Clusterhousing, Storagehousing einerseits
und als Projekt- und Kooperationspartner in verschiedenen Projekten (BABS2, BSB-Google, Rosetta)
andererseits.
Nicht zuletzt bedingt durch die Vorarbeiten zu „Rosetta“, einem Projekt mit sehr ambitioniertem Zeitplan,
für das in erheblichem Maß Speicherplatz benötigt wird, wurde sehr kurzfristig die Ersetzung des alten
Speichersystems der BSB notwendig und auch erfolgreich umgesetzt. Die Bayerische Staatsbibliothek
verfügt nun über 500 Terabyte Onlinespeicher am LRZ, der von verschiedenen Arbeitsgruppen und Projekten genutzt wird. Dieser Speicher ist auch Ausgangspunkt für die Übertragung der Daten ins Langzeitarchiv des LRZ.
Am LRZ selbst und an den Kommissionen der Bayerischen Akademie der Wissenschaften wird gemeinsam nutzbarer, hoch verfügbarer und optimal gesicherter Speicher auf Basis der NAS-Technologie eingesetzt. Dieser Dienst steht als Grundversorgungsangebot auch Mitarbeitern und Studierenden der TU München und der LMU zur Verfügung und ersetzt dort immer häufiger lokale Lösungen.
Die 2008 installierten NAS-Systeme wurden 2010 deutlich erweitert. Hinzu kamen weitere hochverfügbare Speichersysteme, die primär innerhalb der virtuellen Serverumgebung des LRZ genutzt werden.
Insgesamt ist der zur Verfügung stehende Onlinespeicherplatz auf 2.000 Terabyte brutto angewachsen.
Zusammen mit dem SAN-Speicherplatz beträgt die Bruttokapazität der Plattenspeicher 3.500 Terabyte
verteilt auf etwas weniger als 5.000 Festplatten.
2.1.2 Archiv- und Backupsystem
2.1.2.1
Konfiguration
Das Archiv- und Backupsystem des LRZ besteht aus zwei großen Systemen mit Bandrobotern: einem
Hochleistungssystem HABS, das Anfang 2006 installiert und Ende 2007 und 2010 erweitert wurde, und
einem System mit LTO-Bandlaufwerken in mehreren Bibliotheken (LABS), das 2010 neu installiert wur-
Entwicklungen und Tätigkeiten im Bereich der Hochleistungssysteme (HLS)
46
de. Aus Gründen der Ausfallsicherheit befinden sich die Komponenten der beiden Systeme in getrennten
Speichernetzen. Softwareseitig wird die gesamte Architektur mit dem Tivoli Storage Manager von IBM
betrieben.
Archive and Backup System, Dec 2010
IBM
SUN
Brocade
10 GBit Ethernet
8 TSM Servers
TSM
TSM
8 TSM Servers
3 machines
TSM
IBM X3850x5
TSM
SAN
Disk Cache
SUN FLX380
280 TB
Brocade
Silkworm
4800
Brocade
Silkworm
4800
3 TSM Servers
TSM
SAN
3 TSM Servers
TSM
12 machines
HABS –
High Performance Archive and Backup System
TSM
SUNFire 4270
Brocade 5400
Brocade 5400
Disk Cache
SUN 6780
520 TB
Brocade 5400
Brocade 5400
Library SUN SL8500
26 tape devices SUN T10K-B
10,000 slots
3 TSM Servers
Library SUN SL8500
16 tape devices IBM LTO5
6,500 slots
Library IBM TS3500 L52
6,500 slots
LABS –
LTO Archive and Backup System
Abbildung 9: Überblick Archiv- und Backupsysteme
Die theoretische Gesamtkapazität der Systeme liegt bei 27 PB, die Peak-I/O-Leistung liegt bei 22 TB pro
Stunde. Die wesentlichen Komponenten des Systems sind:
• 16 Rechner (Vorwiegend Intel Nehalem EP und EX)
• 4 Fibre Channel Switches (8 Gbit) und 2 Fibre Channel Direktoren (4 u. 8 Gbit)
• 14 Storage Server mit insgesamt 800 TB verteilt auf 2176 Disks
• 3 Tape Libraries mit insgesamt 21.500 Slots
• 76 Tape Laufwerke (LTO-4, LTO-5, T10K)
Abbildung 10 und Abbildung 11 zeigen die beiden Teil-Konfigurationen des LABS bzw. HABS im
Detail. Der Name Hochleistungsarchiv HABS ist insofern irreführend, als durch die jüngsten
Aufrüstungen am LABS dieses System einen höhere Leistung und Kapazität vorweisen kann als das
HABS.
2.1.2.2
Veränderungen im Bereich Speichersysteme
2.1.2.2.1
Stilllegung eines veralteten Systems
Die LTO-Technologie (LTO steht für linear tape open) hat sich in den vergangenen zehn Jahren nicht
zuletzt wegen des offenen Standards zum Marktführer im Midrange-Bereich entwickelt. Am LRZ wird
die Technologie beginnend mit LTO2 seit 2003 eingesetzt. Die Modellreihe ist zwischenzeitlich bei
LTO5 angelangt. LTO2 entspricht weder leistungsmäßig noch kapazitiv länger dem Stand der Technik.
Im Laufe des Jahres 2010 wurden sämtliche Daten von 11.000 LTO2-Bändern auf LTO4-Bänder kopiert.
40 LTO2-Bandlaufwerke wurden außer Betrieb genommen. Die älteste Bandbibliothek, die schon in der
Innenstadt betrieben wurde und den Umzug nach Garching im Jahr 2006 mitmachte, wurde stillgelegt.
47
LTO Archive and Backup System 2010
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
devices:
6.297 TB, 5.500 LTO-4 cartridges + 3795 LTO-5 cartridges
17.250 TB, 11.500 LTO-5 cartridges
26 x LTO4 + 24 LTO5 drives
192 TB FC-AL, 262 TB SATA, 65 TB SAS
Router MWN
10 Gbit
HP E6600-24XG Switch
24 x 10 GbE Ports
24 x 10 GbE Ports
Munich Scientific
Network
24 x 10 Gbit Ethernet
9 x Sun Fire X4270
3 x Sun Fire X4270
Pentium 4
Pentium 4
Pentium 4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Pentium
4
Sn
Sn
Sun
Fire X4270Sn
S1
Sn
Sn
Worker
7 Server
2 XEON x 4 Core
2 x INTEL X5560 2.8 GHz
72 GB Memory
4 x FC 8 Gbit
2 x 10 GbE (Failover)
Pentium 4
Pentium 4
Sun
Fire X4270Sn
S1
Sn
Sn
Mgmt.
7 Server
1 XEON x 4 Core
SLES 11
TSM Server 6.2
2 x INTEL X5560 2.8 GHz
16 GB Memory
4 x FC 8 Gbit
2 x 10 GbE (Failover)
SLES 11
TSM Server 6.2
48 x 8 Gbit FC
Storage Area Network
8 GBit FC-Switch 80 Port
26 x 4 Gbit FC
24 x 8 Gbit FC
56 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
6.500 slots total
capacity: 9.750 TB
SUN SL8500 tape library
16 x LTO-4 + 16 x LTO-5
Max library capacity:
Cur. library capacity:
17.250 TB uncompressed
SUN 6780
FC-AL 65 TB
SATA 87 TB
SUN 6780
FC-AL 65 TB
SATA 87 TB
SUN 6780
FC-AL 61 TB
SATA 87 TB
IBM DS3500
SAS 65 TB
1028 disks, total capacity: 519 TB
Abbildung 10: LTO-Archiv-und Backupsystem LABS Ende 2010
48
High Performance Archive and Backup System 2010
Cur.
Max.
Tape
Disk
tape capacity:
tape capacity:
devices:
capacity:
9.300 TB, 9.300 T10K cartridges
10.000 TB, 10.000 T10K cartridges
26 x T10K-B
280 TB FC-AL
Munich Scientific
Network
National
Supercomputer
HLRBII
Linux Compute
Cluster
Router MWN
10 Gbit
10GE-Switch Cisco 6509
20 x 10 GbE Ports
24 x 10 GbE Ports
2 x 10 Gbit Ethernet HPC
special
3 x IBM X3850 X5
Pentium 4
Pentium
S1 4
OPTERON
Worker ServerSn
S127x 2 core
Sn
XEON
X7550
7
4 x 8 Core
9 x 10 Gbit Ethernet
1 x 10 Gbit Ethernet HPC special
1 x Sun Fire X4200 M2
4 x Intel Xeon X7550 2.0 GHz
128 GB Memory
8 x FC 8 Gbit
4 x 10 GbE (3 x trunk, 1 x HPC special)
2 x OPTERON
DualCore 2.6 GHz
16 GB Memory
4 x FC 4 Gbit
1 x 10 GbE
Mgmt. Server
OPTERON
2 x 2 core
SLES 11
TSM Server 6.2
SLES 11
TSM Server 6.2
4 x 4 Gbit FC
24 x 8 Gbit FC
13 x NAS
Filer
13 x 2 Gbit FC
FC-Direktor
96 Port 4Gb + 16 Port 8Gb
FC-Direktor
96 Port 4Gb + 16 Port 8Gb
26 x 4 Gbit FC
80 x 4 Gbit FC
SUN 6540
FC-AL 30 TB
STK 6540
FC-AL TB
STK FLX380
FC-AL 25 TB
STK FLX380
FC-AL 25 TB
SGI IS4500
FC-AL 28 TB
SGI IS4500
FC-AL 28 TB
SGI IS4500
FC-AL 28 TB
SGI IS4500
FC-AL 28 TB
SGI IS4500
FC-AL 28 TB
SGI IS4500
FC-AL 28 TB
STK SL8500 tape library
26 FC tape drives Titanium B
Max library capacity:
Cur. library capacity:
1148 disks total capacity: 280 TB
Abbildung 11: Hochleistungsarchiv- und Backupsystem HABS Ende 2010
49
2.1.2.2.2
Beschaffung eines neuen Systems und Modernisierung
Bereits 2009 wurde als Ersatz für das 2010 außer Betrieb genommene Archiv ein neues System im Rahmen einer Ausschreibung erworben. Dieses System wurde 2010 in zwei Phasen installiert und in den
Produktionsbetrieb übergeführt. In der ersten Phase im Frühjahr wurden eine weitere Bandbibliothek mit
6.500 Stellplätzen, sowie Plattenspeicher und eine Serverfarm im Daten- und Archivraum aufgestellt. Die
Bibliothek wurde mit 16 LTO4-Laufwerken ausgerüstet. Zum Ausschreibungszeitpunkt war LTO5 noch
nicht verfügbar. In der zweiten Phase wurde die Bibliothek dann im vierten Quartal um 16 LTO5Bandlaufwerke erweitert. LTO5-Laufwerke sind deutlich schneller als LTO4-Laufwerke und fassen die
doppelte Datenmenge (800 GB).
Die Rechner und auch andere Komponenten des Hochleistungsarchiv- und Backupsystems HABS aus
dem Jahr 2006 wurden 2010 gegen neuere, leistungsstärkere Maschinen ausgetauscht. Dazu mussten die
TSM-Serverinstanzen, die auf den Servern liefen, hardware- und betriebsystemseitig auf die neuen Systeme migriert werden.
Ende 2010 wurde dann noch eine der Bandbibliotheken von IBM um 8 LTO5-Laufwerke aufgerüstet. In
dieser Bibliothek wurden bis 2009 20 LTO2-Laufwerke betrieben. Diese wurden sukzessive durch LTO4Laufwerke ersetzt, sodass nun in der Bibliothek ein Mischbetrieb zwischen LTO4 und LTO5 gefahren
wird. Grundsätzlich haben die robotergestützten Bandbibliotheken eine deutlich längere Standzeit als die
Bandlaufwerke selbst, bei denen sich die Technologie rasant weiterentwickelt.
2.1.2.2.3
Releasewechsel auf TSM Version 6
Die Software, mit der die Archiv- und Backupsysteme betrieben werden, wird mindestens einmal im Jahr
auf allen Systemen aktualisiert. In der Regel sind für diese Releasewechsel nur kleinere Anpassungsarbeiten und kurze Betriebsunterbrechungen notwendig. Der Upgrade von TSM 5 auf TSM 6 war anders.
Kernstück einer jeden TSM-Serverinstanz ist die interne Datenbank, in der verzeichnet ist, welche Datei
auf welchem Band in welcher Version zu welchem Zeitpunkt gespeichert wurde. In den TSMDatenbanken liegen Informationen dieser Art zu 8 Milliarden Dateien. Mit TSM 6 wurde die proprietäre
interne Datenbank durch die Datenbank DB2 ersetzt. Der Wechsel machte umfangreiche Anpassungsarbeiten sowie eine Konvertierung der Datenbanken, die jeweils mehrere Tage dauerte, auf das neue Format
notwendig und zog sich über einige Monate.
2.1.2.2.4
Synchronisierung Kunden-DB mit zentralem Verzeichnisdienst
Die in den Archiven gespeicherten Daten werden bestimmten Personen und Personengruppen bzw. Einrichtungen zugeordnet. Die Pflege der Kontaktdaten der über 1100 Ansprechpartner auf Kundenseite ist
eine ebenso wichtige wie zeitraubende Aufgabe beim Betrieb des Archiv- und Backupsystems. Die Fluktuation im Hochschulbereich ist sehr hoch, Ansprechpartner wechseln häufig. Bisher wurden die personenbezogenen Daten in einem eigenen, unabhängigen Datenbanksystem mit Webschnittstelle (DATWeb)
verwaltet. Im Frühjahr 2010 wurden die Kontaktdaten mit dem zentralen Verzeichnisdienst des LRZ synchronisiert. Personenbezogenen Daten werden seitdem nur noch zentral gehalten. Dies erleichtert die
Verwaltung der Kundendaten erheblich. Trotzdem erfordert die Pflege der Kontaktdaten auch weiterhin
viel Aufmerksamkeit. Nur durch ständigen Kontakt mit den Kunden kann erreicht werden, dass sich die
Archive nicht zu einem „Datenfriedhof“ entwickeln.
2.1.2.3
Statistik
Ende 2010 waren in den drei Libraries 14.700 Terabyte, verteilt auf 8 Milliarden Dateien gespeichert. Täglich wurden auf die Systeme durchschnittlich 40 Terabyte neu geschrieben, zu Spitzenzeiten
mit einer Geschwindigkeit von 6 GB/Sek. Die Daten stammten von 6.800 Servern des MWN aus 430
Einrichtungen der Münchner Hochschulen.
Im Vergleich zum Vorjahr sind Last und Datenmenge erwartungsgemäß weiter gestiegen. Der Bestand an
genutzten Kassetten in den drei Libraries lag Ende 2010 trotz Zukauf von weiteren 5.000 Stück mit
14.000 um 5.000 Stück niedriger als im Vorjahr (2009: 19.000). Die Differenz erklärt sich durch die Au-
50
ßerbetriebnahme von 11.000 LTO2-Kassetten. 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. 2010 wurden 1.260 Nodes
neu registriert und 550 alte Nodes inklusive ihrer gespeicherten Daten gelöscht. Durch das explizite Löschen von Nodes sowie durch automatische Löschprozesse nicht mehr benötigter Daten wird dafür 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 kostenlosen – Ressourcen anzuhalten.
Ein eigens für diesen Zweck bereitgestellter Server erlaubt es den Kunden, sich direkt umfassend über
den eigenen Datenbestand zu informieren. Gleichzeitig werden die Nutzer in regelmäßigen Abständen
von diesem Server über die von ihnen verbrauchten Speicherressourcen via E-Mail informiert. Integriert
sind Werkzeuge, die der betrieblichen Überwachung und Analyse der Systeme dienen. Nutzer mit besonders auffälligem Datenprofil werden direkt angesprochen.
Alle Kontaktdaten werden zusätzlich regelmäßig auf ihre Aktualität überprüft. Entsprechend den Benutzungsrichtlinien werden Daten, zu denen sich keine Ansprechpartner mehr ermitteln lassen, nach Ablauf
einer festgelegten Frist gelöscht.
Zur Erhöhung der Datensicherheit spiegelt das LRZ seine Archivdaten an das Rechenzentrum der MaxPlanck-Gesellschaft in Garching (3,3 Petabyte) und umgekehrt (5,8 Petabyte).
Den Zuwachs von Speicherbelegung und Dateneingang im Laufe des Jahres 2010 zeigen Abbildung 12
und Abbildung 13.
1.400.000
Backup
Archiv
1.200.000
1.000.000
800.000
600.000
400.000
200.000
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 12: Datenverkehr (Gigabytes/Monat)
Der Archiv-Anteil am Datenbestand ist relativ statisch, d.h. es gibt nur wenige Änderungen an den Dateien im Archiv. Archivdaten werden in der Regel einmal ins Archiv übertragen und dort sehr lange aufbewahrt, im Fall der Langzeitarchivierung für Jahrzehnte. Datensicherungen finden regelmäßig statt. Backupdaten werden dagegen häufig ins System geschrieben und die veralteten Daten werden automatisch aus
dem Bestand gelöscht. Durch diese Dynamik erklärt sich die im Vergleich zur Archivierung deutlich höhere Dateneingangsrate.
51
14000
12000
10000
8000
6000
Backup
Archiv
4000
2000
0
Jan
Feb
Mrz
Apr
Mai
Jun
Jul
Aug
Sep
Okt
Nov
Dez
Abbildung 13: Datenumfang in Terabytes
14.090.000
9.475.000
2.810.000
1.700.000
950.000
340.000
220.000
120.000
62.000
31.000
12.000
100.000
1.000
1.000
10.000
500
Speicherbelegung in TB
1.000.000
84.000
10.000.000
650.000
100.000.000
5.300.000
Die Entwicklung der letzten 15 Jahre zeigt Abbildung 14. Das Diagramm zeigt ein kontinuierliches exponentielles Wachstum des Datenbestands über die Jahre hinweg.
100
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010
Abbildung 14: Speicherbelegung 1995-2010
52
2.1.3 Langzeitarchivierung
2.1.3.1
Das LRZ als Service-Provider für digitale Langzeitarchivierung
Veröffentlichungen in digitaler Form nehmen im Wissenschaftsbetrieb wie auch im gesellschaftlichen
Leben einen immer höheren Stellenwert ein. Oft wird, wie z. B. bei Dissertationen und bei amtlichen
Publikationen, auf ein gedrucktes Pendant ganz verzichtet. Während die Digitalisierung für die Nutzer
den Zugang und den Umgang mit der Information beschleunigt und insgesamt erleichtert, entstehen aus
organisatorischer, rechtlicher und technischer Sicht neue Herausforderungen. Die Objekte sollen nicht nur
verwaltet und gespeichert, sondern auch langfristig zugänglich gemacht werden. Diese Aufgabe wird
erschwert durch den raschen technologischen Wandel im Bereich der Hard- und Software und der 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),
der BSB-Google Partnerschaft und der Einführung des LZA-Managementsystems Rosetta der Firma Exlibris an der BSB ausgeweitet wurde. Dabei tritt das LRZ für die BSB als Dienstleister für die Langzeitarchivierung, das Bereitstellen von Onlinespeicher, das Attended Housing von Clusterknoten und Hosting
von virtuellen Servern auf. Die langfristige Speicherung der Daten übernimmt bei allen Projekten ein
NAS-System und das Archiv- und Backupsystem des LRZ mit dem Softwarepaket Tivoli Storage 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).
Weitere Details über die hier aufgeführten Langzeitarchivierungsprojekte können über die LRZHomepage im Bereich Projekte (http://www.lrz.de/projekte/langzeitarchivierung) gefunden werden.
Abbildung 15 und Abbildung 16 zeigen die Entwicklung der Anzahl der Archivobjekte und des Datenvolumens des Langzeitarchivs von Januar 2005 bis Januar 2011. Der starke Anstieg der Dateianzahl ab
März 2009 ist durch den Produktivbeginn der Archivierung der Google-Digitalisate zu erklären. Bisher
wurden von der BSB mehr als 560 Millionen Objekte mit einem Datenvolumen von mehr als 290 TByte
am LRZ archiviert. Der Datenzuwachs im Jahr 2010 betrug ca. 260 Mio. Dateien mit einem Volumen von
90 TByte. In Abbildung 16 ist dieser Anstieg weniger auffällig, da die Größe der einzelnen GoogleDigitalisate im Vergleich zu den übrigen Digitalisaten eher gering ist. Die aus Sicherheitsgründen erstellte Zweitkopie auf einem weiteren Magnetband verdoppelt in der Praxis die Objektanzahl und das Datenvolumen. Sie ist in den Diagrammen nicht berücksichtigt.
Abbildung 15: Objektanzahl im LRZ-Archiv
53
Abbildung 16: Datenvolumen im LRZ-Archiv
Die gespeicherten Daten werden auf Systemen aufbereitet, archiviert und als Webpräsenz bereitgestellt,
die zum großen Teil auf der virtuellen Serverplattform des LRZ betrieben werden. Zu diesen Systemen
gehören unter anderem die Verkündungsplattform Bayern, der Webserver der Bayerischen Landesbibliothek oder ein Server, der die Volltextindizierung der Digitalisate steuert, um nur einige Beispiele zu nennen.
Die Anzahl dieser am LRZ für die Staatsbibliothek gehosteten virtuellen Linux-Server ist im Jahr 2010
von 13 auf 27 angewachsen.
2.1.3.2
Projekt BABS2
Start für das DFG-geförderte Projekt BABS2 war Oktober 2008. Das Projekt wurde am 20.01.2011 mit
einem sehr gut besuchtem Workshop mit dem Thema „Langzeitarchivierung von Retrodigitalisaten:
Handlungsfelder und Praxis“ erfolgreich abgeschlossen. Das rege Interesse von über 80 Teilnehmern am
Workshop zeigt die Relevanz der im BABS2 behandelten Thematiken für die Praxis. Ein Ziel von
BABS2 war der prototypische Ausbau und die Evaluierung eines vertrauenswürdigen und skalierbaren
digitalen Langzeitarchives.
Die Entwicklungen der letzten Jahre haben gezeigt, dass die Zuwächse an digitalen Daten, die der Langzeitarchivierung zugeführt werden, schwer abschätzbar sind. Dies zeigt sich sehr deutlich im Bereich der
digitalen Sammlungen der BSB, wo exorbitante Steigerungen zu verzeichnen sind, und alle Prognosen
früherer Jahre immer wieder nach oben korrigiert werden mussten. Als Hauptdatenlieferant sind die
Google-Digitalisate anzusehen. Auch entsteht durch die anlaufende Pflichtablieferung elektronischer
Publikationen eine nur schwer abschätzbare Menge weiterer Daten. In 2010 wuchs das Datenvolumen
von 194 TB auf 290 TB und die Archivobjektanzahl von 305 Mio. auf 560 Mio. Dateien. Für die wichtige
Frage nach der Skalierbarkeit bezüglich Datenvolumen und insbesondere bezüglich der Anzahl der archivierten Dateien eines digitalen Langzeitarchivs wurden im Projekt BABS2 Lösungsansätze gesucht.
Die Ergebnisse aus den umfangreichen Skalierungstests flossen in das umgesetzte Konzept für ein skalierbares Langzeitarchivierungssystem für die Massendigitalisierung ein und führten zur Realisierung
einer erweiterbaren Speicherschicht bestehend aus einem Onlinespeicher (Festplatten) und einem Archivund Backupsystem mit Magnetbändern als Speichermedien. Als Onlinespeicher wird ein NAS-System
(Network Attached Storage) verwendet, das durch zwei getrennte Speicher-Controller (Filer-Köpfe) redundant aufgebaut ist, und den Ausfall einzelner Komponenten ohne Betriebsunterbrechung abfangen
kann. Da sehr große Speicherbereiche im Petabyte-Bereich nicht zu realisieren sind, werden diese großen
Bereiche aus vielen kleinen Speicherbereichen (so genannten Volumes) mit einer Größe von vier bis
sechs Terabyte zusammengesetzt. Ähnliches gilt auch bei der Datensicherung. Die Sicherung (Backup
oder Archivierung) sehr großer Speicherbereiche ist nicht zu empfehlen, da gerade hier an das Wiedereinspielen der Sicherung in einem Desaster Fall gedacht werden muss, was viel zu lange dauern würde. Deshalb wurde auch innerhalb des Backup- und Archivsystems durch so genannte TSM-Nodes eine zu den
54
Volumes analoge Organisation umgesetzt. Abbildung 17 zeigt eine Detailansicht der skalierbaren Speicher- und Archivumgebung.
Abbildung 17: Aufbau einer skalierbaren Archivierungskomponente
2.1.3.3
Projekt Rosetta
Im Frühjahr 2010 hat sich die BSB für die Einführung des Langzeitarchivsystems Rosetta der Firma Exlibris als neue strategische Plattform für die Langzeitarchivierung in Bayern entschieden. Diese Entscheidung wurde auch dadurch beeinflusst, dass das bislang verwendete Systeme Digitool der Firma Exlibris
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.
Mittelfristig ist geplant, den bisher archivierten Datenbestand (290 TB; 560 Mio. Dateien) nach Rosetta
zu migrieren. Gegenüber der bisherigen Konfiguration werden neben den Bereitstellungsdaten auch die
digitalen Masterdateien auf einem Online-Speichersystem vorgehalten. Diese ambitionierten Pläne haben
dazu beigetragen, dass der bestehende Online-Speicher (NAS-System) der BSB im Oktober 2010 durch
ein performanteres und skalierbareres NAS-System ersetzt wurde. Die Bruttokapazität des NAS-Filers
wurde ganz erheblich von 137 TB auf 586 TB erweitert. Das LRZ betreibt für die BSB die Komponenten
des Langzeitarchivsystem Rosetta (virtuelle Server, Onlinespeicher und Archivspeicher).
2.1.3.4
Projekt BSB-Google
Im Rahmen einer im Jahr 2007 entstandenen Public-Private-Partnership digitalisiert Google über einen
Zeitraum von mehreren Jahren mehr als 1 Million urheberrechtsfreie Druckwerke aus dem Bestand der
BSB. Die BSB erhält Kopien der Digitalisate, die am LRZ gespeichert, archiviert und über den OPAC der
BSB weltweit zugänglich gemacht werden. Das LRZ unterstützt die BSB in diesem Projekt als Dienstleister und ist für die Langzeitarchivierung der Digitalisate, das Housing von Clusterknoten für die Formatmigration als Vorbereitung für die Web-Bereitstellung, das Hosting des Speichersystems und das Hosting
virtueller Server für Archivierung und Web-Bereitstellung zuständig.
Konkret stellt das LRZ zunächst drei virtuelle Server bereit, die sich um den Download, die Verarbeitung,
Archivierung und Bereitstellung der Daten im Internet kümmern. Die Originaldateien, die die BSB von
Google erhält, werden im Archiv- und Backupsystem des LRZ abgelegt.
55
Abbildung 18: Rosetta-Speicherarchitektur
Die Dateien, die im Internet angeboten werden, werden am LRZ auf einem NAS-System gehostet. Die
Umwandlung aller originalen Bilddateien in jeweils zwei Bilddateien mit niedriger Auflösung geschieht
am LRZ auf dem Linuxcluster. Schematisch dargestellt ist die Infrastruktur sowie der Workflow in Abbildung 19:
Abbildung 19: Workflow im Google Projekt
56
Ende 2008 wurden von Google die ersten Digitalisate bereitgestellt. Bis Ende 2010 wurden rund 210.000
Bücher heruntergeladen und verarbeitet, der Bestand an Archivdaten im Google-Projekt ist so bis Ende
2010 auf fast 90 TB angewachsen:
100
90
80
70
60
50
40
30
20
10
Dezember
November
Oktober
September
August
Juli
Juni
Mai
April
März
Februar
Januar '10
Dezember
November
Oktober
September
August
Juli
Juni
Mai
April
März
Februar
Januar '09
0
Abbildung 20: Archivierte Daten in Terabyte
Im Oktober 2010 wurden auch die Google-Volumes unterbrechungsfrei auf das neue NAS-System der
BSB umgezogen.
2.1.3.5
Münchner Arbeitskreis Langzeitarchivierung
Der Münchener Arbeitskreis Langzeitarchivierung ist auf Initiative der Bayerischen Staatsbibliothek und
der Generaldirektion der Staatlichen Archive Bayerns entstanden und vereint Institutionen aus dem Raum
München, die sich aktiv mit der Langzeitarchivierung elektronischer Medien befassen. Der Arbeitskreis
bietet die Möglichkeit eines Informations- und Erfahrungsaustausches auf lokaler Ebene und fördert den
Transfer von Wissen über Methoden und Techniken. Bei den etwa halbjährlich stattfindenden Treffen an
wechselnden Orten werden jeweils andere Themenschwerpunkte gesetzt. Ein ausgewähltes Thema war
„Langzeitarchivierung von Objekten aus Massendigitalisierungsprojekten an der BSB“.
Eine detailliertere Beschreibung der einzelnen Projektinhalte im Bereich der Langzeitarchivierung ist auf
der LRZ-Homepage (http://www.lrz.de/projekte/langzeitarchivierung) zu finden.
Auch wenn im Kontext der Kooperation mit der Bayerischen Staatsbibliothek der größte Teil der Aktivitäten bezüglich der digitalen Langzeitarchivierung stattfindet, sollte die Zusammenarbeit mit anderen
Einrichtungen wie dem Bayerischen Bibliotheksverbund (siehe Abschnitt 1.10) und der Bibliothek der
Technischen Universität München, die die Speicher des LRZ für den bibliothekseigenen Medienserver
nutzen, nicht unerwähnt bleiben.
2.1.4 Online-Speicher
2.1.4.1
Network Attached Storage
2.1.4.1.1
Homogene NAS-Umgebung
Die NAS-Systeme am LRZ haben sich als Speicherplattform aufgrund ihrer Stabilität, Ausfallsicherheit
und hohen Datensicherheit durch die Spiegelung auf ein Replikationssystem seit mehreren Jahren bewährt und als strategische Plattform etabliert. Die rapide wachsenden Datenmengen erfordern auch eine
57
gute Skalierbarkeit der eingesetzten Systeme. Abbildung 21 zeigt exemplarisch die Speicherentwicklung
wichtiger Systeme im Jahr 2010.
Abbildung 21: Links: NAS-Speicherentwicklung von Juni 2010 bis Januar 2011.
Rechts: Speichereinsparung durch Datendeduplizierung
Datendeduplizierung wird für den VMWare-Datenspeicherbereich produktiv eingesetzt. Bei der Datendeduplizierung wird der Datenbestand nach gleichen Blöcken durchsucht. Sind Doubletten vorhanden, wird
ein solcher Block nur einmal gespeichert und die doppelten Datenblöcke freigegeben. Die Deduplizierung
bringt in diesem Bereich eine Einsparung von über 40% (grüne Kurve).
Abbildung 22 zeigt die Konfiguration der Speicherinfrastruktur der Primärspeichersysteme (Produktivsysteme) inklusive der Replikations- und Backupsysteme. Zwischen Primär- und Replikationsspeichersystemen findet mit SnapMirror eine asynchrone Spiegelung der Daten statt, im VMWare-Umfeld, wie
unten beschrieben, eine synchrone Spiegelung. Zur weiteren Erhöhung der Datensicherheit werden die
Daten von den Replikationssystemen zusätzlich über NDMP (Network Data Management Protocol) auf
Magnetbänder gesichert. Die Primär- und Replikationssysteme befinden sich aus Sicherheitsgründen darüber hinaus in getrennten Brandabschnitten des Rechnergebäudes.
Abbildung 22: Primärsysteme, Replikation und Backup
2.1.4.1.2
Hochverfügbarer Speicher für virtuelle Server
Im Frühjahr 2010 wurden Speichersysteme für die neue VMWare-Infrastruktur und für ein Hochleistungs-NAS-System für den HPC-Bereich in Betrieb genommen. Voran ging eine Ausschreibung im Vorjahr.
58
Um die notwendige hohe Verfügbarkeit bei der Speicherversorgung der neuen VMWare-Infrastruktur zu
erreichen, wurde ein System beschafft, das seine Daten synchron spiegelt und zusätzlich repliziert. Als
nutzbarer Speicherplatz stehen VMWare seit Frühjahr 2010 ca. 55 TByte zur Verfügung. Für die Replikation der Daten wurde das vorhandene Replikationssystem, das 2007 beschafft wurde, entsprechend erweitert. Abbildung 23 zeigt das beschaffte System, das in räumlich getrennten Brandabschnitten aufgebaut
und installiert wurde.
Abbildung 23: Hochverfügbares NAS-System für VMWare inkl. Replikation und Backup
2.1.4.1.3
Hochleistungs-NAS-System für HPC-Anwendungen
Der Linux-Computecluster des LRZ mit derzeit mehr als 500 Knoten bietet eine Grundversorgung mit
HPC-Diensten für Wissenschaftler sowohl für die Münchner Universitäten als auch für andere bayerische
Hochschulen. Zusätzlich zu den LRZ-eigenen Rechnern integriert der Linux-Computecluster weiterhin
externe Projekte wie D-Grid, das LHC-Tier-2-Zentrum oder die Archivprojekte der Bayerischen Staatsbibliothek, deren Rechner in die Gesamtinfrastruktur eingebunden sind. Da in der Vergangenheit das für
den Linux-Computecluster verwendete parallele Dateisystem Lustre häufiger zu Ausfällen geführt hat,
wurde entschieden, dieses System zu ersetzen. In der erwähnten Ausschreibung von 2009 wurde ein skalierbares und für hohen Durchsatz optimiertes NAS-Speichersystem für die Speicherung von großen Datensätzen beschafft und im Frühjahr 2010 in Betrieb genommen. Das Speichersystem hat sich hervorragend in die am LRZ bereits vorhandene NAS-Speicherinfrastruktur integrieren lassen und besteht aus
sechs FAS3170 (2 Nodes je Chassis) der Firma Netapp und verfügt über eine nutzbare Kapazität von
knapp über 150 TB. Bereits einige Monate später wurde das System auf 300 TB erweitert.
2.1.4.1.4
Speicher für die Wissenschaft
Das LRZ bemüht sich um die Bereitstellung von Speicherkapazitäten für alle Studierenden und Mitarbeiter der Hochschulen. Die derzeitige Infrastruktur für die Speicherung von Dateien und Dokumenten an
den Hochschulen ist dezentralisiert und die Qualität der angebotenen Dienstleistungen schwankt in Abhängigkeit von der zuständigen Teileinheit, verfügbaren Budgets und den für den Betrieb verantwortlichen Mitarbeitern. Die innerhalb des Projektes IntegraTUM (Projektende September 2009) evaluierten
und ausgearbeiteten technischen Grundlagen und Randbedingungen für hochschulweite Bereitstellung
59
von Speicher wurde erfolgreich umgesetzt und seit Mitte 2008 in den Produktivbetrieb überführt. Das
LRZ stellt seit dieser Zeit eine einfach zu bedienende, sichere und zentral administrierte Speicherlösung
bereit. Durch eine enge Kopplung mit Verzeichnisdiensten verfügen alle Mitarbeiter und Studierenden
sowohl über persönlichen Speicherplatz als auch über den Zugang zu Projektablagen. Gemeinsamer 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 zentrale Speicher wird gut angenommen, was die stetig steigende Anzahl der eindeutigen Benutzer-Kennungen (ohne Funktions- und
lokale Benutzerkennungen) mit simultanen Zugriffen zeigt (siehe Abbildung 24). Die Zugriffe haben sich
innerhalb des Jahres 2010 von ca. 650 auf fast 1.200 simultane Zugriffe fast verdoppelt.
Abbildung 24: Durchschnittliche Anzahl von simultan zugreifenden Kennungen von Jan 10 bis Jan 11
Für das im Dezember 2007 beschaffte Speichersystem, bestehend aus einem Primärspeichersystem (2 x
FAS6070) und einem Replikationssystem (FAS6070) wurden Ende 2009 Erweiterungen beschafft. Die
Bruttokapazitäten des Primärsystems wurden Anfang 2010 von 68 TByte auf 117 TByte und des Replikationssystems von 68 TByte auf 305 TByte (dient auch als Replikationssystem für die VMWare Speicherinfrastruktur) erhöht. Die Infrastruktur des Speichers für die Wissenschaft ist in Abbildung 25 dargestellt.
Abbildung 25: Infrastruktur des Speichers für die Wissenschaft
60
Der für die Speichersysteme beschaffte innovative Flashspeicher von 4 TB dient als intelligenter ReadCache. Durch den Einsatz dieser Technologie kann festplattenbasierter Speicher für Random-Readintensive Workloads wie File-Services optimiert und effizienter genutzt werden, da durch den Cache die
Anzahl der Platten-IOs reduziert wird. Somit können günstigere Speichermedien (SATA anstelle FC Platten) eingesetzt werden. Der Einsatz der Flashspeicher hat sich in der Praxis bewährt.
2.1.4.1.5
Speicher für Hochschulstart.de
Das LRZ hat sehr kurzfristig das Hosting für das Projekt Hochschulstart.de übernommen. Für das Projekt
wurde im Herbst 2010 ein hochverfügbares Speicher-Cluster (2 x NetApp FAS 3170, 50 TB) mit synchroner Spiegelung beschafft und installiert (siehe Abschnitt 2.9).
2.1.4.2
Wie in den meisten großen Rechenzentren wird auch am LRZ sowohl ein Storage Area Netzwerk (SAN)
als Grundlage für einen effizienten Transport von großen Datenmengen, insbesondere für die Datensicherung, als auch die NAS-Architektur zur Bereitstellung von Plattenspeicher eingesetzt.
HRR
HRLBII
8 x NAS
Home
AFS
128
Port
128 Port
NSR
AFS
2 x NAS
mass
storage
16AFS
Port
16 Port
2 x NAS
BSB
2 x NAS
SFS
2 x NAS
LRZ
6 x NAS
Linux
HPC
DAR
LABS
63 Port
64 Port
AFS
64 Port
64 Port
NAS
Mirror
SFS
HABS
122
Port
AFS
122 Port
NAS
Mirror
LRZ
Abbildung 26: SAN/NAS-Topologie
Das ursprüngliche Speichernetz, dessen Anfänge auf das Jahr 2000 zurückgehen, wurde vor einigen Jahren in mehrere sogenannte Fabrics aufgeteilt, um so eine höhere Verfügbarkeit gewährleisten zu können.
Es werden nun getrennte Fabrics für das Hochleistungsarchiv HABS, das LTO-Archiv- und Backupsystem LABS, das verteilte Filesystem AFS und das SAN-Filesystem des Bundeshöchstleistungsrechners
betrieben. An die SAN-Fabrics sind die Storageserver, ein Teil der NAS-Filer, alle Bandlaufwerke der
Libraries und alle Serversysteme mit hohem Datenverkehr, insbesondere die File- und Backupserver angeschlossen.
Abbildung 26 zeigt die Topologie des Netzwerks auf den verschiedenen Stockwerksebenen des Rechnergebäudes. Gut zu sehen ist die Anbindung der diversen NAS-Filer, über die der sogenannte NDMPBackup läuft. Die Sicherung über NDMP wird mittelfristig zu Gunsten einer Sicherung über das LAN
zurückgefahren, da sich die LAN-Sicherung kostengünstiger umsetzen lässt.
Insgesamt gibt es vier getrennte, sogenannte Fabrics im Speichernetz:
61
Redundantes SAN für das Hochleistungsarchiv:
Basis sind zwei FC-Direktoren mit je 96 Ports. Die Direktoren werden als zwei getrennte Fabrics
betrieben, um ein Höchstmaß an Ausfallsicherheit (redundant fabric) zu gewährleisten.
• SAN für das LTO-Archiv- und Backupsystem:
Die Verkabelung der 4 FC-Switches (4x32 Port) des LABS bildet eine Mesh-Struktur.
• Redundantes SAN für AFS:
Zwei 16 Port FC-Switches sorgen für die redundante Storageanbindung der AFS-Fileserver.
• SAN für das CXFS-Filesystem des HLRB II.
Als Storageserver werden ausschließlich Plattensysteme eingesetzt, deren Controller von LSI Logic
stammen. Da die Geräte im Laufe mehrerer Jahre über verschiedene Ausschreibungen beschafft wurden,
sind die Modellnamen trotzdem recht unterschiedlich:
• StorageTek D280
Der Storageserver D280 der Firma STK hat zwei 2 Gbit Fibre-Channel-Anschlüsse ins SAN,
über die eine aggregierte Leistung von 800 MB/s erreicht wird. Intern sind die Systeme mit 146Gigabyte-Platten bestückt und ebenfalls über Fibre Channel verkabelt. Die Gesamtkapazität beträgt 14 Terabyte. Der Plattenplatz der Systeme wird von den AFS-Fileservern und einem
MySQL-Server genutzt.
• StorageTek Flexline 380 Storageserver
Die Storageserver Flx380 der Firma STK haben acht 4 Gbit Fibre-Channel-Anschlüsse ins SAN,
über die eine aggregierte Leistung von 1600 MB/s erreicht wird. Intern sind die Systeme sowohl
mit 146-Gigabyte-Platten als auch 300-Gigabyte-Platten bestückt und ebenfalls über Fibre Channel verkabelt. Die Gesamtkapazität beträgt 115 Terabyte. Der Plattenplatz der Systeme wird ausschließlich von den Rechnern der TSM-Serverinstanzen genutzt. Die 146-Gigabyte-Platten werden als Speicher für die TSM-Datenbanken verwendet, die 300-Gigabyte-Platten für die Plattenpools der Server.
• SGI IS4500
Die 6 Storageserver vom Typ SGI IS4500 mit insgesamt 170 TB Kapazität kamen im Frühjahr
2010 dazu. Die Geräte wurden vorher am Linux-Computecluster des LRZ für das parallele Filesystem Lustre genutzt. Lustre wurde wegen seiner Instabilität durch eine NAS-Lösung ersetzt und
die SGI-Storageserver wurden vom NSR in den DAR umgezogen und leisten nun als Cache für
das Archiv- und Backupsystem gute Dienste.
• SUN StorageTek 6780
Zu Beginn des Jahres wurden drei Controllerpärchen mit insgesamt 516 TB Plattenplatz (FC und
SATA) für das neue Archiv- und Backupsystem LABS 2.0 installiert.
•
2.1.4.3
AFS
Seit 1992 wurde am LRZ das verteilte Filesystem AFS (Andrew Filesystem) eingesetzt. Es war in den
90er Jahren das zentrale Filesystem am LRZ, das von allen Diensten genutzt wurde. Im Rahmen des
TUM-Großprojekts IntegraTUM wurden auch die Alternativen für ein hochschulübergreifendes hochverfügbares Filesystem evaluiert. Bereits 2005 fiel dann die Entscheidung zu Gunsten einer NAS-basierten
Lösung. Seitdem wird an der Ablösung von AFS gearbeitet. Die tiefe Verwurzelung von AFS in zahlreiche Teilbereiche des LRZ-Dienstespektrums machte die Ablösung zu einem langwierigen Unternehmen,
das bis heute noch nicht abgeschlossen ist. Nach und nach wurden die Speicherbereiche verschiedener
Dienste aus AFS herausgelöst, zunächst der Mailbereich, der am wenigsten mit der speziellen Filesystemarchitektur von AFS zurechtkam, dann die Daten der Computecluster.
Mitte 2010 fand eine große Bereinigungsaktion nicht mehr oder kaum genutzter AFS-Homeverzeichnisse
und damit gekoppelt der AFS-Kennungen statt. Dadurch konnte die Anzahl der AFS-Kennungen von
vormals über 30.000 auf 2.300 reduziert werden. Heute liegen noch 800 GB in diesen Homeverzeichnissen, etwa ebenso viele Daten sind noch in allgemeinen Verzeichnissen, Webbereichen u.ä. gespeichert.
Die Räumung aller Bereiche wurde im Laufe des Jahres weiter vorangetrieben und soll Ende 2011 abgeschlossen sein.
62
2.1.5 Daten- und Archivraum
Im Rechnerwürfel des LRZ steht im Augenblick für die Geräte des Archiv- und Backupbereichs nahezu
ein gesamtes Stockwerk mit 560 m2 Nutzfläche zur Verfügung, der sogenannte Daten- und Archiv-Raum
(DAR, vgl. Abbildung 27). Die Dimensionierung erlaubte bisher eine optimale Aufstellung der Geräte.
Die sicherheits-technischen und klimatischen Randbedingungen waren gut geeignet für die langfristige,
sichere Aufbewahrung großer Datenmengen.
Abbildung 27: Daten- und Archivraum
Mit einer durchschnittlichen Leistungsaufnahme von unter 50 KW ist der Raum ein Aushängeschild für
Green-IT. Der geringe Energiebedarf ist darauf zurückzuführen, dass in diesem Raum primär Bandbibliotheken, deren Stromverbrauch gemessen an der Speicherkapazität sehr gering ist, stehen.
An dem für das Jahr 2012 geplanten Supercomputer der nächsten Generation werden deutlich mehr Daten
anfallen als bisher, für die Nearlinespeicher bereitgestellt werden muss. Es wird erwartet, dass für den
neuen Supercomputer während seiner Standzeit Speicher in der Größenordnung von 100 PB bereitgestellt
werden muss. Ein Grobkonzept für eine mehrstufige Installation der dazu notwendigen Komponenten
wurde festgelegt. Der Daten- und Archivraum wird dazu an den Erweiterungsbau angebunden. Umfangreiche Staubschutzmaßnahmen sind während der Bauarbeiten notwendig, um die Staubbelastung für Kassetten und Bandlaufwerke so gering wie möglich zu halten. So wird zum Beispiel im Raum ständig ein
gewisser Überdruck gegenüber der Außenhaut erzeugt.
2.2
Entwicklungen bei den Rechensystemen
2.2.1 Höchstleistungsrechner in Bayern (HLRB II: SGI Altix 4700)
2.2.1.1
Kennzahlen des Systems
Anzahl SMP Knoten
CPUs pro Knoten
Anzahl Prozessoren
Peakperformance pro CPU
Peakperformance pro Knoten
Peakperformance des Gesamtsystems
LINPACK
Hauptspeicher pro Knoten
Hauptspeicher des Gesamtsystems
Plattenspeicher
19
512
9728 (=19*512)
*
6.4 GFlop/s
**
3.3 TFlop/s
**
62.3 TFlop/s
**
56.5 TFlop/s
2056 GByte
39064 GByte
660 TByte
Tabelle 20: Kennzahlen des HLRB II: SGI Altix 4700
63
Abbildung 28: SGI Altix 4700 im Höchstleistungsrechnerraum (HRR) des LRZ
2.2.1.2
Betriebliche Aspekte
Im Berichtsjahr 2010 konnte die Betriebsstabilität und die Verfügbarkeit durch das Einspielen kleinerer
Software Updates durch SGI weiter erhöht werden. Ab November 2010 traten jedoch nach einem Upgrade Performanceprobleme mit dem parallelen Filesystem auf, die im Berichtsjahr nicht gelöst werden
konnten.
Die Verfügbarkeit des Systems ist in Abbildung 29 dargestellt. Mit ca. 97% Verfügbarkeit kann man bei
einem so großen System sehr zufrieden sein. Die Gründe für die Ausfälle sind in Abbildung 30 dargestellt.
Abbildung 29: Übersicht über die Verfügbarkeit (Monatsmittel) des HLRB II (SGI Altix 4700)
64
HLRB II unavailability statistics 2010
1.00%
0.90%
unavailability [%]
0.80%
0.70%
0.60%
0.50%
0.40%
0.30%
0.20%
0.10%
0.00%
Erläuterungen:
DIMM: Memorybausteine
CPU: Central Processing Unit
Blade: Platine
POD: Power On Discovery (Fehler beim Selbsttest nach Power On)
Router: Dual- oder Quad-Dense-Router
IRU: Individual Rack Unit(Enclosure für bis zu 16 Blades)
L1: Kontrolleinheit für eine IRU
PS: Power Supply, Netzteil
NUMA Link: Fehlerfortpflanzung auf andere Partitionen
10GigE: Netzwerkkarte
xpc: Cross Partition Communication Software
CXFS or RAID: Plattenfehler
OS: Fehler im Betriebssystem
user: durch Benutzer verursachte Störung
Maintenance: Stillstandszeiten durch (geplante) Wartungen
Abbildung 30: Gründe für Ausfälle des HLRB II
2.2.1.3
Nutzungsübersicht
Die Schwerpunkte der Arbeiten in diesem Jahr lagen auf der Stabilisierung des Betriebs und der Optimierung und Skalierung von Benutzerprogrammen. Das Angebot an Chemiesoftware und mathematischen
Bibliotheken wurde wiederum erweitert. Neue Compilerversionen wurden getestet und installiert. Der
HLRB II zeigte ab Frühjahr 2010 einen sehr stabilen Betrieb, wobei vor allem die Anzahl der softwarebedingten Ausfälle deutlich zurückgegangen ist.
Die abgegebene Rechenzeit (ausgedrückt in Core*Stunden) des HLRB II sind in Abbildung 31 dargestellt. Im Jahr 2010 wurden am HLRB II ca. 68 Mio. Core*Stunden abgegeben. Berücksichtigt man die
Service- und die Interaktivknoten nicht, so sind das etwa 83% der maximal abgebbaren Rechenzeit. Der
Anstieg der abgegebenen Rechenzeit ist auf mehrere Faktoren zurückzuführen:
65
• Weniger und lokalisiertere Systemabstürze
• Weniger und kürzere Wartungen
Eine weitere Steigerung der abgegebenen Rechenleistung ist im letzten Betriebsjahr nicht zu erwarten.
Abbildung 31: Abgegebene Rechenzeit des HLRB II (in Core-Stunden)
Abbildung 32: Mittlere Rechenleistung des HLRB II in GFlop/s. 2006 und
teilweise 2007 vor Upgrade auf Phase2
Die mittlere Rechenleistung des Systems hat in diesem Jahr einen deutlichen Einbruch erlitten (siehe
Abbildung 32). Dies ist zum einen auf die stark gestiegene Anzahl von neuen Projekten zurückzuführen,
zum anderen auch darauf, dass auf Grund der Personalknappheit und der Inanspruchnahme der Mitarbei-
66
ter für die SuperMUC-Beschaffung weniger gezielte Optimierungen von Benutzerprogrammen durchgeführt werden konnten.
Die Verteilung der abgegebenen Rechenzeit auf einzelne Jobklassen ist in Abbildung 33 dargestellt. Der
Schwerpunkt der Nutzung liegt immer noch zwischen 128 und 512 Prozessorkernen. Es sind daher deutlich mehr Anstrengungen notwendig, um die Applikationen für die Nutzung zukünftiger Rechnergenerationen mit mehr als einhunderttausend Cores vorzubereiten und zu optimieren.
Abbildung 33: Verteilung der Rechenzeit nach Jobgröße (Legende gibt die Anzahl von Cores an)
Wartezeiten von Jobs
120
Wartezeit (h)
100
80
2006
60
2007
40
2008
20
2009
0
2010
Jobgröße (Cores)
Abbildung 34: Wartezeiten der Jobs
Die durchschnittlichen Wartezeiten in Abhängigkeit von der Jobgröße sind in Abbildung 34 dargestellt.
Zum einen sieht man das Anwachsen der Wartezeiten für kleine bis mittlere Jobs aufgrund der zunehmenden Überbuchung der Maschine, zum anderen auch den Effekt von administrativen Maßnahmen,
große Jobs (ab ca. 1024 und darüber) zu bevorzugen und deren Wartezeiten in Grenzen zu halten. Für
67
Jobs größer als 4096 Cores sind solche Maßnahmen aber nicht mehr sinnvoll, da sie zu großen Leerständen auf der Maschine führen würden. Für solche Jobs sind lange Wartezeiten unvermeidbar.
2.2.1.4 Nutzungsstatistik
Die Anzahl der aktiven Nutzer des HLRB II hat sich im Bereichtszeitraum nur noch leicht erhöht. Die
Anzahl von Projekten ist leicht zurückgegangen.
Number of Users and Projects
600
514
500
510
527
389
400
Users
300
200
100
196
135
186
139
Projects
180
62
0
2006
2007
2008
2009
2010
Abbildung 35: Entwicklung der Anzahl aktiver Benutzer und Projekte
Die Verteilung der Rechenzeit auf die einzelnen Fachgebiete ist in Tabelle 21 aufgeführt. Die zeitliche
Entwicklung in den einzelnen Fächern ist in Abbildung 36 dargestellt. Bemerkenswert für 2010 ist die
wachsende Bedeutung der Biowissenschaften.
Die Aufschlüsselung der Rechenzeitabgabe nach der Herkunftsregion der am HLRB II durchgeführten
Projekte ist in Tabelle 22 angegeben.
In dieser Statistik sind neben deutschen Bundesländern auch Staaten aufgeführt, die in DEISA (Distributed European Infrastructure for Supercomputing Applications) aktiv sind. Für die Projekte aus Deutschland, die in DEISA und oder von virtuellen Organisationen in D-Grid durchgeführt wurden, kann kein
eindeutiges Bundesland zugeordnet werden; sie wurden deshalb in einem eigenen Punkt „Deutschland“
zusammengefasst.
Die zehn größten Projekte am HLRB II sind in Tabelle 24 aufgeführt. Kritisch ist im Berichtsjahr zu vermerken, dass auf Grund der stark gestiegenen Anzahl von neuen Projekten der Anteil der größten Projekte an der Rechenzeit stark zurückgegangen ist. In früheren Jahren lag dieser bei ca. 10%. Diese Situation
ist sehr unbefriedigend und muss mit der Inbetriebnahme des neuen Höchstleistungsrechners beseitigt
werden.
68
Fachgebiet
Computational Fluid Dynamics
Astrophysics/Cosmology
Chemistry
Biophysics/Biology/Bioinformatics
Physics - Solid State
Physics - High Energy Physics
Geophysics
Engineering - others
Informatics/Computer Sciences
Met/Clima/Oceanography
Grid Computing
Support
Electr. Engineer.
Physics - others
Medicine
% CPU-h
31.5%
14.5%
9.7%
9.5%
7.3%
6.7%
5.9%
3.3%
3.0%
2.8%
2.3%
1.0%
0.9%
0.8%
0.7%
CPU-h
21337381
9836460
6568450
6427534
4914823
4556832
4002677
2257973
2044633
1921560
1585952
659318
618049
520296
468998
Jobs
18.8%
8.4%
14.6%
7.2%
9.7%
7.6%
3.8%
3.6%
7.2%
2.8%
0.4%
14.6%
0.3%
0.7%
0.3%
Jobs
12864
5703
9991
4902
6630
5170
2571
2460
4942
1918
276
9995
210
472
184
Tabelle 21: Verteilung der Rechenzeit nach Fächern am HLRB II im Jahr 2010
Abbildung 36: Zeitliche Entwicklung des Anteiles der Fachgebiete an der Gesamtrechenzeit
Land
Bayern
Baden-Württemberg
Brandenburg
Nordrhein-Westfalen
Thüringen
Deutschland (VO)
Niedersachsen
Berlin
Hessen
United Kingdom
Spanien
Italien
Niederlande
Mecklenburg-Vorpommern
Hamburg
Sachsen-Anhalt
Finnland
69
2006
49.3%
8.9%
3.8%
8.1%
4.4%
0.0%
4.0%
5.6%
1.4%
7.2%
0.0%
0.9%
0.0%
6.3%
0.0%
0.0%
0.0%
2007
52.9%
11.6%
9.7%
5.9%
5.6%
6.9%
1.6%
0.8%
1.1%
0.8%
0.4%
1.1%
0.6%
0.6%
0.0%
0.3%
0.0%
2008
40.5%
10.1%
14.7%
14.3%
6.2%
3.6%
2.4%
2.4%
2.2%
0.4%
1.0%
0.7%
1.0%
0.1%
0.0%
0.3%
0.0%
2009
45.7%
16.5%
14.1%
6.3%
4.1%
1.6%
2.0%
4.5%
3.1%
0.3%
0.9%
0.5%
0.0%
0.0%
0.0%
0.0%
0.3%
2010
49.2%
14.0%
5.3%
7.3%
2.9%
5.6%
7.4%
4.0%
1.8%
1.3%
0.0%
0.0%
0.1%
0.0%
0.8%
0.0%
0.0%
Gesamt
46.6%
13.2%
10.8%
8.6%
4.5%
4.1%
3.6%
3.2%
2.2%
0.9%
0.6%
0.5%
0.4%
0.3%
0.2%
0.1%
0.1%
Tabelle 22: Verteilung der Rechenzeit nach Ländern am HLRB II
Tabelle 23 gibt die institutionelle Zugehörigkeit der Projekte wieder.
Institutionelle Zugehörigkeit
Universitäten
Helmholtz-Gemeinschaft
Max-Planck-Gesellschaft
Deisa
D-Grid
Fraunhofer Gesellschaft
2006
80.6%
0.1%
3.7%
14.8%
0.7%
0.0%
0.0%
2007
61.9%
6.9%
18.4%
5.7%
2.4%
4.7%
0.0%
2008
62.9%
8.2%
21.3%
6.0%
0.8%
0.8%
0.0%
2009
69.3%
14.7%
10.6%
3.7%
1.7%
0.0%
0.0%
2010
72.7%
10.7%
8.7%
7.0%
0.9%
0.0%
0.0%
Gesamt
67.7%
10.4%
13.9%
5.8%
1.3%
1.0%
0.0%
Tabelle 23: Verteilung der Rechenzeit nach institutioneller Zugehörigkeit am HLRB II
Nr.
Projekt
1
h0351
Principal Investigator/
Institution
Krüger/TU München
2
pr47he
Shishkina/DLR Göttingen
3
4
5
h1021
h0983
h006z
Müller/Uni Jena
Stemmer/TU München
Schierholz/DESY Zeuthen
6
7
8
h0485
h019z
h0323
Götz/Uni Erlangen
Igel/Uni München
Schäfer/Uni Regensburg
9
pr95ba
Uhlmann/Uni Karlsruhe
10
h1061
Wassen/TU Berlin
Project Title
Density Functional Investigations of Complex Chemical
Systems
High-resolved numerical simulations of turbulent nonOberbeck-Boussinesq Rayleigh-Benard convection
Dynamics of binary black hole systems
Large Scale CFD for Complex Flows
Simulation of N_f equal 2+1 lattice QCD at realistic
quark masses
Hyper-Scale waLBerla
Computational wave propagation
Dynamical lattice QCD with Ginsparg-Wilson-type
fermions
Interface-resolved direct numerical simulation of
turbulent channel flow with suspended solid particles
Investigation of turbulent drag reduction by flexible
lamellas
% CPU
CUM
3.9%
3.9%
3.5%
7.4%
2.8%
2.8%
2.8%
10.2%
13.0%
15.8%
2.8%
2.2%
2.2%
18.5%
20.7%
22.9%
2.1%
25.1%
2.1%
27.2%
Tabelle 24: Die zehn größten Projekte und ihr Anteil an der Gesamtrechenzeit am HLRB II im Jahr 2010
70
2.2.2 Linux-Cluster
2.2.2.1
Weiterentwicklung des Systems
Für das Berichtsjahr sind im Wesentlichen Anstrengungen zur Konsolidierung des Betriebs sowie die
Inbetriebnahme neuer Hardware zu verzeichnen. Nachdem 2009 das parallele Dateisystem Lustre immer
wieder größere Störungen verursacht hatte, wurde Anfang 2010 seine Ablösung durch NAS-basierten
Speicher mit erheblich verbesserter Metadatenleistung durchgeführt. Das Dateisystem läuft seitdem praktisch ohne Probleme.
Die seit 2003 bzw. 2005 betriebenen Itanium-Systeme vom Typ McKinley und Madison des Clusters
wurden im November 2010 außer Betrieb genommen; für diese Systeme waren schon seit einiger Zeit
keine Ersatzteile verfügbar und ihr Energieverbrauch war im Verhältnis zur abgegebenen Rechenleistung
zu hoch. Ähnliches gilt für die seit 2004 betriebene Altix 3700 mit 128 Madison Prozessorkernen, die
ebenfalls außer Betrieb ging.
Im Gegenzug sind zwei neue, von SGI gelieferte Systeme nach ausführlicher Hard- und SoftwareEvaluierung im Rahmen des PRACE Projektes in das Cluster integriert worden: eine auf der Nehalem-EP
Architektur basierende SGI ICE mit 64 über Infiniband vernetzten Knoten mit je zwei 4-core Sockeln
(also 512 Cores) und einer Spitzenrechenleistung von etwas mehr als 5 TFlop/s sowie ein auf NUMAlink-Technologie basierendes großes Shared-Memory Ultraviolet 1000 System mit 256 Nehalem-EP
Cores, 512 GByte Hauptspeicher und einer Spitzenrechenleistung von etwa 2 TFlop/s. Ein weiterer Ausbau der parallelen Cluster-Kapazität wurde durch die DFG im Sommer 2010 genehmigt und soll nach
Abschluss der erforderlichen Beschaffungsverfahren Anfang bzw. Mitte 2011 in Benutzerbetrieb gehen
(siehe unten).
2.2.3 Tests und Prototypen
Das LRZ wurde von Intel als eines von wenigen Zentren weltweit ausgewählt, um vorab die neue Intel
MIC-Architektur zu testen (Many Integrated Cores). Ab Mai stand dem LRZ ein "Knights Ferry"Prototyp für Tests zur Verfügung, erste Ergebnisse wurden in dem nicht-öffentlichen PRACE-Deliverable
"Final Technical Report and Architecture Proposal" dokumentiert.
Weiterhin wurden Tests von spezieller Beschleuniger-Hardware, insbesondere von NVIDIA GPGPUs,
Analysen zur Performance und Anwendbarkeit neuer Programmiersprachen und -paradigmen für hochparallele Systeme und eine Evaluierung der Programmierumgebung HMPP ("Hybrid Multicore Parallel
Programming Workbench“) sowie des PGI Accelerator Compilers, die beide die Programmierung von
GPGPUs wesentlich vereinfachen, durchgeführt. Beta-Tests von Intels neuer datenparalleler Programmiersprache "Intel Array Building Blocks (ArBB)“, Mitwirkung an der ausgedehnten Beta-phase für den
12.0 Compiler mit Coarray-Funktionalität sowie die Einladung des LRZ zur Mitwirkung am Intel Software Customer Advisory Board zeigen, dass das LRZ ein begehrter Partner ist. Arbeiten zur synthetischen Performance-Modellierung der Applikationen runden diesen Arbeitsbereich ab.
2.2.4 Linux MPP Erweiterung
Ein Antrag zur Ersetzung der Itanium-Komponenten im Linux-Cluster wurde Anfang 2010 erstellt und
nach Jahresmitte genehmigt. Es werden ein großes MPP-System und ein großes Shared Memory System
für das Cluster beschafft. Die Beschaffung des MPP-Anteils musste noch 2010 erfolgen, deshalb war es
trotz des hohen Arbeitsaufwandes für die SuperMUC-Ausschreibung zusätzlich nötig, für diese Beschaffung Unterlagen und Benchmarks zusammenzustellen und die Angebote der Hersteller auszuwerten. Wie
auch beim SuperMUC legte das LRZ hierbei großen Wert auf Energieeffizienz und die mögliche Nutzung
der Warmwasserkühlung im neuen Rechnerwürfel. Den Zuschlag für die Lieferung von 1824 Infinibandvernetzten AMD-Cores für das Cluster erhielt die Firma Megware mit ihrem innovativen WarmwasserKühlungskonzept. Das neue Cluster soll mit der MPI Software „Parastation“ der Firma Par-Tec betrieben
werden; es wird eine deutliche Zunahme der parallelen Job-Größen auf dem Cluster zulassen.
71
2.2.4.1 Nutzungsstatistiken für das Linux-Cluster
Kategorie
LRZ
BAY
BAY
BAY
BAY
BAY
BAY
BAY
LCG
HLR
HLR
Kör
Kör
HSM
TUM
TUM
TUM
TUM
TUM
TUM
TUM
TUM
TUM
TUM
LMU
LMU
LMU
LMU
LMU
LMU
LMU
LMU
LMU
Sonstige
Summe
Summe
Summe
Summe
Institution/Fachbereich
LRZ
Hochschule Ingolstadt (FH)
Universität Regensburg
Universität Erlangen
Universität Würzburg
Universität Bayreuth
Katholische Universität Eichstätt
Universität Augsburg
LCG (Large Hadron Collider Computing Grid)
Fraunhofer ITWM - HPC department
Astrogrid
Bayerisches Staatsministerium für Wissenschaft,
Forschung und Kunst
Hochschulnahe Einrichtungen
Feinwerk- und Mikrotechnik
Maschinenwesen
Chemie
Mathematik
Wissenschaftszentrum Weihenstephan
Bauingenieur- und Vermessungswesen
Elektrotechnik und Informationstechnik
Wirtschaftswissenschaften
Informatik
Zentralbereich
Medizin
Betriebswirtschaft
Zentrale Einrichtungen und Verwaltung
Physik
Chemie und Pharmazie
Geowissenschaften
Medizinische Fakultät
Biologie
Mathematik, Informatik und Statistik
Volkswirtschaftliche Fakultät
Sonstige
LCG (Large Hadron Collider Computing Grid)
Ludwigs-Maximilians-Universität
Sonstige Bayerische Hochschulen
Summe
total
Anzahl Jobs
113830
229
113952
59210
83612
11162
11217
1582
3412774
47
17314
703621
% Jobs
1.39
0.00
1.39
0.72
1.02
0.14
0.14
0.02
41.55
0.00
0.21
8.57
Core-h
750217
21983
2384465
862948
382926
913868
213659
53253
5332378
442
149626
137547
% Core-h
2.56
0.07
8.12
2.94
1.30
3.11
0.73
0.18
18.17
0.00
0.51
0.47
399
4475
16846
150306
15879
96063
755730
25138
7457
385005
659
1380
26
294
1779629
10010
3139
33133
365179
20981
350
13059
3412774
1454463
2212748
280964
0.00
0.05
0.21
1.83
0.19
1.17
9.20
0.31
0.09
4.69
0.01
0.02
0.00
0.00
21.67
0.12
0.04
0.40
4.45
0.26
0.00
0.16
41.55
17.71
26.94
3.42
36833
138867
2775163
1641675
848987
606210
392107
214941
111205
212104
60121
46363
2517
1659
8026341
1111469
786248
266123
513331
113530
121032
119875
5332378
6908875
10942252
4833102
0.13
0.47
9.46
5.59
2.89
2.07
1.34
0.73
0.38
0.72
0.20
0.16
0.01
0.01
27.35
3.79
2.68
0.91
1.75
0.39
0.41
0.41
18.17
23.54
37.28
16.47
8213687
100.00
29350013
100.00
Tabelle 25: Linux-Cluster Nutzung nach institutioneller Zugehörigkeit und Fachgebiet
2.2.5 Remote Visualisierungsserver
Die auf dem HLRB II oder dem Linux-Cluster erzeugten Datensätze erreichen inzwischen oftmals eine
Größe, die eine Visualisierung auf PCs oder einfachen Workstations nicht mehr gestattet. Der Dienst
„Remote-Visualisierung“ wird daher von den Benutzern sehr gut angenommen, was an der auf hohem
Niveau liegenden Auslastung der Hardware-Reservierungen abzulesen ist, so dass Anwender bereits temporär vom automatischen Reservierungssystem abgewiesen werden mussten. Das RemoteVisualisierungssystem RVS1 für HLRB II Benutzer läuft seit Inbetriebnahme stabil. Die beiden aus DGRID Mitteln für den Linux-Cluster neu beschafften Remote-Visualisierungs-Server GVS1 und GVS2
liefen Anfang des Jahres recht instabil. Als Ursache wurden BIOS-Probleme gefunden, die verhinderten,
dass die Maschinen in der gekauften Vollbestückung (8 CPU-Module und 4 Grafikkarten) korrekt arbeiten konnten. Der Hersteller lieferte deswegen im Juni zwei zusätzliche Server-Gehäuse. Die CPU-Module
und Grafikkarten konnten dann auf vier Maschinen verteilt werden, die seither stabil laufen. Insgesamt
stehen den Anwendern nun fünf Server (RVS1, GVS1-4) mit zusammen 80 Cores und insgesamt zwölf
Hochleistungsgraphikkarten zur Verfügung. Sämtliche Visualisierungs-Server sind auch per GridZertifikat benutzbar. Wegen der hohen Nachfrage nach GPGPU-Programmierung (speziell NVIDIA CU-
72
DA) wurde hierfür ein dediziertes CUDA Testsystem angeschafft (1 Workstation mit Intel Nehalem EX,
1 Tesla C1060 Karte und 1 GeForce 9800 Grafikkarte).
2.3
Aktivitäten zur Beschaffung des neuen Petascale-Rechners
SuperMUC
Nach mehr als einjähriger Vorbereitung konnte die Beschaffung des nächsten (europäischen) Höchstleistungsrechners unter dem Dach des Gauß-Zentrums für Supercomputing als Wettbewerblicher Dialog
zwischen Februar und Dezember 2010 durchgeführt und zum erfolgreichen Abschluss gebracht werden.
Dafür wurden die im letzten Jahr begonnen Arbeiten an den Verdingungsunterlagen und der Benchmarksuite Anfang dieses Jahres abgeschlossen. Nach über zwanzig jeweils ganztägigen Einzelverhandlungen mit anfänglich fünf Bietern erhielt am Ende das Angebot der Firma IBM den Zuschlag. Ein Migrationssystem soll Mitte 2011 in Betrieb gehen, der Hauptteil des SuperMUC genannten Systems soll bis
Ende Mai 2012 betriebsbereit sein und über drei PFlop/s Spitzenrechenleistung verfügen. Der gesamte
Beschaffungsvorgang ist in Tabelle 26 noch einmal dargestellt.
In Anwesenheit von Staatsminister Dr. Wolfgang Heubisch unterzeichneten am 13.12.2010 Prof. Dr.
Arndt Bode, Vorsitzender des Direktoriums des Leibniz-Rechenzentrums (LRZ) der Bayerischen Akademie der Wissenschaften, und Martin Jetter, Vorsitzender der Geschäftsführung der IBM Deutschland
GmbH, den Vertrag hierzu.
Damit kommt im Frühjahr 2012 einer der leistungsfähigsten und der wohl effizienteste Rechner der Welt
nach Garching. Der „SuperMUC“ genannte Rechner wird mehr als 110.000 Prozessorkerne neuester
Bauart der Firma Intel aufweisen und damit eine Leistung von drei Petaflop/s erreichen, das sind drei
Billiarden Rechenoperationen pro Sekunde – eine Drei mit 15 Nullen. Eine neuartige, von der Firma IBM
in Deutschland entwickelte Hochtemperatur-Flüssigkeitskühlung und eine ausgefeilte Wärmerückgewinnung sorgen für eine optimale Energieausnutzung. Minister Heubisch betonte bei der Vertragsunterzeichnung: „Das Leibniz-Rechenzentrum in Garching wird mit dem neuen Höchstleistungsrechner zum Vorreiter einer energieoptimierten Computertechnik.“
Abbildung 37: Foto von der Vertragsunterzeichnung für SuperMUC, v.l.n.r.: Staatsminister Dr. Wolfgang
Heubisch, Prof. Dr. Arndt Bode, LRZ, Martin Jetter, IBM, Andreas Pflieger, IBM, Prof. Dr. Dietmar
Willoweit, Präsident der Bayerischen Akademie der Wissenschaften
Vorgang
Markterkundung
Informationspapier für Hersteller
Herstellerbesuche des Direktoriums
Kolloqium für Herstellerfirmen
Technische Einzelbesprechungen mit Firmen
Sitzung der Kommission für Informatik zur Benennung des
Auswahlgremium
Hersteller-Konzept für Petascale-Rechner am LRZ
Benchmarks (Vorbereitung)
Auswahl Benchmarkprogramme
Erstellung herstellerfähiger Versionen
Eignung auf verschiedenen Architekturen testen
Auslieferung der Benchmarksuite an Hersteller
Durchführung von Tests durch Hersteller
Beschaffungsprozess
Verdingungsunterlagen (erste Iteration) erstellen
Bestätigung der Verdingungsunterlagen durch
Auswahlgremium
Wettbewerblicher Dialog
Ankündigung
Versendung der Vergabeunterlagen
Abgabefrist für Teilnahmeanträge (8 Anträge)
Prüfung der Teilnahmeanträge
Auswahl der Dialogteilnehmer (Bull, CRAY, HP, IBM, SGI)
Erste Dialogphase (3 Verhandlungsrunden mit 5 Teilnehmern)
Schärfung der Leistungsbeschreibung durch LRZ
Erstellung der Angebote durch Firmen
Auswertung der Angebote
Auswahl der Shortlist (2 Bieter: IBM, SGI)
Zweite Dialogphase (3 Verhandlungsrunden mit 2 Teilnehmern)
Finale Leistungsbeschreibung vom LRZ erstellt
endgültige Angebotserstellung durch Firmen
Rechnerauswahl
Sitzung der Auswahlkommission (Entscheidung für IBM)
Vertraggestaltung
Frist GWB §101a
Vertragsgestaltung und -verhandlungen
Vertragsunterschrift
73
Datum/Vom
Feb 09
Mrz 09
Mrz 09
Mai 09
Jun 09
Jul 09
Bis
Dez 09
Mrz 09
Dez 09
Dez 09
Mai 09
Mai 09
Mai 09
Mai 09
Jan 10
Jan 10
Dez 09
Dez 09
Jan 09
Mai 10
Dez 09
Dez 09
Mai 10
Dez 10
Jan 09
Feb 10
Feb 10
Feb 10
Feb 10
Feb 10
09.03.2010
Mar 10
Jun 10
Jun 10
Jul 10
28.07.2010
Aug 10
Sep 10
Sep 10
Nov 10
10.11.2010
15.11.2010
15.11.2010
20.11.2010
13.12.2010
Nov 10
Jul 10
Jul 10
Nov 10
Okt 10
13.12.2010
20.11.2010
12.12.2010
Tabelle 26: Beschaffungsvorgang für den nächsten Höchstleistungsrechner SuperMUC
Mit dem SuperMUC wird die bewährte Linie der auf vollwertigen Prozessoren basierenden, universell
einsetzbaren Höchstleistungsrechner am LRZ konsequent fortgesetzt. SuperMUC wird den jetzigen, 2006
in Betrieb genommenen „HLRB II“ ersetzen und erneut den Sprung an die technologische Spitze schaffen. Mit 3 Petaflop/s Spitzenrechenleistung, 320 Terabyte Hauptspeicher und 12 Petabyte Hintergrundspeicher wird SuperMUC zu den leistungsfähigsten Universalrechnern der Welt gehören, wenn er Mitte
2012 in Betrieb geht.
Die Architektur des SuperMUC lässt trotz der imposanten Zahl von mehr als 110.000 Prozessorkernen
einen stabilen Dauerbetrieb und sehr gute Skalierung erwarten. Über das Gauß Zentrum für Supercomputing (GCS) können Wissenschaftler in Bayern, Deutschland und darüber hinaus den neuen Höchstleistungsrechner bruchlos und ohne Änderung an den bisherigen Programmierkonzepten nutzen. Über die
Infrastruktur PRACE (Partnership for Advanced Computing in Europe) eröffnet SuperMUC weitere neue
Möglichkeiten für Wissenschaftler in 21 europäischen Mitgliedsstaaten.
Revolutionär ist das neue Kühlkonzept. Die aktiven Komponenten wie z.B. Prozessoren und Memory
werden unmittelbar mit Wasser gekühlt, das über vierzig Grad warm sein darf. Diese „Hochtemperatur-
74
flüssigkeitskühlung“ und eine hochinnovative Systemsoftware zur energieeffizienten Leistungssteuerung
ermöglichen es, den Anstieg des Energieaufwands und damit der Betriebskosten so gering wie möglich zu
halten und darüber hinaus alle LRZ-Gebäude mit der Abwärme des Rechners zu heizen. „SuperMUC“
steht für unerreichte Energieeffizienz im Sinne des Green Computing und für Spitzenleistung in der Rechenkapazität durch massive Parallelität der universell einsetzbaren Multicore-Prozessoren.
Abbildung 38: Prof. Arndt Bode (LRZ) und Martin Jetter (IBM) mit einem Prototypen für ein Bauteil des
SuperMUC. Die Kupferrohre zur Zu- und Abführung der Kühlflüssigkeit sind klar zu erkennen.
Die Investitions- und Betriebskosten für fünf bis sechs Jahre einschließlich der Stromkosten für den SuperMUC werden 83 Mio. Euro betragen, die das Land Bayern und der Bund zur Hälfte finanzieren, ebenso wie die 50 Mio. Euro für die bereits laufende Gebäudeerweiterung des LRZ. Darüber hinaus fördert
Bayern weitere begleitende Projekte wie z.B. das Bayerische Kompetenznetz für WissenschaftlichTechnisches Höchstleistungsrechnen KONWIHR mit seinen mehr als 25 überregionalen Anwendungen.
Wissenschaftsminister Dr. Wolfgang Heubisch bezeichnete den SuperMUC als Investition in die Zukunft:
„Leistungsfähige Rechner und Software sind heute der Schlüssel für wissenschaftliche und technologische Konkurrenzfähigkeit. Das Leibniz-Rechenzentrum in Garching wird mit dem neuen Höchstleistungsrechner zum Vorreiter einer energieoptimierten Computertechnik.“
2.4
Software und User Support im Bereich Hochleistungsrechnen
2.4.1 Software für Linux-Cluster und Höchstleistungsrechner
Im Software-Portfolio erfolgten Aktualisierungen und Erweiterungen; aus dem Bereich der Quantenchemie sind neue Releases von NAMD, CASTEP, Gamess, Gaussian, Molpro, NWChem, Amber, CP2K und
VASP sowie zusätzliche Pakete wie Abinit, ACESS oder Schrödinger zu nennen. Im Bereich der Entwicklungssoftware sind Verbesserungen bei der Fortran 2003 und OpenMP 3.0 Unterstützung (Intel
Compiler) sowie der direktivengesteuerten Programmierung von Beschleunigerkarten (PGI Compiler)
und neuere Versionen der Werkzeuge zur Fehlersuche und -behebung (Totalview, Forcheck, Valgrind)
eingeführt worden. Die MPI Implementierung der Firma Intel wurde im Hinblick auf die Skalierbarkeit
erheblich verbessert und dient auch als Grundlage für eine erste Implementierung des im neuen Fortran
2008 Standard integrierten parallelen PGAS-Programmiermodells „Coarrays“.
75
2.4.2 Supportanfragen
Die deutlich gesteigerte Anzahl von Nutzern und der große Job-Durchsatz am HLRB II und am LinuxCluster haben zu einer weiteren Steigerung von Supportanfragen geführt, die nur mittels des Troubleticket-System gezielt abgearbeitet werden können (siehe Tabelle 27). Diese Möglichkeit der Kontaktaufnahme wurde von den Benutzern sehr gut angenommen und hat die Kontaktaufnahme via Email fast
komplett ersetzt. Die deutlich gestiegene Anzahl von Anfragen, teilweise von recht unerfahrenen Benutzern führt zu einer deutlich gesteigerten Arbeitsbelastung der Mitarbeiter, vor allem, da diese Anfragen
unvermittelt in den Arbeitsablauf eindringen. Da die Supportgruppe für den HLRB und das Linux-Cluster
der größte Nutzer des Troubleticket-Systems am LRZ ist, hat sie auch als erste das neue Incident Managementsystem IeT ITSM eingeführt.
2008
2009
2010
574
625
838
Tabelle 27: Anzahl Troubletickets im Bereich Hochleistungsrechnen
2.4.3 Einführung des neuen Incidenttools
Im September wurde der Pilotbetrieb des neuen ITSM Tools von IeT Solutions im Rahmen des Incident
Managements für das Linux-Cluster und kurze Zeit später auch für den HLRB gestartet. Das neue Servicedesk-Tool bietet dem Anwender deutlich mehr Möglichkeiten mit dem LRZ zu interagieren und den
Zustand eines Incidents einzusehen. Zahlreiche Probleme und Konfigurationswünsche mussten hierzu
vom ITSM Team gelöst werden.
2.4.4 Benutzerverwaltung
Die Workflows für Benutzerverwaltung und Antragstellung am Linux-Cluster und HLRB konnten weiter
verbessert und automatisiert werden. Durch das am LRZ nun eingeführte Single Identity Management ist
jetzt ein leichterer Zugriff auf Benutzerdaten und die Validierung von Benutzern für verschiedene Dienste
möglich. So wurden das HLRB- und Linux-Web-Antragsformular neu generiert und bereits vorhandene
Informationen können bei der Bearbeitung zur Erleichterung für den Master-User eingeblendet werden.
2.4.5 Kurse und Ausbildung
Das Aus- und Weiterbildungsangebot konnte auch im Berichtsjahr erheblich erweitert werden. Der hohe
Wissensstand und die Güte der Kurse am LRZ drückt sich auch dadurch aus, dass Dr. Bader aus der
Gruppe Hochleistungsrechnen im Fortran-Standardisierungskommittee WG5 mitarbeitet und auf der Supercomputing-Konferenz in New Orleans zu ersten Mal mit einem Tutorial zum Thema PGAS-Sprachen
(Partitioned Global Address Space) vertreten war. Außerdem wurde Herr Bader zu einem Vortrag über
PGAS Konzepte in Fortran und UPC am IDRIS in Frankreich eingeladen. Es zeigt sich aber auch, dass
das Kursangebot mit der jetzigen Personalkapazität nicht mehr weiter ausgebaut werden kann, obwohl es
gerade in der jetzigen Umbruchzeit mit vielen neuen Ansätzen (neuen Programmiersprachen, Multi- und
Manycores, GPGPUs) sehr viele Themen zur Ausbildung gäbe. Das LRZ wird hier deshalb versuchen, in
Zusammenarbeit mit Firmen und anderen Rechenzentren die Attraktivität seines Kursangebotes weiter
aufrecht zu erhalten.
2.4.5.1
Programmiersprachen und Programmentwicklung
Großen Zuspruch fanden ein neuer Fortran-Grundlagenkurs sowie die bereits etablierte Fortgeschrittenenveranstaltung, die jetzt als jeweils einwöchige Blockveranstaltung regelmäßig durchgeführt werden.
In Zusammenarbeit mit dem RRZE fand eine einwöchige Einführung in die wissenschaftliche Programmierung mit C++ statt. Für die inzwischen auch zunehmend im wissenschaftlichen Bereich genutzte Entwicklungsumgebung „Eclipse“ gab es eine eintägige Veranstaltung, die in Zukunft durch eine Einführung
in die Nutzung dieser Software im Bereich des parallelen Programmierens (Eclipse PTP) ergänzt werden
soll. Die Integration von Parallelität in klassischen Programmiersprachen im Rahmen des „Partitioned
76
Global Address Space“ (PGAS) Konzeptes wurde in einer eintägigen Veranstaltung mit den Themen
coarray Fortran (CAF) und unified parallel C (UPC) behandelt. Der Kurs „Eclipse: C/C++ programming
(with a slight Fortran touch)“ vermittelte sowohl erste Schritte in Eclipse für C, C++ und FORTRAN als
auch im Grid computing, denn in den Übungen wurden Grid Zertifikate (SLCS) und Grid middleware
(gsissh-Term mit VNC für remote visualization) für den Zugang verwendet.
2.4.5.2
Parallelisierung und Optimierung
Der traditionell jährlich stattfindende Workshop zum parallelen Programmieren und Optimieren (abwechselnd in München und Erlangen) wurden neu strukturiert, und fortgeschrittene Themen wurden in eine
separate Veranstaltung ausgegliedert. Sehr gut besucht war der in Zusammenarbeit von HLRS sowie den
Universitäten Kassel und Lübeck am LRZ durchgeführte Workshop zur Programmierung mit MPI,
OpenMP und parallelen Bibliotheken sowie angewandter linearer Algebra für iterative Verfahren. Etliche
Veranstaltungen wurden auch in Zusammenarbeit mit Firmen durchgeführt, beispielsweise mit Intel eine
Schulung zu Multicore und zum neuen parallelen Programmiermodell „Array Building Blocks“. Außerdem fand eine Reihe von eintägigen Veranstaltungen mit Fokus auf spezielle Tools zur PerformanceAnalyse und zu Debugging statt; dies erfolgte in Zusammenarbeit mit den Tool-Entwicklern aus dem
Forschungszentrum Jülich bzw. der Firma Allinea. Das wachsende Interesse an der Nutzung von Graphikkarten zur Beschleunigung von Algorithmen kam in einer hohen Teilnehmerzahl bei einer Veranstaltung zum Thema GPGPU („General Purpose Graphics Processing Unit“) zum Ausdruck.
2.4.5.3
Fluid-Dynamik
Die Community der CFD-Anwender um das Open-Source-Programm OpenFOAM hat sich auf einer vom
LRZ organisierten Veranstaltung getroffen und ihre Projekte vorgestellt. OpenFOAM entwickelt sich
immer mehr zu einer wichtigen Applikation am LRZ und es werden vom LRZ Anstrengungen unternommen, diese Applikation auf neuartige Architekturen zu portieren.
2.4.5.4
Life Sciences und Visualisierung
In Kursen zu Molecular Modelling gab es eine Einführung in die Simulation von Molekülen mit unterschiedlichen Software-Paketen auf dem Supercomputer am LRZ (Maestro, Desmond, VMD, NAMD,
Gromacs). Dies beinhaltete auch eine Einführung in die Remote Visualisation Services am LRZ; außerdem werden Hands-on Sessions mit Beispielanwendungen gegeben. Der Kurs konzentrierte sich auf Biomoleküle und Ziele der Life-Science-Community. Eine weitere Veranstaltung gab es zum parallelen Programmieren und Visualisierung mit der statistischen Programmierumgebung R. Im Kurs "Wissenschaftliche 3D-Animation mit Blender" lernten die Kursteilnehmer, selbst hochwertige Filme zur Darstellung
ihrer wissenschaftlichen Arbeit zu erstellen. Weiter zu erwähnen sind: Eine allgemeine Einführung in die
Nutzung der Cluster- und Visualisierungssysteme am LRZ sowie die Behandlung spezieller Themen aus
dem Bereich Visualisierung in Zusammenarbeit mit dem Rechenzentrum der Max-Planck-Gesellschaft.
2.5
Öffentlichkeitsarbeit
2.5.1 Supercomputing Konferenzen in Hamburg und New Orleans
Für den Auftritt auf den Supercomputing-Konferenzen ISC10 in Hamburg und SC10 in New Orleans
wurde ein neuer Messestand entworfen, dessen herausragende Neuerung ein geteiltes Display mit vier
großen HD-Monitoren darstellt. Das Display wird mit Informationen, Filmen, Animation oder Simulationen beschickt, die alle Bereiche des LRZ vorstellen und zudem einen Ausblick auf den Neubau und den
SuperMUC bietet. Und natürlich führt auch wieder Frankie (eine vom LRZ für Schulungszwecke weiterentwickelte virtuelle Figur) durch das LRZ, dabei wird auf dem Display auch ein virtuelles 3DLaboratorium gezeigt, durch das sich Messebesucher frei bewegen können. In der virtuellen Welt werden
die verschiedenen Anwendungsgebiete des Höchstleistungsrechnens anschaulich gezeigt. Auf den Messeveranstaltungen in Hamburg und New Orleans zeigte das LRZ auch Live-Demonstrationen aus dem
Bereich der Molekularen Simulation zu Remote Visualisation und Computational Steering mit einem
Force-Feedback System, das aus Komponenten zusammengestellt wurde, die quer über den Atlantik verbunden waren. Das Force-Feedback-System vermittelt dem Anwender einen Eindruck von Kräften, z.B.
77
innerhalb von Molekülen oder mechanischen Strukturen. Als Rechenserver wurde der HLRB II benutzt,
die Remote Visualisierung wurde im GVS-Cluster des LRZ berechnet und die 3D-Displayausgabe und
die Force-Feedback-Steuerung konnte in New Orleans am Messestand interaktiv von den Messebesuchern bedient werden.
2.5.2 Wissenschaft im Dialog/Tag der offenen Tür
Am Tag der Offenen Tür wurde die im Haus entwickelte 3D-Präsentation "Frankie goes to LRZ", die
schon auf der Ars Electronica in Linz 2009 gezeigt wurde, erheblich erweitert und auf der mobilen 3DStereo-Projektionsanlage des LRZ vorgeführt. Frankie ist ein kleines „elektronisches Flughörnchen“, das
in einer simulierten Welt verschiedene virtuelle Orte besucht, an denen Aktivitäten und Ergebnisse am
LRZ, wie zum Beispiel Molekülsimulationen, in unterhaltsamer Weise dargestellt werden. Ein Schülerpraktikant hat diese Simulation noch um Einsichten in den Rechnerwürfel und um ein virtuelles Labor
erweitern können. Die Resonanz beim Publikum war hervorragend, was sich auch in einer Veröffentlichung in der Zeitschrift "Aviso" des Bayerischen Staatministeriums für Wissenschaft und Kunst niedergeschlagen hat. In diesem Zusammenhang ist auch der Vortrag bei der Vortragsreihe der Sprecher der
BAdW zu nennen: „Was Wissenschaftler aus Computerspielen machen (können)“.
2.5.3 Berichtsband
Viel Arbeit erforderte die redaktionelle Fertigstellung,
die drucktechnische Aufbereitung und Veröffentlichung
des 780-seitigen Berichtsbandes "High Performance
Computing in Science and Engineering" der die Ergebnisse des Ende 2009 durchgeführten "HLRB and KONWIHR Review Workshops" darstellt:
S. Wagner, M. Steinmetz, A. Bode, M. M. Müller (Editors): "High Performance Computing in Science and
Engineering, Garching/Munich 2009", Transactions of
the Fourth Joint HLRB and KONWIHR Review and
Results Workshop 780 p., Hardcover, ISBN 978-3-64213871-3, 2010.
Dieses Buch stellt ausgewählte Ergebnisse dar, die am
gegenwärtigen Höchstleistungsrechner in Bayern erzielt
wurden. Die abgedeckten Forschungsbereiche umfassen
die Bereiche Informatik, Fluiddynamik, Astrophysik,
Hochenergiephysik, Geo-Wissenschaften, Festkörperphysik, Chemie und Biowissenschaften. Das Buch liefert
einen Überblick über das breite Anwendungsspektrum
von Problemen, die eine Nutzung von Höchstleistungsrechnern erfordern. Jede Projektbeschreibung umfasst
Informationen über den jeweiligen wissenschaftlichen
Hintergrund, die erzielten Resultate und die eingesetzt
numerischen Methoden. Das Buch bietet auch Einblicke
in die erreichte Rechenleistung, in die Skalierbarkeit der
Anwendungen und welche Verbesserungen bei den eingesetzten Algorithmen erreicht werden konnten.
2.5.4 InSiDe und Quartl
InSiDe (Innovatives Supercomputing in Deutschland) ist die Zeitschrift des Gauss Centre for Supercomputing (GCS). Das LRZ hat zu den beiden Heften des Jahrgangs Nutzerartikel, Projekt- und Systembeschreibungen beigetragen. Die Zeitschrift wird an zahlreiche Institutionen und Personen, sowie die Nutzer
der Höchstleistungsrechner verschickt. Ferner wurden Beträge für das Quartl, das Mitteilungsblatt von
KONWIHR und der Bavarian Graduate School of Computational Engineering (BGCE) verfasst.
78
Online-Ausgaben sind verfügbar unter: http://inside.hlrs.de/htm/editions.htm bzw.
http://www5.in.tum.de/wiki/index.php/Quartl
2.5.5 Sonstige Aktivitäten im Umfeld des Hochleistungsrechnens
19.01.2010
Besuch einer chinesischen Delegation
20.01.2010
DGI Monitoring Task Force
26.01.2010
Besuch einer Delegation der Universität Innsbruck
03.02.2010
Microsoft Uni Roadshow 2010
10.02.2010
DEISA WP 3,4,6,8 All Hands Meeting
19.02.2010
GSCS Meeting in Bonn zu Öffentlichkeitsarbeit
24.02.2010
Vortrag Prof Wettig Regensburg: QPACE - A massively parall supercomputer based
on Power XCell 8i processors and network FPGAs
01.03.2010 02.03.2010
PRACE Prototype and Language Workshop
03.03.2010
Stratos-Treffen
12.03.2010
Führung durch Rechnergebäude für Verband Deutscher Ingenieurinnen
19.03.2010
NGI-DE Meeting
22.04.2010
Girls‘ Day 2010
05.05.2010
Prospect Management Board Meeting
17.05.2010 18.05.2010
DRIHM (Distributed Research Infrastructure for HydroMeteorology) Workshop
31.05.2010 03.06.2010
International Supercomputing Conference 2010, Hamburg
Informationsstand
07.06.2010
Besuch Minoru Nomura, Affiliated Fellow, Science and Technology Foresight Center
(STFC), National Institute of Science and Technology Policy (NISTEP), Mnistry of
Education, Culture, Sports, Science and Technology, Japan.
29.06.2010 –
30.06.2010
DEISA Review Rehearsal
01.07.2010
Brooking Institut, President Metropolitan, Policy Program Bruce Katz,
Washington DC
12.07.2010
KONWIHR Review Workshop
16.07.2010
Besuch einer Delegation Huawei Research Unit, China
30.07.2010
OpenFoam Anwendertreffen
02.08.2010 04.08.2010
DRIHM Proposal Meeting
30.08.2010 31.08.2010
PRACE 1IP Kickoff-Meeting
27.09.2010 28.09.2010
DGSI" (D-Grid Scheduler Interoperability) Plenar Meeting
08.10.2010
Dr. Kusnezov, National Security Science and Technology, Washington DC
08.10.2010
Besuch einer Delegation der University of Aizu, Japan
13.10.2010
PROSPECT e.V. Mitgliederversammlung
14.10.2010
Exascale Meeting
18.10.2010
Richtfest Gebäudeerweiterung (Minister Herrmann)
18.10.2010 19.10.2010
IGE Kickoff Meeting
25.10.2010
Besuch des Russischen Staatsministers für Kommunikation und Massenmedien Igor
Shchegolev
08.11.2010
Besuch einer irakischen Delegation
13.11.2010 19.11.2010
Supercomputing 2010 Conference New Orleans
Informationsstand, Tutorial: Introduction to PGAS (UPC and CAF) and Hybrid for
Multicore Programming (R.Bader)
06.12.2010 08.12.2010
Besuch einer chinesischen Delegation
07.12.2010
Besuch des European Institute for Urban Affairs (Prof. Evans Liverpool)
07.12.2010
Stratos Management Board Meeting & General Assembly
13.12.2010
Unterzeichnung SuperMUC Vertrag und Pressekonferenz
2.6
79
Projekte und Kooperationen
2.6.1 PRACE
Innerhalb des PRACE Software-Arbeitspakets widmete sich das LRZ vorrangig der Evaluierung der Performance und Produktivität paralleler Programmiersprachen. Die Untersuchungsergebnisse zu RapidMind
wurden in einem Artikel veröffentlicht, die umfassende Produktivitätsstudie zu zwölf Programmiersprachen wurde als wissenschaftliches Poster auf der ISC10 angenommen. Frau Christadler stellte die Ergebnisse der Studie in mehreren Vorträgen vor, unter anderem bei der Internationalen SupercomputingKonferenz in Hamburg ("PRACE: Open Dialog with European Tier-0 Users").
Zum Thema "New Languages & Future Technology Prototypes" lud das LRZ Anfang März mehr als 60
Teilnehmer zu einem PRACE Workshop ein. Das Booklet des Events fasst alle Vorträge zusammen. Im
August waren dann mehr als 120 PRACE Mitarbeiter aus 20 verschiedenen Nationen am LRZ zu Gast,
als die PRACE First Implementation Phase (das EU-Projekt PRACE-1IP) gestartet wurde. Auch hier
übernimmt das LRZ wieder die Leitung des "Future Technology“ Arbeitspakets; außerdem zeichnet es
verantwortlich für die Koordinierung der Subtasks zum Thema "Programming Techniques for High Performance Applications".
80
Unter Leitung des LRZ lud die PRACE advisory group for Strategic Technologies (STRATOS) auf der
ISC10 in Hamburg 15 HPC-Technologiefirmen ein, PRACE eine Aktualisierung der entsprechenden
Produktroadmaps zu geben. Diese Informationen dienen unter anderem als Grundlage für die im PRACE1IP-Projekt zu definierenden HPC-Technologieprototypen. STRATOS war außerdem aktiv an der Organisation des 2. European Workshop on Supercomputing Centre Infrastructure im Oktober 2010 in
Dourdan, Frankreich beteiligt. In dieser Veranstaltung wurden den eingeladenen Vertretern von europäischen HPC-Zentren die aktuellen Entwicklungen zur Steigerung der Energie- und Kühlungseffizienz von
Rechenzentren aufgezeigt. Im Rahmen eines Vortrages stellte Herbert Huber den LRZ-Erweiterungsbau
sowie die Arbeiten des LRZ zur Steigerung der Kühlungseffizienz und deren geplante Umsetzung im
Erweiterungsbau vor.
Arndt Bode ist der deutsche Vertreter im PRACE Council, dem Leitungsgremium von PRACE.
2.6.2 DEISA2
LRZ-Mitarbeiter nahmen an DEISA2 Technical Meetings in Amsterdam, Barcelona, Bologna, Brüssel,
Helsinki, Paris und Stuttgart, an DEISA Training Sessions in London und Edinburgh, dem DEISA Symposium in Amsterdam, sowie an zahlreichen DEISA-Videokonferenzen teil und beteiligten sich aktiv an
Diskussionen in über 20 DEISA-Mailinglisten. DEISA2 läuft bis April 2011. Abbildung 39 zeigt die
Teilnehmer an diesem Projekt.
Abbildung 39: Teilnehmer am DEISA2 Projekt. Mit gestrichelten Linien sind die vier assoziierten Partner
CSCS (Schweiz), CCRT/CEA (Frankreich), KTH (Schweden) und JSCC (Russland) gekennzeichnet.
Quelle: http://www.deisa.eu/
Das LRZ beteiligt sich dabei insbesondere an den Service Activities „Technologies“, „Application Enabling“ und „Operations“ sowie einer Joint Research Activity „Integrated DEISA Development Environment“. Das LRZ betreibt für DEISA neben der Rechen-Ressource HLRB II auch deren Anbindung an das
dedizierte DEISA-Netzwerk, einen Client für das gemeinsame Dateisystem GPFS, die Middlewares Globus und UNICORE für den Benutzerzugang, sowie Dienste zur Benutzerverwaltung, Budgetierung, und
Funktionsüberwachung der Benutzerdienste.
Mit der zunehmenden Nutzung der DEISA-Infrastruktur spielt die Dienstgüte in DEISA eine immer größere Rolle. In 2010 wurden mehrere Maßnahmen unternommen, um dieser wachsenden Bedeutung ge-
81
recht zu werden. Um eine stärkere Kontrolle der Service-Qualität in der DEISA Infrastruktur zu gewährleisten und um sicherzustellen, dass auftretende Schwierigkeiten zeitnah gelöst werden, wurde ein Trouble Ticket-System verwendet. Im Rahmen der Verbesserung der Service-Qualität wurden DEISA-Dienste
(z.B. accounting, MyProxy, Unicore6) auf virtuelle Maschinen umgezogen und mit Hilfe des MonitoringTools Nagios überwacht.
Das Monitoring-Werkzeug Inca wird erfolgreich für die Versionsprüfung des DEISA Common Production Environment (DCPE), für die Funktionsüberwachung der Middleware sowie für die Konsistenzprüfung der Benutzerdaten eingesetzt. Die zentralen Inca-Komponenten werden für ganz DEISA am LRZ
betrieben. Zahlreiche Updates und Änderungen der Infrastruktur wurden durchgeführt. Dazu zählen die
Upgrades zu den neuesten Versionen, die Integration neuer DEISA Ressourcen, die Implementation einer
Schnittstelle zwischen Inca und dem DEISA Trouble Ticket System sowie die Weiterentwicklung von
Nutzungs- und Verfügbarkeitsreports. Inca führt regelmäßig mehr als 1.000 Tests auf 19 Ressourcen
durch. Um die DEISA Inca Infrastruktur stetig zu verbessen, wurden die Inca Reporter für die Überwachung des General Parallel File Systems (GPFS) in Produktion genommen. Um eine zeitnahe Behandlung
von Problemen und Änderungswünschen zu gewährleisten, pflegt das LRZ einen engen Kontakt mit dem
Inca Entwickler-Team am San Diego Supercomputing Center (SDSC).
Wie sich herausgestellt hat, ist eine frühzeitige Information von Administratoren und Benutzern über
zukünftige Dienstausfälle durch Wartungen, Anpassungen, Erweiterungen, etc. sehr wichtig. Nur so können die von diesen Diensten abhängigen Personen angemessen darauf reagieren und z.B. auf andere Systeme ausweichen. Zur Automatisierung dieser Informationsmechanismen erarbeitete die Arbeitsgruppe
DMOS, die vom LRZ geleitet wird, ein Konzept und begann mit der Implementierung des DMOS Systems. DMOS stellt ein einfach zu bedienendes graphisches Benutzerinterface zur Verfügung, das Benutzern aktuell in Wartung befindliche Systeme anzeigt und Administratoren einen einfachen update der
Wartungsinformationen erlaubt. Da DMOS im Hintergrund eine SQL Datenbank benutzt, können Wartungsdaten leicht importiert und zu anderen Systemen, wie z.B Inca, exportiert werden. Nach der Produktivführung von DMOS wird ein Adaptor für Inca entwickelt werden, sodass zukünftig Wartungen mit der
feinen Granularität des Services-Levels (bisher konnten nur ganze Systeme als „in Wartung“ angezeigt
werden) in Inca angekündigt werden können.
Das LRZ leitete die Untersuchung des neuesten Globus Releases GT5 auf seine Eignung zum Produktionseinsatz in DEISA. Das LRZ führte für DEISA-Benutzer Globus-Schulungen in Edinburgh und in
London durch. Außerdem beteiligt sich das LRZ an den Aktivitäten im Bereich von Remote Visualization, Cloud-Computing und Virtualisierung sowie zur Evaluierung von Monitoring-Tools. Viel zusätzliche
Funktionalität wurde in das PTP Framework eingebaut. Die in 2009 entdeckten Sicherheitslöcher konnten
geschlossen werden. Unterstützung für das DEISA Common Production Environment (DCPE) wurde
eingebaut; UNICORE und das Performance-Analyse tool Paraver wurden eingebunden und getestet.
Im Rahmen des WP9, „Enhancing Scalability“, wurde anhand des Quanten-Chromodynamic-Codes
BQCD die Skalierbarkeit und Performanz eines Hybrid-Codes untersucht. Dazu wurden mehrere DEISAMaschinen wie IBM BlueGene/P, CRAY und SGI Altix verwendet. Zusätzlich wurden in 2010 Beschleunigerkarten (GPGPUs) auf Ihre Eignung untersucht und mit den Ergebnissen vom Vorjahr verglichen, um
ihre Auswirkungen auf Perfomance und Skalierbarkeit zu verstehen.
Die Grid- und HPC-Enabling Arbeiten für die Projekte aus dem aktuellen DECI-6-Call werden erstmals
von allen DEISA Sites mit dem in 2009 vom LRZ entwickelten und in DEISA etablierten EnablingArbeitsablauf verfolgt und gemanagt. Die HPC-Applikationen der Projekte AirFloPS, CatTIO2, COSUF,
DiParTs, DNArecog, GlobUS, MeMGenA und PaRAdiSE wurden mit Home-Site LRZ in DEISA akzeptiert und vom LRZ betreut. Zusätzlich wurden für das Projekt DyBHo, mit Home-Site BSC und Execution-Site LRZ, die Portierungs- und Enablingarbeiten übernommen. Im Rahmen der DEISA Extreme
Computing Initiative (DECI) wurden 12 Projekte am LRZ betreut. Für den DECI-Call 2010 wurden über
das LRZ 11 Projekte eingereicht, von denen 8 akzeptiert und betreut wurden.
Die Koordinierung der führenden europäischen Höchstleistungsrechenzentren zur gemeinsamen Abwicklung der ehrgeizigen Ziele einer verteilten europäischen Höchstleistungs-Rechnerinfrastruktur erfordert
regelmäßige Management-Treffen des DEISA-Exekutivkomitees. Diese fanden als Telefonkonferenzen
statt.
82
2.6.3 PROSPECT e.V.
PROSPECT ist ein im Umfeld von PRACE gegründeter Verein zur Förderung des Höchstleistungsrechnens unter Einbeziehung von Wissenschaft, Wirtschaft und Herstellerfirmen. Der Verein wurde gemeinsam vom Barcelona Supercomputing Centre, dem Forschungszentrum Jülich und dem LRZ gegründet
und umfasst inzwischen europaweit über fünfzig institutionelle Mitglieder. Arndt Bode vertritt das LRZ
im Vorstand des Vereins.
Der Fokus der Arbeiten in PROSPECT lag im Berichtsjahr auf den Themen „European OFS“ und „European Technology Platform (ETP) for HPC“.
Für die Verbreitung und Weiterentwicklung von Open Source Dateisystemen in Europa (u. A. Lustre)
sowie die Berücksichtigung von speziellen Belangen europäischer Nutzer und Hersteller soll eine European Cooperative Society (SCE) for OFS gegründet werden. Das LRZ ist durch Herrn Biardzki im Lenkungsausschuss der geplanten "European OFS Cooperative SCE" vertreten.
Viel Engagement von PROSPECT e.V. Mitgliedern floss in strategische Überlegungen zur Gründung
einer ETP für HPC, welche zukünftig die Belange von europäischen HPC-Nutzern bei der EU entsprechend vertreten soll.
2.6.4 KONWIHR
2.6.4.1
OMI4papps
Im Rahmen des durch das Bayerische Staatsministerium für Wissenschaft, Forschung und Kunst geförderten Kompetenznetzwerkes für Hoch- und Höchstleistungsrechnen in Bayern (KONWIHR-II, Sprecher:
Arndt Bode) erfolgten am LRZ innerhalb des Projektes „OMI4papps: Optimierung, Modellierung und
Implementierung hoch skalierbarer Anwendungen“ folgende Aktivitäten:
• Analyse der Performance und Anwendbarkeit neuer Programmiersprachen/-paradigmen für
hochparallele Systeme
• Beurteilung von neuen Hardware-Architekturen, insbesondere von Beschleuniger-Systemen mit
CELL Prozessoren, Grafikkarten und Intels neuem Knights Ferry Chip
• Evaluierung der Entwicklungsumgebungen RapidMind, HMPP ("Hybrid Multicore Parallel Programming Workbench“) und des PGI Accelerator Compilers, die eine einfache Programmierung
von GPGPUs ermöglichen
• Beta-Test von Intels neuer datenparalleler Programmiersprache "Intel Array Building Blocks"
(ArBB)
• Arbeiten zur synthetischen Performance-Modellierung wissenschaftlicher Applikationen
• Erweiterung der Benchmarksuite des LRZ
• Erweiterung des Kursangebots des LRZ im Bereich neuer Programmiersprachen und GPGPUProgrammierung.
Im Juni fand der KONWIHR Review-Workshop statt, bei dem OMI4papps um ein weiteres Jahr verlängert werden konnte.
2.6.4.2
KONWIHR Software Initiative
Im Rahmen der KONWIHR Software Initiative wurden vom LRZ drei Projekte unterstützt. Ziele der
Initiative war es, neue Benutzer an das Hochleistungsrechnen heranzuführen. Das LRZ unterstützte die
Benutzer hierbei bei der parallelen Implementierung von Submodulen aus dem Bioconductor Paket für
verschiedene Architekturen wie SMP, MPP und GPGPU. Die Pakete umfassen Sequence Alignment
(global und lokal) und teilweise überlappendes Alignment von DNA- und Protein-Sequenzen. Ein weiteres Projekt beschäftigte sich mit der Implementierung von Entscheidungsbäumen auf verschiedenen parallelen Architekturen für genom-weite Studien. Das dritte Projekt erforschte die Implementierung von
Kreuz-Validierungs- und Normalisationsalgorithmen für hoch-dimensionale Micro-Array-Datensätze.
Hierbei wurden rechenintensive Klassifikationsalgorithmen auf mehrere hundert Prozessoren skaliert.
83
2.6.5 ISAR
Innerhalb des BMBF-Projektes ISAR (Integrierte System- und Anwendungsanalyse für massivparallele
Rechner) wurde durch das LRZ der Prototyp eines Monitoring-Tools (PerSyst Monitoring) installiert. Mit
dem Tool lassen sich Engpässe auf Systemebene, wie z. B. Jobs mit schlechter Performance, detektieren.
Für die Implementierung von PerSyst Monitoring wurden das Agentensystems, die Properties sowie die
Suchstrategien von Periscope (innerhalb von ISAR weiterentwickeltes automatisches LeistungsanalyseTool auf Anwenderebene der TUM) an die systemweite Leistungsanalyse angepasst. Wesentlich bei der
Implementierung war die Gewährleistung der weiteren Nutzung der von den Administratoren und Benutzern am LRZ eingesetzten Anwendungen, die auf den bisherigen Monitoring-Tools basieren. Für die Abspeicherung der gemessenen Daten sowie der berechneten Eigenschaften in einer MySQL-Datenbank
wurde vom LRZ adäquate Hardware bereitgestellt. Die graphische Darstellung der Ergebnisse realisiert
der GridMonitor der Firma ParTec, die ein Industriepartner innerhalb des ISAR-Projektes ist. Eine Vorstellung von PerSyst Monitoring erfolgte innerhalb des Status-Treffens der Gauß-Allianz „Competence in
High Performance Computing“ (CiHPC) in Schwetzingen (22.-24. Juli 2010).
2.6.6 EU Projekt Scalalife
Im März 2010 wurde der Antrag für das Projekt Scalalife im Rahmen des FP7 Calls der EU genehmigt.
Das Projekt soll die Grundlage für eine e-Infrastruktur im Bereich Life Science in der EU schaffen. Das
LRZ hat hierbei die Leadership-Rolle für ein Workpackage übernommen und wird Dienste entwickeln,
die anspruchsvolle Hochdurchsatzrechnungen von numerischen Simulationen auf europäischer Ebene
ermöglichen. Speziell ist das LRZ für die Installation und die Validierung der Software zuständig und soll
Benutzer an Maschinen der Petaflop-Klassen heranführen. Das Projekt hat eine Laufzeit von drei Jahren.
2.6.7 Beteiligung an Workshops
Im Rahmen des Jülich Blue Gene/P Extreme Scaling Workshop 2010 (22.-24.3.) konnte ein Mitarbeiter
das komplette Blue Gene/P System für BQCD-Tests benutzen und hat erreicht, dass das Quantenchromodynamikprogramm BQCD auf 294.912 Cores skalierte.
Im Herbst 2010 wurde ein Projekt bei den "Grands Challenges CINES 2010" in Frankreich submittiert.
Im Rahmen von Benchmark-Läufen auf dem neuen dortigen ICE Rechner wurde das Projekt akzeptiert
und die Ergebnisse sind veröffentlicht („Combining MPI with OpenMP Parallelism in Large Scale QCD
Simulations“).
Auf einem Workshop in Leogang/Österreich zum Thema "Understanding the Parallel Behavior of Modern Parallel CFD Applications" berichtete das LRZ über die Analyse des Skalierungsverhaltens und über
eine Verbesserung des Mehrgitterverfahrens in OpenFOAM, einer modernen und weit verbreiteten Open
Source CFD Anwendung.
Zusammen mit den Jülicher Kollegen wurde im Frühjahr der „5th VI-HPS Tuning Workshop” organisiert; Thema des Workshops waren Tools zur Skalierungs- und Parallelisierungsanalyse, wie Scalasca,
VampirNG und Marmot.
2.7
Tätigkeiten im Server-Betrieb
Der Hauptanteil der Tätigkeiten im Bereich der Server-Dienste beruhte auch im Jahr 2010 auf der Aufrechterhaltung eines stabilen Betriebs. Trotz steigender Serverzahlen sind auch in diesem Jahr keine nennenswerten Dienstunterbrechungen zu vermelden.
2.7.1 Linux-Serversysteme
Zur Aufrechterhaltung eines stabilen Betriebs von Linux-Systemen bewährt sich nach wie vor der für das
Leibniz-Rechenzentrum entwickelte Software-Installations- und Update-Mechanismus. Die Eigenentwicklung bietet den Vorteil, zeitnah auf individuelle Anforderungen reagieren zu können. Gerade im Bereich der Linux-Server gleicht kaum eine Installation der anderen.
84
Tagtäglich geschehen dynamische Veränderungen der LRZ-Dienste. Parallel dazu sind zum Betrieb aktueller Dienstsoftware Upgrades auf neuere Betriebssysteme notwendig. Wenn ältere Versionen nicht mehr
vom Distributor unterstützt werden, betrifft der Betriebssystem-Upgrade zahlreiche Server.
Die zugrunde liegende physische Hardware besteht aus verschiedensten Servermodellen. Deren Vielfalt
ergibt sich nicht nur durch unterschiedliche Ansprüche beim Einkauf, sondern auch aufgrund Überlappung der jeweiligen Nutzungsdauer, teils über vier Generationen, d.h. Beschaffungsphasen hinweg.
Erst durch die in 2009 erfolgte Beschaffung von Server-Blades als Grundlage für den VirtualisierungsCluster, der ab Mitte 2010 in Produktionsbetrieb übergeführt wird, entsteht ein gewisses Maß an Homogenisierung. Somit existieren Administrationsvorteile analog zu den Pools gleicher Hardware im Bereich
des Linux-Clusters, des HLRB II oder z.B. der Linux-Desktops bei den Mitarbeiter-Arbeitsplätzen.
Die Zeitvorteile durch Homogenisierung werden allerdings bei gleichbleibendem Personalstand durch die
rapide steigenden Zuwachszahlen an Linux-Servern nicht nur egalisiert, sondern ins Gegenteil verschoben. Das Jahr 2010 ist deshalb geprägt von der Planung und teilweisen Einführung notwendiger Prozesse
zur Inbetriebnahme und Verwaltung von Linux-Servern und der Konkretisierung des sog. Dienstleistungskatalogs inklusive Aufstellung einer Verhaltensrichtlinie (Policy) für Linux-Nutzer.
Ein wichtiges Beispiel ist die, bereits Ende 2009 angekündigte Einführung automatischer Linux-KernelUpdates. Letztere ziehen einen Server-Reboot und somit eine zumindest kurzzeitige Dienstunterbrechung
nach sich. Auf Wunsch kann eine Vorwarnzeit (in Tagen) eingerichtet werden.
Seit 1. Juni 2010 liegt die Verantwortung beim Dienstadministrator, wenn Kernel-Updates ausgesetzt
werden sollen. Eine individuelle Absprache zwischen Dienst- und Systemadministrator, die zuvor für
jeden einzelnen Server getroffen werden musste, entfällt. Zur Dokumentation dient das Webinterface des
LRZmonitor. In gewohnter Weise lassen sich sämtliche Routinen – auch für den Kernel-Update – halbautomatisch, d.h. bequem durch manuellen Aufruf starten.
Parallel zum Ausbau der virtuellen Infrastruktur bleibt ein gewisser Grundbedarf an physischer Hardware
erhalten. Hierzu zählen z.B. Dienste, die die virtuelle Umgebung managen, deren Aufstellungsort abseits
der virtuellen Infrastruktur liegt, die einen hohen Anspruch auf Autonomie besitzen oder eine hohe Bandbreite benötigen.
Aus den genannten Gründen wurden im Dezember 2010 insgesamt 18 Server von der Fa. DELL eingekauft. Neben 2 Modellen mit der Bezeichnung DELL PowerEdge R710 (2 HE), geplant als OracleDatenbank-Server, wurden 16 Modelle mit der Bezeichnung DELL PowerEdge R610 (1 HE) beschafft.
Mit einer Ausnahme von 96 GByte RAM für den LRZ-Accounting-Dienst, sind alle übrigen Server mit
24 GByte RAM bestückt. Während für die R710-Modelle aus Oracle-Lizenz-Gründen nur eine CPU verbaut ist, besitzen alle anderen Server jeweils zwei 6-Core-CPUs von Intel. Mit aktiviertem Hyperthreading ergeben sich somit 24-fach SMP-Systeme.
Das Einsatzgebiet der neuen R610-Server ist die Auslagerung als DNS- und DHCP-Server zur TUM und
LMU in die Innenstadt, sowie die Verbringung nach Weihenstephan. Weitere zwei Server werden aus
Homogenitätsgründen für DNS-/DHCP und als Testmaschine LRZ-intern genutzt.
Sieben R610-Server (Accounting, Secomat, Snort-IDS usw.) dienen dem künftigen Netzmonitoring und
besitzen deshalb eine zusätzlich eingebaute Karte mit 10-GbE-Dual-Ports für LC-Verkabelung. Zwei
R610-Server unterstützen die VoIP-Telefonanlage, zwei sind als zentrale Basis für das künftige LRZMonitoring eingeplant.
2.7.1.1
Virtualisierung am LRZ
Die stetige Virtualisierung physischer Systeme setzte sich auch im Jahr 2010 fort. Gegen Ende des Jahres
bestand noch für etwa 76 physische Server mit Betriebssystem SuSE-Linux Virtualisierungspotential.
Hauptgruppe
SGI Altix
Linux-Cluster
Grid Server
HSS Server
BSB + BVB Server
Server
Basisdienste
Kurs-Cluster
MitarbeiterArbeitsplätze
85
Untergruppe
Hlrb2
Div
Ice
Lx64a
Lx64e
Lx64i
Lx64s
Lxe
Lxlcg
Lcg
Grid
Hss
Bsb
Bvb
Misc
Net
Mail
Web
Sql
Edir
Dat
Cons
Gmm
Ext
Kurs
Beschreibung
Höchstleistungsrechner
HLR-Test- u. Spezialsysteme
ICE-Testsystem
Opteron-Clusterknoten
EM64T-Clusterknoten
Itanium-Clusterknoten
Cluster-Management
LMU Physik-Cluster
LCG-Server-Blades
LCG-Manage- u. DCache-Knoten
Grid-Dienste
Hochschulstart.DE-Dienst
BSB-Dienste
BVB-Dienste
Verschiedene Dienste
Netzdienste
Mail-Server
Web-Server
Datenbank-Server
e-Directory-Dienste
Daten- und Archiv-Dienste
Konsol- und Leitwartenserver
Grafik- und Multimedia-Dienste
Server-Hosting
Kurs-Clusterknoten
User
Büro- und Telearbeitsplätze
Gesamtanteile
Virtualisierungsanteil
7%
2/27 ≈
0%
0/6 ≈
0%
0/66 ≈
0%
0/360 ≈
0%
0/345 ≈
0%
0/3 ≈
75%
28/37 ≈
7%
1/14 ≈
0%
0/27 ≈
17%
12/67 ≈
92%
60/65 ≈
90%
77/85 ≈
46%
30/65 ≈
22/22 ≈ 100%
72%
48/66 ≈
36%
20/55 ≈
48%
17/35 ≈
41%
21/51 ≈
77%
14/18 ≈
85%
53/62 ≈
12%
10/83 ≈
3%
1/33 ≈
22%
4/18 ≈
68%
17/25 ≈
57%
12/21 ≈
Erreichte
Zielsetzung
2/2 ≈ 100%
28/28 ≈ 100%
1/1 ≈ 100%
12/12 ≈ 100%
92%
60/65 ≈
77/77 ≈ 100%
30/30 ≈ 100%
22/22 ≈ 100%
94%
48/51 ≈
86%
20/23 ≈
48%
17/35 ≈
44%
21/47 ≈
14/14 ≈ 100%
85%
53/62 ≈
10/10 ≈ 100%
1/1 ≈ 100%
50%
4/8 ≈
68%
17/25 ≈
12/12 ≈ 100%
4%
4/4 ≈ 100%
4/91 ≈
453/1747 ≈
26% 453/529 ≈
86%
Tabelle 28: Anteil virtueller gegenüber physischer Linux-Systeme Ende 2010
Nachdem im Vorjahr mit der Beschaffung einer größeren Infrastruktur der Grundstein für Virtualisierung
am LRZ gelegt worden war, stand im Jahr 2010 das Thema Hosting virtueller Maschinen im Vordergrund. Ziel des Vorhabens ist es, neben der Virtualisierung von LRZ-internen Systemen, die bereits zu
massiven Einsparungen an physischen Servern führte, auch anderen Großnutzern die Möglichkeit zu geben, virtuelle Maschinen gegen Gebühr in der „LRZ-Cloud“ zu betreiben. Unter diesem Aspekt wurde
das vorhandene VMware-Cluster von 32 auf nunmehr 64 Knoten verdoppelt, so dass mittlerweile 4,6 TB
Hauptspeicher und 512 Rechenkerne für Virtualisierungsprojekte zur Verfügung stehen. Mit dem Projekt
„Hochschulstart.de“ konnte ein weiterer großer Kunde für den Virtualisierungsdienst gewonnen werden
und ein zusätzliches, separiertes Cluster mit 28 Systemen aufgebaut werden. Aktuell betreibt das LRZ auf
diesen Clustern bereits über 800 VMs – Tendenz stark steigend.
Neben den Erweiterungen der Hardware, die schon allein aufgrund der hohen LRZ-internen Virtualisierungsquote notwendig wurde, lag der Focus im Jahre 2010 auf dem Design von Prozessen zum Betrieb
des geplanten Hosting-Szenarios sowie ersten prototypischen Implementierungen eines Webshops und
eines automatisierten Verfahrens zur Bereitstellung von bestellten virtuellen Maschinen. Der Webshop
wurde von Mitgliedern der ITSM- und Virtualisierungs-Gruppen des LRZ in Zusammenarbeit mit iET
Solutions geplant und wird zurzeit von iET Solutions, dem Hersteller der im letzten Jahr erworbenen
ITSM-Suite, implementiert. Dieses Projekt erweist sich aufgrund der noch nicht implementierten CMDB
(Konfigurations-Management-Datenbank) sowie diversen Designeinschränkungen seitens der ITSM Suite
als etwas kompliziert und langwierig, so dass mit funktionalen Ergebnissen frühestens im ersten Quartal
2011 gerechnet werden kann. Gut voran kam hingegen ein selbst entwickelter Algorithmus zur automatischen Provisionierung von virtuellen Maschinen. Der Algorithmus ermöglicht es, bestellte virtuelle Maschinen aus einer Datenbank abzufragen, eine entsprechende virtuelle Maschine nach den Vorgaben des
Bestellers auf dem Cluster zu instanziieren und diese durch ein ebenfalls vollautomatisiertes Installationsverfahren mit einem gewünschten Betriebssystem zu versehen. Zu einem funktionierenden Gesamtsystem, das als Dienst des LRZs nach den Vorgaben des ISO/IEC 20000 Standards betrieben werden soll,
fehlt jedoch noch die endgültige Anbindung an die CMDB, welche zu diesem Zweck momentan um diverse Funktionalitäten wie etwa IP-Adressverwaltung und den genannten Webshop erweitert wird.
86
Zwei weitere Aspekte, die im laufenden Jahr fast zwangsläufig im Kontext des Hostingprojekts behandelt
werden mussten, sind die Themen Monitoring und Security. Da die Verfügbarkeit einer virtualisierten
Umgebung aufgrund der vielen involvierten Subdienste, wie zum Beispiel physische Server, Netz und
Storage, neben der eigentlichen Virtualisierungsschicht auch stark von diesen Komponenten abhängt,
wird ein Dienste-übergreifendes Monitoring notwendig, welches aktuell im Rahmen von zwei Bachelorarbeiten implementiert wird. Weiterhin wurden neue Firewall-Lösungen für virtualisierte Infrastrukturen
evaluiert, um die gehosteten Maschinen zuverlässig voneinander isolieren zu können sowie ein erstes
Konzept zur Realisierung eines sicheren und mandantenfähigen Management-Portals im Web erarbeitet.
Abbildung 40: Entwicklung und Nutzung der LRZ-Virtualisierungsumgebung
2.7.1.2
PCs unter Linux als Mitarbeiter-Arbeitsplätze
Im Bereich der Mitarbeiter-Arbeitsplätze gab es 2010 wenige Änderungen. Ab April 2010 fand der Upgrade des verwendeten Betriebssystems „Novell/SuSE Linux Enterprise Desktop“ von Version 10 ServicePack 2 auf ServicePack 3, kurz bezeichnet als „SLED-10.3“, statt.
Ende 2010 wurde wegen zu hektischer Upgrade Zyklen der Umstieg auf die neueste Version „openSUSE
11.3“ vorbereitet. Ende Dezember begann die Verteilung der neuen OpenSource-Software auf die Mitarbeiter-Arbeitsplätze.
Neben der Softwareumstellung werden sukzessive veraltete PCs der Modellreihe „DELL OptiPlex
GX620“ durch neue „DELL OptiPlex 980“ ersetzt, von denen Mitte 2010 insgesamt 25 Stück für den
Einsatz als Linux-Arbeitsplatz beschafft wurden.
2.7.1.3
87
Zuwachs von Linux-Hosts im Leibniz-Rechenzentrum
1800
1700
SGI Altix
1600
Linux-Cluster
1500
Mitarbeiter-Arbeitsplätze
Kurs-Cluster
1400
BSB + BVB Server
1300
Grid Server
1200
HSS Server
1100
Server Basisdienste
1000
Virtuelle Hosts
900
800
700
600
500
400
300
200
100
0
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
Abbildung 41: Anzahl der Linux-Hosts im Leibniz-Rechenzentrum
2.7.1.4
Betriebsüberwachung
Im Bereich der Betriebsüberwachung gab es 2010 wenig nennenswerte Änderungen gegenüber dem Vorjahr. Erwähnenswert ist die Einführung eines weiteren sog. Überwachungssatelliten (siehe zur Begriffsklärung den Jahresbericht 2009) im Rahmen des Hochschulstart.DE-Projekts. Auf diesem kommt die
lizenzpflichtige Monitoring-Software „up.time“ zum Einsatz.
Im Herbst 2010 fand für mehrere Mitarbeiter eine hausinterne Schulung zur Bedienung von „Tivoli Netcool/OMNIbus“ statt. Die Umstellung von „HP OpenView“ auf „Tivoli Netcool/OMNIbus“ verzögert
sich aufgrund unerwartet hohen Personalaufwands zur Kundenbetreuung für das Linux-Server-Hosting.
2.8
Aktivitäten im Bereich „Verteilte Ressourcen“
Die Arbeiten im Bereich Grid-Computing erfordern ein breit gefächertes Know-how und werden deshalb
von den Abteilungen Kommunikationsnetze, Hochleistungssysteme und Benutzernahe Dienste und Systeme gemeinsam durchgeführt. Als abteilungsübergreifende Einrichtung war und ist der Arbeitskreis Grid
Computing (AK-Grid) maßgeblich an der Koordinierung der verschiedenen Grid-Projekte (D-Grid, DEISA-2, PRACE, LCG Tier-2, EGI, IGE, LRZ-Grid, Grid Aktivitäten an LMU und TUM) innerhalb des
LRZ und im Münchner Raum beteiligt, hilft Synergien auszunutzen und Doppelarbeit zu vermeiden. Darüber hinaus widmete sich der AK-Grid in 2010 verstärkt dem Thema „Cloud-Computing“.
Bis zu 10% der HLRB II-Rechenleistung sowie ein nicht unerheblicher Teil der Rechenleistung unseres
Linux Clusters werden über Grid-Middleware von den Wissenschaftlern in Deutschland und Europa abgerufen.
Das LRZ ist aktiv an den nationalen und internationalen Grid-Projekten „Initiative for Globus in Europe –
IGE“, „European Grid Initiative - Integrated Sustainable Pan-European Infrastructure for Researchers in
88
Europe – EGI-InSPIRE“, „Distributed European Infrastructure for Supercomputing Applications DEISA2“, „Partnership for Advanced Computing in Europe, 1st Implementation Phase - PRACE-1IP“,
den D-Grid-Projekten DGI2, SLA4D-Grid sowie DGSI, LHC-Grid (LCG) und „e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3)" beteiligt. Dabei hat das LRZ bei IGE erstmalig die Führungsrolle in einem europäischen Projekt übernommen.
Im Folgenden beleuchten wir einige der in den Grid-Projekten durchgeführten Arbeiten ausführlicher.
2.8.1 Initiative for Globus in Europe (IGE)
Die Gruppe VER initiierte 2010 das EU-Proposal „Initiative for Globus in Europe (IGE)“, um die Belange der europäischen Benutzer stärker in dieser führenden Grid-Middleware zu repräsentieren. Dazu integriert IGE zehn europäische Partner sowie die University of Chicago, die die zentrale Globus Codebasis
pflegt.
IGE will hauptsächlich koordinierend eingreifen und die europäischen Wünsche bündeln und abstimmen,
um sie dann mit einer gewichtigen Stimme gegenüber den anderen Globus-Entwicklern vorzutragen.
Durch IGE soll Globus, das sich in Europa einer breiten Benutzerschaft erfreut, bisher aber keine europäische Lobby hatte, in die europäischen Grid-Projekte, allen voran die European Grid Initiative (EGI), getragen werden. Durch Zentralisierung von Funktionen wie Test, Zertifizierung, Training, Support, etc.,
bei IGE kann Europa durch Synergieeffekte den Aufwand verringern und den Service für die Benutzer
verbessern.
Die wichtigsten Ziele des Projekts sind:
• Koordination europäischer Globus Aktivitäten
• Europäischen Input gebündelt an die Globus Alliance liefern
• Für Europa wichtige Erweiterungen sollen in den Globus Quellcode einfliessen
• Adaptoren für in Europa häufig benutzte Stapelverarbeitungssysteme wie LL, NQS2, ... bereitstellen
• Als Globus-Dienstleister für europäischen Grids wie DEISA, PRACE und EGI arbeiten
• Die Softwarequalität der Globus Middleware beurteilen
• Verbesserung von Standardisierung, Training und Dokumentation von Globus
• Ausrichten der Globus Europe Konferenz und des europäischen Globus Community Forums
• Bereitstellung eines Spiegelservers für globus.org in Europa zur Redundanzerhöhung
• Aufsetzen eines europäischen Globus metrics, um den strengen europäischen Datenschutzrichtlinien zu genügen
• Unterstützung für Interoperabilität von Grid Middleware (BES, SAML, JSDL, LCAS, etc.)
• Bereitstellung einer Web-Präsenz: http://www.ige-project.eu/
• Erstellen binärer Distributionen für die in Europa wichtigen Betriebssysteme AIX, SuSE,
Debian, Fedora, etc.
Die „Initiative for Globus in Europe – IGE“, begann offiziell am 1. Oktober 2010 und startete kurz darauf
mit einem Kick-Off Treffen am LRZ. Sie stellt für das internationale Globus Projekt den Brückenkopf in
Europa dar. IGE liefert die Globus Middleware für die europäischen Grid Infrastrukturen wie EGI, DEISA, PRACE, etc., und bietet neben Benutzerunterstützung und Training auch Anpassungen von Globus
an europäische Bedürfnisse an. Dieses Projekt stärkt die Rolle Europas und natürlich auch des LRZ in
Globus, dem weltweit führenden Middleware-Projekt.
Auf der jährlich stattfindenden GridKa Summer School in Karlsruhe wurde das vom LRZ im Rahmen
von IGE organisierte Globus-Training zum besten Training gewählt.
2.8.2 D-Grid:
Förderung „e-Science und vernetztes Wissensmanagement“ des BMBF
Im Rahmen von D-Grid nahm das LRZ 2010 an vielen Workshops und Treffen teil. In den kommenden
Jahren wird das D-Grid Teil eines größeren, europäischen Verbunds, der European Grid Initiative (EGI) dort vertreten durch NGI-DE (National Grid Initiative - Deutschland).
2.8.2.1
89
D-Grid Integrationsprojekt (DGI)
Als Rechenzentrum, und damit als Ressourcenanbieter, war das LRZ vorrangig am sogenannten D-Grid
Integrationsprojekt (DGI, Laufzeit Jan. 2008 bis Dez. 2010) beteiligt. Aufgrund langjähriger guter Kontakte zu HPC-Benutzern aus Astro- und Hochenergiephysik trat das LRZ aber auch als assoziierter Partner der Astrophysik- und der Hochenergiephysik-Community auf und beteiligte sich an deren Arbeitstreffen. Außerdem ist zur Vertretung der Globus-Ressourcen-Anbieter ein Mitarbeiter des LRZ im Technical
Advisory Board (TAB) des D-Grid vertreten.
Das LRZ stellt im verteilten Kompetenzzentrum Middleware (Fachgebiet 1) vielfältiges Know-how für
die Unterstützung von Benutzern und Ressourcenanbietern bezüglich Globus bereit. Auf den Produktionssystemen des LRZs wurde Globus von GT4.0.8 auf GT5.0 angehoben. Aufgrund der stürmischen
Entwicklung des Globus Toolkits wurde im D-Grid beschlossen, die Version GT4.2 zu überspringen und
direkt auf GT5 zu migrieren. Für einen Übergangszeitraum von 6 bis 12 Monaten sollen im D-Grid beide
Globus Versionen parallel betrieben werden, da sie nicht 100% kompatibel sind. Nach Ende der Übergangsphase soll dann vollständig auf GT5 migriert werden. Ein schwerwiegender Fehler in GT5, der
durch Tests des LRZs offensichtlich wurde, verzögerte jedoch die Einführung von GT5.
Im Rahmen des DGI-Fachgebiets 2-3 hat das LRZ Ressourcen für D-Grid angeschafft und betrieben und
zentrale Dienste bereitgestellt. Die im Rahmen der D-Grid-Sonderinvestitionen im Herbst 2008 angeschafften Serversysteme (zwei Serversysteme Sunfire X4600) zur Remote-Visualisierung sowie die dazu
notwendige Software (AVS, Amira/Avizo, IDL) wurden für das D-Grid betrieben. Das LRZ hat die Ressourcen, die im Rahmen früherer Sonderinvestitionen beschafft wurden, weiterbetrieben und für das DGrid verfügbar gemacht. Im Jahr 2010 wurden auf diesen Ressourcen fast 3,4 Mio. Jobs submittiert, die
ca. 5,8 Mio. CPUh verbraucht haben. Der Speicherplatz im dCache-Pool belief sich auf ca. 500 TByte.
Als zentrale Dienste für D-Grid hat das LRZ Grid-Monitoring mittels der Werkzeuge MDS, WebMDS,
GridCSM, D-MON und Inca sowie den zentralen MyProxy-Server zur Authentisierung der Nutzer betrieben. Es wurde intensiver Globus-Support für alle Communities, allen voran die Astro-Community, geleistet.
Da der Förderzeitraum für DGI-2 Ende 2010 endete, wurde im Herbst zusammen mit den NGI-DE Partnern ein Antrag für eine zwei-jährige Anschlussförderung beim BMBF eingereicht.
2.8.2.2
DGSI
Das D-Grid-Gap-Projekt „D-Grid Scheduler Interoperability“ (DGSI) konzipiert und entwickelt eine Interoperabilitätsschicht für Scheduling in Service Grids, die es Benutzern einer Community erlaubt, Arbeitslast auf Ressourcen einer anderen Community zu verlagern.
Im September 2010 richtete das LRZ ein All-Hands-Meeting von DGSI am LRZ aus. LRZ-Mitarbeiter
beteiligten sich an unzähligen Telefonkonferenzen und brachten den LRZ Standpunkt ein. Das LRZ ist als
Leiter von Task 4 für die „Anbindung lokaler Resource Management-Systeme“ verantwortlich. Im Rahmen dieses Tasks stetzte das LRZ ein Testbed mit GT4.0.8 und einer SGE Instanz auf. Es wurden Interfaces zu den in Task 3 entwickelten Komponenten implementiert, sodass nun eine einheitliche Verbindung auch zu verschiedenen Batch Systemen möglich ist. Das LRZ ist an insgesamt drei Arbeitspunkten
im Projekt beteiligt und hat an mehreren Projektberichten mitgearbeitet.
2.8.2.3
SLA4D-GRID
Das D-Grid-Projekt “Service Level Agreements for D-Grid” (SLA4D-GRID) entwirft und realisiert eine
Service Level Agreement-Schicht (SLA-Schicht) für das D-Grid. Diese Schicht zur Vereinbarung einer
festgelegten Dienstgüte bietet einzelnen Benutzern, ganzen D-Grid Communities, sowie den Anbietern
von D-Grid-Ressourcen die Gewährleistung der Ressourcennutzung unter wirtschaftlichen Bedingungen.
In 2010 gab es drei Projekttreffen, an denen sich auch das LRZ beteiligte; ein Treffen wurde vom LRZ
ausgerichtet und im Anschluss an die an der LMU stattfindende OGF-28 Konferenz in den Räumen der
LMU in München abgehalten. Das LRZ promotete D-MON, eine LRZ Eigenentwicklung im MonitoringBereich, und lieferte ein Konzeptpapier, das die mögliche Verwendung von D-MON in SLA4D-GRID
aufzeigt sowie Auswahlkriterien für ein Monitoringsystem bereitstellt. Vom LRZ wurde ein Testbed mit
sechs Servern aufgesetzt. Für Globus, UNICORE und gLite steht jeweils ein Server zur Verfügung. Gemeinsam für alle Middlewares gibt es einen Speicher-Server, einen Monitoring-Server und einen Batch-
90
Server. Die Installation des Speicher-Servers mit GridFTP erleichterten Installationspakete von IGE (siehe Abschnitt 2.8.1).
2.8.3 EGI-InSPIRE
Mit der Beteiligung an EGI-InSPIRE, das am 1. Mai startete, spielt das LRZ nun auch eine wesentliche
Rolle in der zweiten großen europäischen e-Infrastruktur: EGI. Zusammen mit der Beteiligung an
PRACE-1IP (ab 1.7. 2010) und DEISA2 fällt damit dem LRZ eine wichtige Funktion für die Integration
der Infrastrukturen zu, an der auch in 2010 mit Hochdruck gearbeitet wurde.
Im Projekt EGI-InSPIRE beteiligt sich das LRZ in den Arbeitspaketen zum Entwurf der notwendigen
Policies und zur Definition der Grid-Management-Infrastruktur auf europäischer Ebene. Es arbeitet mit
am verlässlichen Betrieb der Grid-Dienste, die von der deutschen Grid-Infrastruktur der EGI zur Verfügung gestellt werden. Darüber hinaus leistet das LRZ den europaweiten 2nd-Level-Support für das Globus
Toolkit im Rahmen der Deployed Middleware Support Unit (DMSU).
2.8.4 MAPPER
Das in 2010 neu gestartete EU-Projekt MAPPER (Multiscale Applications on European e-Infrastructures,
http://www.mapper-project.eu/) konzentriert sich darauf, die für die Forschung immer wichtiger werdenden multi-scale Systeme, die mehrere wissenschaftliche Gebiete (etwa Fluiddynamik, Strukturmechanik
und Chemie der Verbrennungsvorgänge) involvieren, effizient auf die europäischen Infrastrukturen wie
EGI und PRACE abzubilden. Diese multidisziplinären, multi-scale Systeme erfordern zu ihrer Simulation
höchste Rechenleistung. MAPPER wird Algorithmen, Software und Services für diese Unterfangen entwickeln und die besonderen Anforderungen (wie etwa advance reservation und co-scheduling) mit einer
gewichtigen Stimme in die Infrastrukturen hineintragen.
Das LRZ ist hier als Partner der LMU, einem der MAPPER-Partner, beteiligt und wird Hardware und
Software beisteuern sowie das Projekt umfassend unterstützen; so ist z.B. das MAPPER All Hands Meeting für 2011 am LRZ geplant.
2.8.5 e-Infrastructure Reflection Group Support Programme 3 (e-IRGSP3)
Die e-Infrastructure Reflection Group (e-IRG) ist ein Beratergremium der EU, das Empfehlungen zu Best
Practices für europäische e-Infrastrukturen ausspricht. Das Gremium setzt sich aus jeweils zwei 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. Da das Projekt erst im Dezember startete, fanden 2010 neben einem Kickoff-Meeting nur erste koordinierende Tätigkeiten statt.
2.8.6 Tier-2-Zentrum des Large Hadron Collider Computing Grids (LCG)
Das derzeit weltgrößte Teilchenphysikexperiment „Large Hadron Collider“ am CERN steigerte in 2010
die Energie der Teilchenkollisionen. Bei den Experimenten der bedeutenden Wissenschaftsprojekte am
CERN entstehen gewaltige Mengen an Daten im Petabyte-Bereich. Für die Auswertung wurde von Anfang an auf verteilte Ressourcen gesetzt. Heute sind dafür weltweit hunderte Cluster in einem Grid – dem
LHC Computing Grid (LCG) – vernetzt. Das LRZ betreibt dabei zusammen mit dem MCSC-Partner RZG
und den Hochenergiephysikern aus dem Münchner Raum ein Tier-2-Zentrum (siehe Abbildung 42).
Speicher- und Rechenknoten des Tier-2 Zentrums wurden im Rechnerwürfel des LRZs installiert. Den
Betrieb bis zur Vermittlungsschicht, der Middleware gLite, übernimmt das LRZ, die Middleware und die
darüber liegende Experiment-Software wird von den Physikern der LMU betreut. Derzeit stehen am LRZ
für die Speicherung der Experimentdaten und Auswertungsergebnissen 915 Terabyte (TB) zur Verfügung. Durch die Absicherung als RAID beträgt die Nettokapazität 723 TB, die über die dCache-
91
Speicherverwaltung bereitgestellt werden. Die LCG-Rechenknoten sind in den LRZ-Linux-Cluster integriert. Dadurch können Kapazitätsengpässe sowohl bei LCG-Aufgaben als auch bei LRZ-Aufgaben 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.
Abbildung 42: Tier-Struktur des LHC Computing Grids.
2.8.7 LRZ-Projekt „Eclipse4Grid“
Das interne LRZ-Projekt „Eclipse4Grid“ hat sich zum Ziel gesetzt, das Software-EntwicklungsFramework „Eclipse“ von IBM für Grid-Anwendungen geeignet zu erweitern. In Kooperation mit dem
DEISA-Arbeitspaket 8 wurde die Erweiterung PTP untersucht. Darüber hinaus wurden die Erweiterungen
unter die Lupe genommen, die im Rahmen des gEclipse-Projekts entstanden sind. Zusammen mit dem
ISAR-Projekt wurde am 1. Oktober 2010 der PTP Workshop „Eclipse: C/C++ programming (with a
slight Fortran touch)“ gehalten. Ein Abschlussworkshop mit dem Titel „Parallel Tools Platform (PTP):
Eclipse based IDE for parallel application development, debugging and profiling“ ist für März 2011 geplant. Das Projekt lief Ende 2010 erfolgreich aus.
2.8.8 Cloud-Computing
Während beim Grid-Computing der Hauptaspekt die föderale Nutzung von auf die Partner verteilten Ressourcen ist, richtet sich das Cloud-Computing vornehmlich auf die Virtualisierung von Ressourcen. Diese
Ressourcen sind nicht mehr unbedingt weiträumig verteilt, sondern oft bei einem kommerziellen Anbieter
geclustert. So bieten Amazon, Google, aber auch die Deutsche Telekom Cloud Ressourcen gegen Entgelt
an. Da dem Benutzer jeweils virtuelle Maschinen unter verschiedenen (Linux) Betriebssystemen angeboten werden, ist die genaue Beschaffenheit der zugrundeliegenden Hardware nur mehr zweitrangig. Durch
die Virtualisierung wird auch der beim Nutzer ansonsten oft erhebliche Portierungsaufwand drastisch
verringert – idealerweise bis auf null, denn der Benutzer kann ein ihm genehmes Betriebssystem auswählen.
92
Im Rahmen des AK-Grid haben die Mitglieder verschiedene Cloud-Computing Anbieter getestet und in
Vorträgen die Ergebnisse einander vorgestellt. So wurde die Elastic Computing Cloud (ECC) von Amazon auf Ihre Eignung für das LCG getestet: prinzipiell ist die ECC dafür geeignet, jedoch sind derzeit die
auf „echter“ Hardware basierten Tier-2 Zentren (von denen eines auch am LRZ betrieben wird, siehe
Abschnitt 2.8.3) noch deutlich kostengünstiger, als das Cloud-Computing bei Amazon. Es wurden auch
Experimente mit den Angeboten von Google und der Telekom vorgeführt. Der AK verfolgte auch Bestrebungen der Open Cloud Computing Interface working group des OGF, um die derzeit noch proprietären
Interfaces der verschiedenen kommerziellen Anbieter zu vereinheitlichen und deren Clouds interoperabel
zu machen. Die freien Pakete NIMBUS und OpenNebula zum Aufbau einer Cloud wurden praktisch untersucht, jedoch sind beide noch nicht reif für den Produktionseinsatz. Im nächsten Jahr soll am LRZ prototypisch eine Cloud aufgesetzt und ausgewählten Benutzern zum Test angeboten werden.
2.8.9 Projektanträge 7. EU-Forschungsrahmenprogramm „e-Infrastrukturen“
Für die Ausschreibung „FP7-INFRASTRUCTURES-2011-2“ des 7. Forschungs-Rahmenprogramms der
EU beteiligte sich das LRZ an vielen Projekten. Die Projekte mit Beteiligung der Gruppe VER werden im
Folgenden aufgezählt. Eine Entscheidung über die Genehmigung dieser Projekte fällt voraussichtlich im
Frühjahr 2011.
Die Gruppe „Verteilte Ressourcen“ war an den folgenden EU-Projektanträgen im FP7-Call beteiligt:
• Partnership for Advanced Computing in Europe - First Implementation Phase Project
(PRACE-2IP (Konsortialführung FZ Jülich)
• My e-World (M-eW, Konsortialführung NCF, Den Haag)
• Virtual Earthquake and Seismology Research Community in Europe (VERCE, Konsortialführung CNRS-INSU, Paris), Wiederholungsantrag
• Intelligent Application-Oriented Scheduling Framework (IANOS, ATOS Origin Spanien),
Wiederholungsantrag
• Distributed Research Infrastructure for Hydro-Meteorology (DRIHM, Universität Genua),
Wiederholungsantrag
2.8.10 Betrieb der Grid-Infrastruktur
Der Regelbetrieb der Grid-Dienste wurde durch die Mitarbeiter der Gruppe „Verteilte Ressourcen“ betreut und ausgebaut. Derzeit betreut die Gruppe etwa 70 Server, auf denen ca. 40 Dienste in Produktionsund Testbetrieb laufen. Bei den seit Anfang 2010 in Produktion befindlichen Systemen lag die Verfügbarkeitsquote bei 99.968%. Um die Ausfallsicherheit der Dienste weiter zu erhöhen, wurde fortgefahren,
sie von physikalischer Hardware auf virtuelle Maschinen aus dem LRZ VMware-Pool zu migrieren. Außerdem wurde die automatische Überwachung der Maschinen und Dienste deutlich erweitert, sowie regelmäßige Kernel-Updates und Security-Checks durchgeführt.
Die lokale Grid-Benutzerverwaltung GUA (Grid User Administration) wurde vollständig mit LRZ SIM
integriert. Benutzer aus D-Grid VOs (virtuelle Organisationen) und DEISA Projekten erhalten nun automatisch Zugang zum Linux Cluster bzw. zum Höchstleistungsrechner. Die Zahl der Grid-Accounts stabilisiert sich bei ca. 1.500 (1.409 Grid-Accounts in 2010, im Vorjahr waren es 1.569). Etwa 5% der HLRB
II-Rechenleistung sowie ein Teil der Rechenleistung unseres Linux Clusters werden über GridMiddleware von den Wissenschaftlern abgerufen.
Die LRZ Grid Registration Authority, die auch die Rolle der Grid Registration Authority der LMU, der
TUM und der Universität der Bundeswehr einnimmt, hat auch in 2010 wieder die Mitarbeiter und Studenten der drei großen Münchner Universitäten bei der Grid-Nutzung unterstützt. Insgesamt wurden 2010 72
User- und 52 Server-Zertifikate ausgestellt.
2.8.11 Sonstige Grid-Aktivitäten
Am LRZ wurde im Rahmen der Einführungsveranstaltungen Grid Computing mit Übungen für die Teilnehmer vorgestellt und traf auf große Resonanz. Die Grid-Zugänge über gsi-ssh stehen nun gleichberechtigt neben ssh mit Passwort in unseren Dokumentationsseiten für alle Benutzer. Dazu trug auch der Short
93
Lived Credential Service (SLCS) des DFN bei, der mit dem Identity provider (IdP) des LRZ gekoppelt ist
und so allen LRZ Benutzern ohne weitere Formalitäten erlaubt, jederzeit ein Grid Zertifikat (der Schlüssel
zum Grid computing) zu erhalten.
Neben der durch IGE in besonderem Maß hervortretenden Expertise im Bereich Globus Toolkit war das
LRZ auch mit der D-Grid-Entwicklung D-MON zum VO-basierten Monitoring auf europäischer Ebene
stark vertreten. Dies zeigte sich u.a. in der Prämierung eines D-MON-Posters auf dem 1. EGI Technical
Forum in Amsterdam mit dem Best Poster Award.
Und last but not least wurde unser LRZ-Grid-Portal (http://www.grid.lrz.de/), mit dem sich das LRZ seinen Kunden im Grid-Bereich präsentiert, regelmäßig aktualisiert und entwickelte sich zu einem festen
Anlaufpunkt für wichtige Informationen aus dem Grid-Umfeld für Benutzer aus der ganzen Welt.
2.9
Managed Hosting für Hochschulstart.de
Die „Stiftung für Hochschulzulassung“ (Stiftung öffentlichen Rechts) ist die Nachfolgerin der Zentralstelle für die Vergabe von Studienplätzen. Im Auftrag der Kultusministerkonferenz wird die Stiftung ab
2011/12 ein bundesweites, zentrales „Dialogorientiertes Verfahren“ für die Vergabe von Studienplätzen
für alle deutschen Hochschulen etablieren. Über eine neue Web-Applikation, die von der T-Systems Multimedia Systems GmbH erstellt wurde, können sich Bewerber an mehrere Hochschulen bewerben und die
Hochschulen können effizient eine Bewerberauswahl treffen und zusagen.
Das LRZ wurde von der Stiftung beauftragt, den Infrastrukturbetrieb und das Managed Hosting für die
neue Applikation durchzuführen. Die Vorbereitungsarbeiten haben bereits im September 2010 begonnen,
die Hosting-Vereinbarung läuft zunächst bis zum 31.03.2012. Mit dem Management der Applikation
selbst wurde die T-Systems MMS beauftragt.
95
3 Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes
3.1
Betrieb des Kommunikationsnetzes
Das Münchner Wissenschaftsnetz (MWN) verbindet vor allem Standorte der Ludwig-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.
Diese Standorte sind insbesondere über die gesamte Münchner Region (i. W. Münchner Stadtgebiet, Garching, Großhadern/Martinsried und Weihenstephan) verteilt, es gibt aber auch weitere Standorte in Bayern.
Derzeit sind an das MWN mehr als 510 als Unterbezirke bezeichnete Gebäudegruppen in mehr als 50
Arealen angebunden (siehe Abbildung 43) und es werden mehr als 79.500 Systeme versorgt. Die Lage
von Standorten, die außerhalb des Münchner Stadtgebietes liegen, ist in der Abbildung nicht maßstabsgetreu dargestellt, sondern lediglich schematisch (in Himmelsrichtung) angedeutet. Die Größe der zu versorgenden Areale ist sehr unterschiedlich; sie reicht von einem einzelnen Gebäude bis zu einem gesamten
„Campusbereich“ (z.B. Garching, Weihenstephan) mit mehr als 30 Gebäuden und mehr als 12.000 angeschlossenen Endgeräten. Derzeit sind bereits über 50 Studentenwohnheime mit insgesamt knapp 12.000
Wohnheimplätzen am MWN angeschlossen.
Abbildung 43: Lage der Standorte im MWN
96
Entwicklungen und Tätigkeiten im Bereich des Kommunikationsnetzes
Abbildung 44: Standorte und Verbindungen im MWN
Abbildung 44: (Fortsetzung) Standorte und Verbindungen im MWN
97
98
Die Areale des MWN werden zu Dokumentationszwecken auch mit Kürzeln aus 1 oder 2 Zeichen (Unterbezirke) benannt (eine Liste der Unterbezirke findet sich im MWN-Netzkonzept;
http://www.lrz.de/services/netz/mwn-netzkonzept/MWN-Netzkonzept-2010.pdf).
Das LRZ ist für das gesamte Backbone-Netz und einen Großteil der angeschlossenen Institutsnetze zuständig. Eine Ausnahme bilden die internen Netze der Medizinischen Fakultäten der Münchner Universitäten (u. a. Rechts der Isar (TUM), Großhadern und Innenstadt-Kliniken (LMU)) sowie der Informatik der
TUM. Sie werden von den jeweiligen Rechenzentren der Fakultäten selbst betrieben und betreut. Das
LRZ ist jedoch für die Anbindung dieser Netze an das MWN zuständig.
Das MWN ist mehrstufig realisiert:
• Das Backbone-Netz verbindet mittels Routern die einzelnen (Hochschul-)Standorte (Areale) und Gebäude innerhalb der Areale.
• Innerhalb eines Gebäudes dient das Gebäudenetz mittels Switches zur Verbindung der einzelnen
Rechner und der Bildung von Institutsnetzen.
• Eine Sonderstellung nimmt das Rechenzentrumsnetz ein, das die zentralen Rechner im Rechnerwürfel
des LRZ miteinander verbindet.
Etwas genauer lässt sich diese Realisierung wie folgt beschreiben:
• Die Router werden über das Backbone-Netz miteinander verbunden und bilden den inneren Kern
des MWN. Die Verbindungsstrecken des Backbone-Netzes sind je nach Nutzungsgrad verschieden ausgeführt. Im Normalfall sind die Strecken Glasfaserverbindungen, die von der Deutschen
Telekom und M-net langfristig angemietet sind. Auf den Glasfaserstrecken wird mit 10 Gbit/s
übertragen. Die Verbindung der Strecken übernehmen fünf Backbone-Router, die untereinander
aus Redundanzgründen mehrere Ringe bilden. Netze mit einer geringen Zahl von Endgeräten
werden überwiegend mit SDSL-Verbindungen (bis zu 10 Mbit/s) von M-net oder WLANVerbindungen auf Basis von IEEE 802.11a oder g (bis 54 Mbit/s) angebunden.
• Die Switches eines Gebäudes oder einer Gebäudegruppe werden mittels Glasfaser zum allergrößten Teil mit 1 Gbit/s, aber auch mit 10 Gbit/s an die Router herangeführt.
• In den Gebäuden geschieht die Anbindung von Datenendgeräten über Ethernet. Die Anbindung
wird entweder über „Twisted-Pair“-Kupferkabel (100/1000 Mbit/s) und Lichtwellenleiter (100
Mbit/s oder zum Teil 1000 Mbit/s) oder zu einem sehr geringen Teil noch über Koaxial-Kabel
(10 Mbit/s) realisiert. Server-Rechner werden fast immer mit 1 Gbit/s angeschlossen.
• Die zentralen Rechner im LRZ (der Bundeshöchstleistungsrechner HLRB II, die Linux-Cluster,
die Server des Backup- und Archivsystems und die zahlreichen Server-Systeme) sind untereinander größtenteils mit 10 Gbit/s mittels Switches verbunden. Diese Netzstruktur der zentralen
Rechner ist über einen Router (10 Gbit/s) mit dem MWN-Backbone verbunden.
• Im MWN wird ausschließlich das Protokoll TCP/IP benutzt.
Abbildung 44 zeigt die für das Backbone-Netz verwendeten Strecken, deren Übertragungsgeschwindigkeiten und Endpunkte. Hieraus lässt sich die Ausdehnung des Netzes ablesen.
3.1.1 Backbone-Netz
Aus Abbildung 45 ist die Struktur des Backbone-Netzes ersichtlich. Den Kern des Backbones bilden Cisco Catalyst 6509 Switch/Router, die untereinander mit 10 GBit/s verbunden sind. Die Anbindung der
Standorte erfolgt über LWL (Lichtwellenleiter). Das LRZ selbst ist über einen virtuellen Router (bestehend aus zwei 6509) an das Backbone angebunden. Alle Telekom-Glasfasern enden im zentralen Netzraum des TUM-Stammgeländes. Die M-net Glasfasern enden im zentralen Netzraum des LMUStammgeländes.
Das Router-Backbone bildet mehrere Zyklen, die der Redundanz dienen. Bis auf die Router in Weihenstephan und an der Hochschule München haben alle eine mindestens doppelte Anbindung an das
Backbone. Die Router unterhalten sich über Punkt-zu-Punkt Verbindungen mittels OSPF (Open Shortest
Path First). Der Verkehr fließt von der Quelle zum Ziel über die Leitungen mit der kleinsten „Hop“Anzahl (Weg, der über die wenigsten Router führt).
99
Abbildung 45: Das MWN-Backbone-Netz
Ausnahmen von dieser generellen Regel bilden der über „Policy-Based-Routing“ geführte Verkehr, der in
einem eigenen VLAN (Virtual LAN) fließt, und spezielle VLANs, die über das gesamte MWN gezogen
wurden. Dies ist nötig, um die besonderen Anforderungen von MWN-Mitnutzern (MPG-Institute, Staatsbibliothek usw.) zu erfüllen.
Auch die Internet-Anbindung ist redundant ausgelegt. Es gibt zwei Anbindungen an das X-WiN und eine
an M-net. Dabei ist die Hierachie so gewählt, dass die höchste Priorität die Internet-Anbindung 1 (siehe
Abbildung 45) hat. Fällt diese aus, wird zur Internet-Anbindung 2 gewechselt. Erst wenn diese auch ausfällt, wird der Weg über M-net gewählt. Die Umschaltung zwischen den Internet-Anbindungen wird automatisch über ein Routing-Protokoll (BGP, Border Gateway Protocol) gesteuert.
3.1.2 Gebäude-Netze
In den Gebäuden existiert grundsätzlich eine strukturierte Verkabelung bestehend aus Kupferkabeln (Kategorie 5/6, TP) oder Multimode-Lichtwellenleiter-Kabeln (50/125µ). Zu einem sehr geringen Anteil ist
jedoch in sehr wenigen, noch zu sanierenden Gebäuden, immer noch Ethernet-Koax-Kabel (yellow cable)
verlegt, wobei sich durch Sanierungsmaßnahmen der Umfang auch in diesem Jahr weiter verringert hat.
Als aktive Komponenten zur Verbindung mit den Endgeräten werden (Layer-2-)Switches eingesetzt.
Ende 2008 wurde eine Switch-Auswahl durchgeführt, bei der Switches der Firma HP Procurve gewonnen
haben, da diese für die Anforderungen im MWN am besten geeignet sind. Derzeit sind vor allem 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 im Jahr 2010 wurden weitere HP
ProCurve-Switches der Serien 4200 und 5400 aufgebaut. Kennzeichen dieser Netzkomponenten sind
10GE und anspruchsvolle Features wie QoS und Meshing. Alle diese Geräte sind modular aufgebaut und
bieten über einzubauende Schnittstellenkarten Anschluss von bis zu 288 Geräten. Die Switches der Serien
HP ProCurve 4000 und 2524 sind die derzeit ältesten Komponenten; sie wurden in 2010 bis auf 6 Geräte
durch neuere Switches ersetzt. Für 2011 und die folgenden Jahre ist eine Ersetzung der nächstältesten
100
Switch-Generation (HP ProCurve 4100) geplant, die z.T. bereits seit neun Jahren im Einsatz sind und
hinsichtlich ihrer Leistungsfähigkeit und Funktionalität nicht mehr den heutigen Anforderungen entsprechen. Für diese Ersetzung wurde im Jahr 2010 ein Großgeräteantrag gestellt, der Ende des Jahres genehmigt wurde.
Zum Jahresende 2010 wurden vom LRZ insgesamt 1126 Switches betrieben. Einen Vergleich zu den
Vorjahren zeigt Tabelle 29:
Anzahl Switches
davon HP-Switches
davon Cisco-Switches
davon 3Com-Switches
Anzahl TP-Ports
Anzahl Glasfaser-Ports
Ende 2010
Ende 2009
Ende 2008
Ende 2007
Ende 2006
1126
990
914
843
780
1125
989
914
843
738
1
67.040
6.842
1
60.363
6.493
53.591
6.245
47.212
5.302
42
42.050
5.110
Tabelle 29: Switches im Jahresvergleich
Die Verteilung nach Switchtypen ist im Abschnitt 7.3.2 zu finden.
3.1.3 Rechenzentrumsnetz
Das LRZ-Rechnergebäude besteht in Bezug auf das Datennetz im Wesentlichen aus drei verschiedenen
Bereichen: dem Daten- und Archiv-Raum (DAR), in dem sich das Backup- und Archiv-System befindet,
dem Netz- und Server-Raum (NSR), der den zentralen Mittelpunkt des Netzes, das Linux-Cluster sowie
die Server mit den diversen Netzdiensten (Mail, Web usw.) beherbergt, sowie dem Höchleistungsrechnerraum (HRR). Das Datennetz in diesen drei Räumen ist den unterschiedlichen Anforderungen der Rechnerlandschaft angepasst und ist wie folgt aufgebaut:
DAR-Raum: Im Wesentlichen besteht das Netz in diesem Raum aus sieben Switches, die auf Grund der
hohen Bandbreite, die das Backup- und Archiv-System benötigt, mit jeweils 10 Gbit/s bzw. 2 ∙ 10 Gbit/s
an den zentralen Routern im NSR-Raum angeschlossen sind. Die älteren Backup-Server sind an diesen
Switches mit jeweils 1 oder 2 Gbit/s (Trunk) angeschlossen, die neuen, in den Jahren 2009 und 2010 beschafften Server des LABS-Systems, mit 10 Gbit/s.
NSR-Raum: Die Netzstruktur in diesem Raum besteht aus zwei Ebenen. Die erste Ebene bilden zwei
Router, über die die LRZ-Gebäude mit dem MWN-Backbone verbunden sind, und zwei Core-Switches
HP E8212, die mit jeweils 2 ∙ 10 Gbit/s an den Routern angeschlossen sind. Jeder dieser beiden zentralen
Switches ist redundant aufgebaut mit zwei Management- und zwei Switch-Fabric-Modulen. Hinter den
Core-Switches befinden sich ca. 80 Edge-Switches, die in die einzelnen Server-Racks eingebaut sind und
die in der Regel mit jeweils 1 Gbit/s mit den Core-Switches verbunden sind, in einigen Fällen auch mit 10
Gbit/s. Die Server selbst sind in der Regel mit 1 Gbit/s an den Edge-Switches angeschlossen, wobei aus
Redundanzgründen die Server teilweise an zwei verschiedenen Switches angebunden sind, so dass die
Verfügbarkeit dieser Server auch bei einem Ausfall eines Switches erhalten bleibt. Eine Sonderstellung
im NSR-Raum bildet das Linux-Cluster, das über eine eigene Infrastruktur mit dem Nexus7000 von Cisco
und 34 daran angeschlossenen Edge-Switches verfügt. Am Nexus7000 sind sowohl die Edge-Switches als
auch 150 Server direkt mit jeweils 10 Gbit/s angebunden. Um die Ausfallsicherheit weiter zu erhöhen,
wurde Anfang 2010 zwischen den zentralen Komponenten (Router, Core-Switches und Edge-Switches
für die VMware-Server) das Spanning-Tree-Protokoll aktiviert, so dass bei einem Ausfall einer Leitung
oder einer Komponente der Datenverkehr ohne Unterbrechung weiterläuft. In diesen Spanning-TreeVerbund wurden Ende 2010 auch die beiden Switches mit aufgenommen, an die die Server des Hochschulstart-Projekts (vgl. Abschnitt 2.9) angeschlossen sind.
HRR-Raum: Der im Jahr 2006 installierte Bundeshöchstleistungrechner besteht aus insgesamt 16 Knoten, wobei jeder Knoten über zwei 10-Gbit-Netzwerkkarten verfügt. Diese Knoten sind mit jeweils einem
Interface an zwei unterschiedlichen Routern angeschlossen. Einer dieser Router ist mit dem MWN verbunden, der andere verfügt über einen eigenen 10-Gbit-Anschluss an das WiN und wird ausschließlich für
101
die Verbindung zu anderen Höchstleistungsrechnern im Rahmen des DEISA-Projektes verwendet. Neben
den beiden Routern befinden sich auch noch einige Switches im HRR-Raum, die für die interne Vernetzung des Höchstleistungsrechners (CXFS-Dateisystem, Management) verwendet werden.
Abbildung 46: Struktur des Rechenzentrumsnetzes
3.1.4 Wellenlängenmultiplexer
Das LRZ setzt seit 1997 Wellenlängenmultiplexer (Wavelength-Division-Multiplexer, WDM) auf den
angemieteten Glasfaserleitungen der lokalen Provider (Telekom und M-net) ein. Hierdurch lassen sich auf
Leitungsebene getrennte Strukturen aufbauen. WDM-Systeme werden derzeit im MWN dazu verwendet,
um die verfügbaren Glasfaserleitungen parallel zum Produktionsnetz für folgende Dienste zu nutzen:
 Kopplung von Nebenstellenanlagen (TK-Kopplung)
 Realisierung von standortübergreifenden Intranets (z.B. Max-Planck-Gesellchaft, Verwaltung)
 Realisierung von Testnetzen parallel (ATM-Pilotprojekte, Fiber-Channel-Kopplung von Speichernetzen usw.)
Im MWN werden aktuell auf 10 Verbindungen WDM-Systeme eingesetzt (siehe Tabelle 30).
Die WDMs, die bisher für die Verbindung der verschiedenen Standorte der medizinischen Fakultät der
TUM (Klinikum Rechts der Isar, Klinikum am Biederstein, Poliklinik für Präventive und Rehabilitative
Sportmedizin und Schwabinger Krankenhaus) verwendet wurden, wurden im Jahr 2010 außer Betrieb
genommen. Das medizinische Intranet zwischen den vier Standorten, das bisher über eigene WDMKanäle bewerkstelligt wurde, wird nun durch MPLS-Verbindungen über das MWN-Backbone realisiert.
Die Telefonanlagen sowie deren abgesetzten Telefonanlagenteile der Technischen Universität und der
Ludwig-Maximilians-Universität werden zum größten Teil mittels IP, d.h. über das Standardprotokoll im
MWN, miteinander gekoppelt.
102
Verbindung
WDM-Typ
Zweck
TU-Nordgelände –
LMU-Stammgelände
MRV LambdaDriver
800
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 LambdaDriver
800
Gbit/s)
Intranet der Max-Planck-Gesellschaft (1 x 10
Gbit/s)
TU-Nordgelände –
Großhadern
MRV LambdaDriver
800
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)
FH-München –
7 externe Standorte
ADVA FSP1
Anbindung zur Zentrale in der Lothstraße 34
von folgenden Standorten:
 Pasing, Am Stadtpark 20
 Lothstr. 21
 Schachenmeierstr. 35
 Karlstr. 6
 Infanteriestr. 13
 Dachauer Str. 98b
TK-Anlagen-Kopplung
Intranet der FH-Verwaltung
Tabelle 30: WDM-Verbindungen
3.1.5 WLAN (Wireless LAN)
Die seit dem Jahr 2000 eingerichteten Zugangsmöglichkeiten über WLAN wurden 2010 weiter ausgebaut. Ende Dezember 2010 waren 1.462 (Vorjahr 1.324) WLAN Accesspoints in 221 (221) Gebäuden
installiert. Die Accesspoints sind vor allem in öffentlichen Bereichen wie Hörsälen, Seminarräumen, Bibliotheken und Foyers installiert. Das Angebot erfreut sich steigender Beliebtheit, zeitweise waren mehr
als 4.500 gleichzeitig aktive Verbindungen aufgebaut. Insgesamt wurden fast 150.000 (148.658) verschiedene Geräte (MAC-Adressen) registriert, dabei am Tag über 15.000 (15.605 am 8.12.2010). Die am
stärksten frequentierten Accesspoints waren mit bis zu 105 gleichzeitigen Verbindungen belegt. Bei Veranstaltungen lag der Wert noch höher. Um diesen Ansturm aufzufangen wurden gezielt einzelne, stark
frequentierte Accesspoints (21 MSM310) durch die nächste Geräte-Generation (MSM422) ersetzt.
103
Abbildung 47: Anzahl aktiver WLAN-Verbindungen (5-Minuten-Mittel)
Abbildung 48: Entwicklung der Belegung über das Jahr 2010 (Tagesmittel)
In den Abbildungen zeigt der blaue bzw. dunklere Bereich den Anteil von Verbindungen mit IEEE
802.11g (54 Mbit/s).
Als Zugangskomponenten werden Accesspoints der Typen MSM310 (CN320), MSM320 (CN330) und
MSM422 (MAP625) der Firma HP (ehemals Colubris) eingesetzt. Mit den MSM422 werden auch Verbindungen mit IEEE 802.11n im 5GHz-Band angeboten, mit denen Geschwindigkeiten bis zu 300Mbit/s
erreicht werden können.
Im Laufe des Jahre 2010 wurden folgende Bereiche neu mit WLAN ausgestattet:
HSWT Weihenstephan Gebäude 4373
HSWT Weihenstephan, Geb. 4173
HSWT Weihenstephan Geb. 4176
HSWT Weihenstephan Staudengarten, Geb. 4374
HM Dachauer Str. 98b, Bau E
HM Schachenmeierstr. 35, Bau S
LMU Großhadern, Wasserchemie, Verfügungsbau
LMU Leopoldstraße 11a
LMU Martinsried, Bio 2
LMU Schönfeldstr. 13
LMU Winzerer Str. 45
Monumenta Germaniae Historica in der Bay. Staatsbibliothek
Monumenta Germaniae Historica, Kaulbachstr. 19
TUM Gabelsberger Str. 39
TUM Garching IAS
TUM Karlstr. 45
TUM Leopoldstr. 139
TUM Nordgelände N2
104
TUM Nordgelände N3
TUM Schragenhofstr. 31
TUM Weihenstephan Botanik, Gebäude 218
TUM Weihenstephan Phytopathologie, Dürnast Geb. 232
TUM ZHS Geb. 2304
Zoologische Staatssammlung
Im Laufe des Jahres 2010 wurde in folgenden Bereichen das WLAN wegen Umzug der Institute bzw.
Aufgabe des Gebäudes abgebaut:
LMU Georgenstr. 7
LMU Geschwister-Scholl-Platz 1, Philosophie
LMU Schellingstraße 10
TUM Weihenstephan Gemüsebau Geb. 4201
Folgende Areale waren Ende des Jahres 2010 mit WLAN versorgt:
(nur zum geringen Teil flächendeckend):
Akademie der Bildenden Künste
Bayerische Staatsbibliothek
Deutsches Museum
Exzellenzcluster Universe
HSWT Weihenstephan Bioinformatik, Altes Bauamt
HSWT Weihenstephan Forstwirtschaft
HSWT Weihenstephan Landpflege, Kustermannhalle
HSWT Weihenstephan Löwentorgebäude
HSWT Weihenstephan Pappelallee
HSWT Weihenstephan, Geb. 4173
HSWT Weihenstephan Bibliothek
HSWT Weihenstephan Staudengarten, Geb. 4374
HSWT Weihenstephan Landtechnik, Geb. 4383
HSWT Triesdorf, 4 Gebäude
HM Dachauer Str. 98
HM Dachauer Str. 98b, Bau E
HM Lothstr. 34
HM Infanteriestr. 14
HM Lothstr. 13 Mensa und Bibliothek
HM Karlstr. 6
HM Lothstr. 21
HM Pasing, Am Stadtpark 20
HM Schachenmeierstr. 35, Bau S
Internationales Begegnungszentrum, Amalienstr. 38
Hochschule für Philosophie
Hochschule für Fernsehen und Film, Frankenthalerstr. 23
LRZ Garching
LMU Akademiestr. 1
LMU Amalienstr. 17
LMU Amalienstr. 54
LMU Amalienstr. 83
LMU Edmund Rumpler Str. 9
LMU Edmund-Rumpler-Str. 13
LMU Frauenlobstr. 7a
LMU Garching, Beschleuniger-Laboratorium
LMU Garching, Physik-Departement Coulombwall
LMU Georgenstr. 11
LMU Geschwister-Scholl-Platz 1
LMU Geschwister-Scholl-Platz 1, Adalberttrakt
LMU Geschwister-Scholl-Platz 1, Bücherturm
LMU Geschwister-Scholl-Platz 1, Hauptgebäude
LMU Geschwister-Scholl-Platz 1, Segafredocafe
LMU Giselastraße 10
LMU Großhadern, Chemie/Pharmazie
LMU Großhadern, Genzentrum
LMU Großhadern, Wasserchemie, Verfügungsbau
LMU Hohenstaufenstr. 1
LMU Königinstraße 12
LMU Königinstraße 16
LMU Kaulbachstr. 37
LMU Kaulbachstr. 45
LMU Kaulbachstr. 51a
LMU Katharina-von-Bora-Straße 10
LMU Konradstraße 6
LMU Leopoldstraße 3
LMU Leopoldstraße 11a
LMU Leopoldstraße 13, Haus 1, Geb. 0601
LMU Ludwigstr. 14
LMU Ludwigstr. 25
LMU Ludwigstr. 27
LMU Ludwigstr. 28
LMU Ludwigstr. 29
LMU Ludwigstr. 31
LMU Ludwigstr. 33
LMU Luisenstr. 37
LMU Martinsried, Bio 2
LMU Martinsried, Biozentrum
LMU Martinsried Mensa
LMU Martiusstr. 4
LMU Menzinger Straße 67
LMU Oberschleißheim, Klauentierklinik
105
106
LMU Oberschleißheim, Schleicherbau
LMU Oberschleißheim, Versuchsgut St. Hubertus
LMU Oberschleißheim, Vogelklinik
LMU Oettingenstr. 67
LMU Oettingenstraße 67 Baracke
LMU Prof. Huber Platz 2, Geb. 420
LMU Vestibülbau (Prof. Huber Platz), Geb. 421
LMU Vestibülbau Turm (Außenbereich), Geb. 421
LMU Richard-Wagner Str. 10
LMU Schönfeldstr. 13
LMU Schackstr. 4
LMU Schellingstraße 3 Rückgebäude
LMU Schellingstraße 3 Vordergebäude
LMU Seestr. 13
LMU Sternwarte Laplacestr. 16
LMU Sternwarte Scheinerstr. 1
LMU Theresienstraße 37
LMU Veterinärstraße 1
LMU Winzerer Str. 45
LMU ZAAR Destouchesstr. 68
LMU Zentnerstr. 31
Monumenta Germaniae Historica in der Bay. Staatsbibliothek
Monumenta Germaniae Historica, Kaulbachstr. 19
Musikhochschule Arcisstr. 12
Musikhochschule Barer Str. 34
Musikhochschule Gasteig
Musikhochschule Luisenstr. 37a
Olympisches Dorf Mensa
Pinakotheken Freifläche Nord
TUM Barer Str. 21
TUM Deutsches Museum
TUM Eichenau
TUM Garching Chemiegebäude
TUM Garching Exzellenzcluster Universe
TUM Garching IAS
TUM Garching Maschinenbau
TUM Garching Medizintechnik
TUM Garching Mensa
TUM Garching Physikdepartment
TUM Garching Physikdepartment II
TUM Garching Physikdepartment E18 Neutronenhütte
TUM Garching Umformtechnik und Gießereiwesen
TUM Garching Wassergütewirtschaft
TUM Iffeldorf Limnologische Station
TUM Karlstr. 45
TUM Katholische Hochschulgemeinde
TUM Klinikum rechts der Isar Teilbibliothek
TUM Klinikum rechts der Isar Hörsäle
TUM Klinikum rechts der Isar Lern- und Trainingszentrum
TUM Leopoldstr. 139
TUM Lothstraße 17
TUM Mensa
TUM Nordgelände N1
TUM Nordgelände N2
TUM Nordgelände N3
TUM Nordgelände N4
TUM Nordgelände N5
TUM Nordgelände N8
TUM Nymphenburger Str. 39
TUM Obernach Versuchsanstalt für Wasserbau
TUM Pasing Grundbau und Bodenmechanik
TUM Richard-Wagner Str. 18
TUM Schellingstraße 33
TUM Schragenhofstr. 31
TUM Stammgelände Präsidialbereich
TUM Stammgelände
TUM Stammgelände Audimax
TUM Stammgelände Cafeteria
TUM Stammgelände Architekturfakultät
TUM Stammgelände Architekturmuseum
TUM Stammgelände Bauinformatik
TUM Stammgelände Fak. Bauingenieurwesen
TUM Stammgelände Bauklimatik und Haustechnik
TUM Stammgelände Betriebswirtschaft
TUM Stammgelände Bibliothek
TUM Stammgelände Bildnerisches Gestalten
TUM Stammgelände Datenverarbeitung
TUM Stammgelände Datenverarbeitung Eikon-Turm
TUM Stammgelände Entwurfsautomatisierung
TUM Stammgelände Fachschaft Architektur
107
108
TUM Stammgelände Geodäsie
TUM Stammgelände Hydraulik und Gewässerkunde
TUM Stammgelände Kommunikationsnetze
TUM Stammgelände LMU Geographie
TUM Stammgelände STARTmunich e.V.
TUM Stammgelände Theresianum
TUM Stammgelände Wasserbau + Wasserwirtschaft
TUM Stammgelände Wirtschaftswissenschaften
TUM Versuchsgut Grünschwaige
TUM Weihenstephan Altes Molkereigebäude
TUM Weihenstephan Bibliotheksgebäude
TUM Weihenstephan Biologie der Lebensmittel
TUM Weihenstephan Biowissenschaften
TUM Weihenstephan Bodenkunde, Gebäude 4217
TUM Weihenstephan Botanik, Gebäude 218
TUM Weihenstephan Botanik, Geb. 219
TUM Weihenstephan Braufakultät, Gebäude 4112
TUM Weihenstephan Chemie + Biochemie, Geb. 4212
TUM Weihenstephan Dürnast, Geb. 4235
TUM Weihenstephan Ernährungslehre Geb. 4107
TUM Weihenstephan Fischbiologie
TUM Weihenstephan FML Geb. 4124
TUM Weihenstephan Forstbau Geb. 4277
TUM Weihenstephan Geb. 4101
TUM Weihenstephan Freigelände zu 4214
TUM Weihenstephan Genetik Geb. 4223
TUM Weihenstephan Grünlandlehre, Gebäude 4105
TUM Weihenstephan Hörsaalgebäude, Geb. 4102
TUM Weihenstephan Landtechnik, Geb. 4210
TUM Weihenstephan Lebensmittelchemie Geb. 4298
TUM Weihenstephan Lebensmitteltechnikum Geb. 4213
TUM Weihenstephan Lebensmittel Verfahrenstechnik Geb. 4126
TUM Weihenstephan Mensa, Geb. 4216
TUM Weihenstephan Physik, Geb. 4212
TUM Weihenstephan Phytopathologie, Dürnast Geb. 232
TUM Weihenstephan Tierernährung Geb. 4308
TUM Weihenstephan Tierwissenschaften
TUM Weihenstephan Geb 4113
TUM Weihenstephan Hörsaalgebäude, Geb. 4214
TUM Winzerer Str. 45
TUM ZHS BFTS
TUM ZHS Geb. 2301
TUM ZHS Geb. 2303
109
TUM ZHS Geb. 2304
TUM ZHS Geb. 2305
TUM ZHS Geb. 2306
Walther-Meißner Institut
Wissenschaftszentrum Straubing
Zentralinstitut für Kunstgeschichte, Katharina-von-Bora-Straße 10
Zoologische Staatssammlung
3.1.6 Wesentliche Netzänderungen im Jahr 2010
Im Jahr 2010 gab es folgende in chronologischer Reihenfolge aufgeführte wesentliche Netzveränderungen:
08.01.2010
Anschluss des Fraunhofer Instituts für Sichere Informationstechnologie (SIT) am
Business Campus in Garching mit 1 Gbit/s
04.02.2010
Anschluss der TU-Mathematik im Business-Campus in Garching mit 1 Gbit/s
(gemeinsam genutzter Anschluss mit Fraunhofer SIT)
10.02.2010
Anschluss des TUM Exzellenzzentrums in Garching mit 1 Gbit/s
18.02.2010
Anschluss des Studentenwohnheims Gregorianum mittels aDSL mit 18 Mbit/s
26.02.2010
Bandbreitenerhöhung für die Hochschule für Musik und Theater im Gasteig auf
100 Mbit/s
03.03.2010
Anschluss des TUM Gebäudes Karlstr. 45 mit 1 Gbit/s
18.03.2010
Anschluss des TUM Gebäudes 4115 in Weihenstephan über das Gebäude 4102
(Bibliothek)
28.04.2010
Anbindung der Container an der Triton-Hütte des Beschleunigerlabors in Garching
25.05.2010
Umzug des Zentrum für Arbeitsbeziehungen und Arbeitsrecht (ZAAR) von der
Infanteriestr. 8 in die Destouchestr. 68
17.06.2010
Anschluss des TUM Gebäudes Guerickestr. 25 mit 1 Gbit/s
05.07.2010
Anschluss des Studentenwohnheims Türkenstr. 58 mit 1 Gbit/s
15.07.2010
Anschluss des LMU Gebäudes Fraunhoferstr. 12 in Planegg mit 1 Gbit/s
16.07.2010
Anbindung der Container der TUM Fischbiologie in Weihenstephan über eine
Funkbrücke
15.08.2010
Anschluss des Studentenwohnheims Student Living Center (SLC) Haus II und
Haus III über privat verlegte Glasfasern
17.08.2010
Upgrade der Anbindung des Gebäudes FCP-A am Genzentrum in Martinsried auf
10 Gbit/s
07.09.2010
Upgrade der Anbindung LMU Gebäude Amalienstr. 54 auf 10 Gbit/s
14.10.2010
Abbau einer Funkbrücke und Anbindung über privat verlegte Glasfaser; Gebäude
4123 in Weihenstephan
29.10.2010
Anschluss des LMU Gebäudes Schönfeldstr. 13 über eine privat verlegte Glasfaser
mit 1 Gbit/s
29.10.2010
Anschluss des Kinderhauses am Campus Garching über eine privat verlegte Glasfaser mit 1 Gbit/s
18.11.2010
Redundante Anbindung des Zentrum für Nanotechnologie und Nanomaterialien in
Garching über eine privat verlegte Glasfaser
110
25.11.2010
Anschluss des TUM Institute für Advanced Studies (IAS) in Garching mit 1 Gbit/s
20.12.2010
Anschluss des Physik Untergrundlabors in Garching über eine privat verlegte
Glasfaser
3.1.7 Netzausbau (Verkabelung)
Mit NIP (Netzinvestitionsprogramm in Bayern) wurde zwar eine flächendeckende Vernetzung erreicht,
diese ist jedoch an der TUM in München und Garching noch zu einem geringen Teil in Koax ausgeführt.
Bis Ende 2008 sollte diese Koax-Verkabelung durch eine strukturierte Verkabelung (Kupfer oder Glasfaser) ersetzt werden. Das Ziel wurde aber nicht erreicht, da einige Gebäude noch auf eine endgültige Generalsanierung warten bzw. es unklar ist, wie sie später genutzt werden.
3.1.7.1
TU München
Im Bereich der TU München (ohne Weihenstephan) konnten die im Folgenden aufgeführten Gebäude im
Jahr 2010 mit einer strukturierten Verkabelung versehen werden.
Innenstadt
Schragenhofstrasse 31 (Motorenlabor)
Derzeit gibt es noch Koax in Bau 0503, 0106 (N6) und 5402 (CH2), das aber im Rahmen anderer Maßnahmen ersetzt werden soll.
3.1.7.2
LMU
Im Bereich der LMU München sind alle Gebäude mit einer strukturierten Verkabelung versehen. Es gibt
jedoch teilweise Defizite in der Verwendung der installierten Medien (nur 4-drahtiger Anschluss [Cablesharing] oder Installation von Kategorie 5-Kabeln bzw. Anschlusskomponenten). Dies betrifft 28 Gebäude (NIP V). Die Kosten in Höhe von 18,4 Mio. € wurden vom Landtag genehmigt. Im Rahmen des
Konjunkturprogramms werden im ersten Bauabschnitt sechs Standorte bis August 2011 nachgerüstet
werden:
M-Bogenhausen
Universitäts-Sternwarte (Neuverkabelung bereits 2009 abgeschlossen)
M-Lehel
Oettingenstr. 67 (Informatik, Kommunikationswissenschaft usw.)
M-Schwabing
Leopoldstr. 13 Haus 1 – 3 (Psychologie+Pädagogik)
M-Maxvorstadt
Theresienstr. 37 (Physik, Meteorologie)
M-Maxvorstadt
Theresienstr. 39 (Mathematik)
M-Maxvorstadt
Theresienstr. 41 (Geo- und Umweltwissenschaften)
Die verbleibenden 22 Gebäude werden voraussichtlich ab 2012 im Rahmen des zweiten Bauabschnittes
der NIP V-Maßnahme mit einer Verkabelung der Kategorie 6a modernisiert.
3.1.7.3
Weihenstephan (TU München)
Im Campus Weihenstephan der TU München sind alle Gebäude mit einer strukturierten Verkabelung
versehen, entweder Kupfer (Kategorie 6-Kabel) oder Glasfaser (multimode).
3.1.7.4
LWL-Netze auf den Campus-Geländen
Auf dem Campusgelände TUM-Stamm/Nordgelände, LMU-Stammgelände, TUM-Garching, 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, Monomode) nicht vorhanden sind,
diese aber aufgrund der gestiegenen Übertragungsraten notwendig sind.
3.1.8 Anbindung Studentenwohnheime
Das LRZ ermöglicht Wohnheimen eine feste Anbindung über Standleitung, DSL-Technik oder WLAN
an das MWN und damit an das Internet. Die Kosten der Anbindung hat der Heimträger zu übernehmen,
111
für die Netznutzung werden aber keine Gebühren verlangt. Zum Jahresende 2010 sind 12.503 Wohnheimplätze (im Jahr 2009: 12.302) in 59 (56) Heimen an das MWN angeschlossen, davon 24 (20) über
eine Glasfaserleitung (LWL) mit 100 MBit/s, 15 Heime über Funkstrecken, 10 (11) Heime über DSL und
10 Heime über 100 MBit/s Laserlinks.
Die nachfolgende Tabelle zeigt die Wohnheime, die Ende 2010 am MWN angeschlossen sind:
Name
Adresse
Träger
Plätze
Anschluss
Studentenstadt
Freimann
Christoph-ProbstStraße 10
Studentenwerk
2440 LWL zu MPI Freimann
Studentenviertel auf dem
Oberwiesenfeld
Helene-Mayer-Ring 9
Studentenwerk
1801 LWL zu ZHS
Kreittmayrstraße
Kreittmayrstraße 14
Studentenwerk
Adelheidstraße
(mit Deutschkurse für Ausländer)
Adelheidstraße 13
Studentenwerk
John-Mott-Haus
Theo-Prosel-Weg 16
CVJM München e.V.
Oberschleißheim
Oberschleißheim
Am Schäferanger 9-15
Studentenwerk
171 LWL zu Rinderklinik
Georg-Lanzenstiel-Haus
Kieferngartenstraße 12
Verein evangelischer
Studentenwohnheime
135
Ökumenisches Studentenheim
Steinickeweg 4
Studentenwohnheime
70 Funk zu TUM-Uhrenturm
Hugo-Maser-Haus
Arcisstr. 31
Studentenwohnheime
Studentenwohnheim Geschwister Scholl
Steinickeweg 7
Studentenwohnheim Geschwister Scholl e.V.
227 SDSL M-net 2 MBit, Linux-Router
St. Albertus Magnus Haus
Avenariusstraße 15
(Pasing)
St. Albertus Magnus-Stiftung
(Kath.)
108 SDSL M-net
Wohnheimsiedlung Maßmannplatz
Hess-Straße 77
Wohnheimsiedlung
Maßmannplatz e.V.
124 Funk zu HM Dachauerstraße
Jakob Balde Haus
Theresienstraße 100
Studienseminar NeuburgDonau
110 LWL zu TUM
Internationales Haus
Adelheidstraße 17
Studentenwerk
Hedwig Dransfeld Allee
Hedwig Dransfeld
Allee 7
Studentenwerk
100 100 MBit/s Laserlink
Stettenkaserne
Schwere Reiter Str. 35
Studentenwerk
SDSL M-net für Uniradio
244 100 MBit/s Laserlink zur FH in der
Dachauerstraße
Heidemannstraße
Paul-Hindemith-Allee 4
Studentenwerk
Felsennelkenanger
Felsennelkenanger 7-21
Studentenwerk
545
100 MBit/s Richtfunk zur Studentenstadt, von dort per LWL zu MPI
Heiglhofstraße
Heiglhofstraße 64/66
Studentenwerk
415
100 MBit/s Laserlink mit integriertem
2 MBit-Funk-Backup
Sauerbruchstraße
Sauerbruchstraße
Studentenwerk
259
100 MBit-Laserlink mit integriertem 2
MBit-Funk-Backup
Garching I
Garching
Jochbergweg 1-7
Studentenwerk
110 100 MBit-Laserlink zu TU-Feuerwehr
Garching II
Garching
Enzianstraße 1, 3
Studentenwerk
112
Dominohaus
Garching
Unterer Strassäcker 21
Dominobau
Maschinenwesen
Garching
Studentenwerk
45 Funk zu FH (Erzgießereistr. 14)
374 Laser zu FH Dachauerstraße
60 Funk zu Winzererstr.
93
Funk zu Studentenstadt,
LWL zu MPI (IMC)
über Adelheidstr. 13
angeschlossen
100 MBit-Laserlink zu TUHeizkraftwerk
82 LWL zu TU-Heizkraftwerk
4 SpeedVDSL
112
Ehemalige Hausmeisterwohnung
97
LWL zu Theresienstraße
Intern mit Funk vernetzt
Türkenstraße
Türkenstraße 58
Studentenwerk
Weihenstephan II
Giggenhauser Str. 25
85354 Freising
Studentenwerk
226 LWL über Weihenstephan IV
Lange Point
(Weihenstephan III)
Lange Point 1-35
85354 Freising
Studentenwerk
382 LWL zu FH Heizhaus
Weihenstephan IV
Giggenhauserstraße 2733
Studentenwerk
239 LWL zur Telefonzentrale
Vöttinger Straße
(Weihenstephan I)
Vöttinger Straße 49
85354 Freising
Studentenwerk
122 LWL zu alter DVS
Roncallicolleg
(+ KHG)
Nymphenburger Str. 99
Roncalli-Colleg
Prof. Fuchtmann
125 Funk zur FH Schachenmeierstraße
BLLV-Wohnheim
Cimbernstraße 68
Bayerischer Lehrer- und
Lehrerinnenverband (BLLV)
160 SDSL M-net
Stiftung Maximilianeum
Max-Planck-Str. 1
Stiftung Maximilianeum
26 Funk zu KH Rechts der Isar
Studentenheim "Paulinum"
Rambergstraße 6
80799 München
Studentenwohnheim Paulinum
e.V. (Kath.)
Albertia, Ottonia, Erwinia
Gabelsbergerstr. 24
Stud.-Verbindungen
Albertia, Ottonia, Erwinia
25 Funk zu Richard Wagner Str. 18
Wohnheim Richard WagnerStr. 16
Richard-Wagner-Str. 16
Ingeborg van-Calker Stiftung
40 LWL zu Richard Wagner Str. 18
Hochschulhaus Garching
Enzianstr. 5
Evangelische Studentenwohnheime
65 Funk zu TU-Feuerwehr
Spanisches Kolleg
Dachauerstraße 145
Katholische Kirche
35 Funk 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
83 M-net SDSL
Wohnheim Stiftsbogen
Schröfelhofstraße 4
Studentenwerk
Priesterseminar St. Johannes
der Täufer
Georgenstraße 14
Katholisches Ordinariat
28 Funk zu Georgenstraße 11
Magdalena-Lindt-Heim
Kaulbachstr. 25
Ev. Waisenhausverein
93 LWL zu Staatsbibliothek
Marie-Antonie-Haus
Kaulbachstr. 49
Studentenwerk
94 LWL zu Ludwigstr. 28
Student Living Center 1
Freisinger Landstraße 47
Garching
Fa. Melampus
93 LWL zu TUM Heizhaus
Freisinger Landstr. 47a
Garching
Fa. Melampus
Freisinger Landstr. 45a
Garching
Fa. Melampus
Studentenwohnanlage
Biederstein
Biedersteiner Str. 24-30a
Studentenwerk
163 LWL zu Amalienstr. 17
Newman-Haus
Kaulbachstr. 29
Newman-Verein
Sophie-Barat-Haus
Franz-Josef-Str. 4
100 LWL zu Ordinariat
Johann-Michael-Sailer-Haus
Preysingstr. 83d
26 LWL zu Ordinariat
Heinrich-Groh-Str.
Heinrich-Groh-Str. 17
Studentenwerk
59 LML über Amalienstr. 17
Moosacher Straße
Moosacher Str. 81
Studentenwerk
Josef-Wirth-Weg 19
Josef-Wirth-Weg 19
Studentenwerk
Gästeappartment
Barer Str. 34
Hochschule für
348 Telekom-LWL zu TUM
580 LWL zu Campus Großhadern
68 Funk über Kaulbachstr. 29
1 ADSL mit VPN-Tunnel
Musikhochschule
113
Musik und Theater
Oskar von Miller Forum
Oskar von Miller Ring 25
Oskar von Miller Forum
80 LWL über Amalienstr. 17
Herzogliches Georgianum
Prof. Huber Platz 1
Erzdiözese München-Freising
44 DSL, intern WLAN
Rosenheim I
Marienberger Str. 36-38
Rosenheim
Studentenwerk
113 über Tunnel und Natomat
Rosenheim II
Westendorfer Str. 47a-m
Rosenheim
Studentenwerk
342 über Tunnel und Natomat
59 Wohnheime
3.2
Summe insgesamt
12.503
Dienste
Neben der physischen und technischen Infrastruktur werden innerhalb des MWN auch viele unterstützende Dienste angeboten und betrieben. Neben dem Übergang ins globale Internet und verschiedenen Zugangsmöglichkeiten aus anderen Netzen ins MWN (z.B. über VPN, UMTS) werden auch mobile Nutzer
im MWN mittels WLAN angebunden. Für Veranstaltungen und Konferenzen gibt es Konzepte, um einen
Zugang ins Internet oder ins MWN zu realisieren. Der reisende Wissenschaftler wird durch eduroam, und
einem damit verbundenen, sehr einfachem Zugang zum Netz unterstützt. Daneben werden Basisdienste
wie Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Service Load Balancer (SLB), Proxies und Zeitschriftenzugänge sowie die nächste Generation des IP-Protokolls (IPv6) angeboten. Außerdem betreibt das LRZ eine Voice over IP (VoIP) Anlage für die Telefonie. Diese unterstützenden Netzdienste werden im Folgenden vorgestellt.
3.2.1 Wählzugänge (Modem/ISDN)
Die Anzahl der Wählverbindungen hat sich im Laufe des Jahres 2010 weiter verringert. Die Anzahl der
Telekom-Kunden ging auf ca. 80 (2009: 160) zurück, die der M-net-Kunden stagnierte bei ca. 70.
Abbildung 49 zeigt für das zweite Halbjahr 2010 die maximale Anzahl gleichzeitig aktiver Verbindungen
pro Woche, aufgeschlüsselt nach den jeweiligen Rufnummern.
Abbildung 49: Maximale Anzahl von Verbindungen pro Rufnummer des zweiten Halbjahres 2010
Der Wochenüberblick zeigt bei den M-net-Verbindungen das Ansteigen werktags um 18 Uhr (vgl. Abbildung 50).
114
Abbildung 50: Verteilung der Modem/ISDN-Verbindungen im Wochenüberblick
Ü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 oder Eduroam selbst verwalten.
Zum Jahresende 2010 waren 55 Radiuszonen konfiguriert.
Eine Auflistung der Radiuszonen zeigt Tabelle 31:
Zonenbezeichnung
aci.ch.tum
ads.mwn.de
binfo.wzw.tum.de
bl.lmu
bsbmuenchen
campus.lmu.de
cicum.lmu
cip.informatik.lmu
cipmath.lmu
eduroam.mwn.de
edv.agrar.tum
fhm.de
fhforst.tum
frm2.tum
fsei.tum
fsmpi.tum
hm.edu
ibe.lmu
ikom.tum
info.tum
lkn.tum
lmu.de
lmupsychologie
lpr.tum
lrz.de
math.lmu
math.tum
med.lmu
med.lmu.de
Institut
Lehrstuhl für Anorganische Chemie TUM
Kennungen im MWN-ADS
Genome oriented Bioinformatics
Beschleunigerlabor der TU und der LMU München
Bayerische Staatsbibliothek
Internet und virtuelle Hochschule (LMU)
Department Chemie LMU
Institut für Informatik der LMU
Mathematisches Institut LMU
Eduroam-Nutzer
Datenverarbeitungsstelle der TU in Weihenstephan
Hochschule München
Hochschule Weihenstephan-Triesdorf
Forstwissenschaftliche Fakultät
Forschungsreaktor
Fachschaft Elektro- & Informationstechnik
Fachschaften MPI
Hochschule München
Institut für medizinische Informationsverarbeitung, BioFachschaft Elektro- & Informationstechnik
Informatik TUM
Lehrstuhl für Kommunikationsnetze
Verwaltung LMU
Depart für Psychologie
Lehrstuhl für Prozessrechner
LRZ-Mitarbeiter
Mathematisches Institut LMU
Zentrum Mathematik TU München
Medizin der LMU, Großhadern
Medizin der LMU, Großhadern
meteo.lmu
mytum.de
org.chemie.tum
phy.lmu
physik.lmu.de
radius.wzw.tum
rcs.tum
regent.tum
rz.fhm
staff.fhm
studext
studlmu
tec.agrar.tum
tphys.lmu
tum.de
usm
usm.lmu
vm08.fhm
wzw.tum
zi.lmu
zikgwpa
zv.tum
115
Meteorologisches Institut LMU
Mitarbeiter und Studenten der TUM
Institut für Organische Chemie und Biochemie Lehrstuhl
Fakultät für Physik der LMU
Fakultät für Physik der LMU
Informationstechnologie Weihenstephan (ITW)
Lehrstuhl für Realzeit-Computersysteme
Lehrstuhl für Rechnergestütztes Entwerfen
Rechenzentrum der FH München (Studenten)
Rechenzentrum der FH München (Mitarbeiter)
Studentenrechner LRZ (andere)
Studentenrechner LRZ (LMU)
Institut für Landtechnik Weihenstephan
Institut Theoretische Physik LMU
Mitarbeiter und Studenten der TUM
LMU Sternwarte
LMU Sternwarte
Fachbereich 08, FH München
Informations-Technologie Weihenstephan
Zoologisches Institut der LMU
Zentralinstitut für Kunstgeschichte
Zentrale Verwaltung TUM
Tabelle 31: Radiuszonen im MWN
3.2.2 VPN
Im MWN werden Virtual-Private-Networks in folgenden Szenarien eingesetzt:
• Zugang über vom LRZ betreute WLANs.
• Zugang über öffentliche Anschlussdosen für mobile Rechner.
• Zugang zu internen MWN-Diensten (z.B. Online-Zeitschriftenangebot der Universitätsbibliotheken)
für Bewohner von Studentenwohnheimen.
• Zugang zu internen MWN-Diensten über das Internet.
3.2.2.1
Technik
Die VPN-Hardware besteht aus vier Appliances vom Typ „Adaptive Security Appliances ASA5540“ und
einer Appliance vom Typ „VPN-Concentrator 3030“ der Firma Cisco. Der VPN-Concentrator 3030 dient
für die Anbindung von externen Einrichtungen außerhalb des MWN über IPsec LAN-to-LAN Tunnel.
Die vier ASA-Appliances sind zu einem VPN-Cluster zusammengefasst. Dieser VPN-Cluster wird von
IPsec-Clients unter der Adresse ipsec.lrz.de, von SSL-VPN-Clients unter der Adresse asa-cluster.lrz.de
angesprochen. Die Nutzer werden beim Anmelden mit der am geringsten ausgelasteten Appliance verbunden. Der VPN-Concentrator 3030 ist über zwei 100 MBit/s Anschlüsse (öffentlich und privat) angeschlossen. Die vier ASA5540 sind jeweils mit 1GBit/s angeschlossen. Die verfügbare Bandbreite für verschlüsselte Verbindungen (AES/3DES) beträgt 50 MBit/s beim VPN-Concentrator 3030 und 350 MBit/s
pro ASA5540. Authentifizierung, Autorisierung der Nutzer sowie Accounting werden über das RADIUSProtokoll abgehandelt.
3.2.2.2
VPN-Software
Berechtigte Nutzer können die aktuellen Versionen der VPN-Software vom Web- oder VPN-Server des
LRZ herunterladen. Für Linux und Mac OS X stehen neben den Cisco-IPsec und AnyConnect-Client der
„Open Source“ VPN-Client vpnc (IPsec) und openconnect (SSL-VPN) zur Verfügung, der erfahrenen
116
Nutzern erweiterte Möglichkeiten bietet. Diese Clients sind inzwischen in den Standarddistributionen wie
z.B. Debian, SuSE und Ubuntu enthalten.
3.2.2.3
Telearbeitsplätze von LRZ-Mitarbeitern
Mitarbeiter nutzen die internen Ressourcen des LRZ während ihrer Arbeit zu Hause. Dazu erhalten sie
einen VPN-Router, an den sie Rechner und VoIP-Telefon anschließen können. Der VPN-Router ist so
konfiguriert, dass er automatisch eine Verbindung zum VPN-Server im LRZ aufbaut. Über diese 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 IPTelefon zur Verfügung. Bei dem VPN-Router handelt es sich um das Modell WRV54G von Linksys. Das
Telefon ist an der VoIP-Telefonanlage des LRZ angeschlossen und so konfiguriert, dass der Mitarbeiter
am Heimarbeitsplatz mit der gleichen Telefonnummer wie an seinem Arbeitsplatz am LRZ erreichbar ist.
3.2.2.4
Entwicklung des Datenverkehrs über die VPN-Server
Im Monat November, dem Monat mit dem höchsten Datenaufkommen, stieg der Durchsatz im Vergleich
zum Vorjahr um 45%. In Spitzenzeiten waren bis zu 3200 Nutzer parallel angemeldet, täglich wurden bis
zu 30.000 Verbindungen aufgebaut. Der im Jahr 2009 eingeführte SSL-VPN Client (Cisco AnyConnect)
hat inwischen einen Anteil von 30% aller Verbindungen erreicht.
Folgende Aufteilung nach Betriebsystemen ergab sich bei den IPsec-Verbindungen (Referenzmonat November): Linux 8%, iOS 15%, Mac OS X 29%, Windows 49%. Bei den SSL-VPN Verbindungen ist eine
Aufschlüsselung nach Betriebsystemen nicht möglich.
Jahr
Ausgehend Eingehend Gesamt
2005
0,7
3,2
3,9
2006
1,7
6,2
7,9
2007
3,1
11,4
14,5
2008
3,8
12,7
16,5
2009
4,6
20,7
25,3
2010
8,0
28,8
36,7
Tabelle 32: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November
40
30
20
Ausgehend
Eingehend
Gesamt
10
0
2005 2006 2007 2008 2009 2010
Abbildung 51: Datenverkehr in Terabytes über die VPN-Server im Referenzmonat November
117
3500
3000
2500
2000
1500
1000
500
0
31.12
31.01 28.02
31.03
30.04
31.05
30.06
31.07
31.08
30.09
31.10
30.11
31.12
Abbildung 52: Anzahl der gleichzeitig an den VPN-Servern angemeldeten Nutzer
40,000
35,000
30,000
Eingehend
Ausgehend
Summe
25,000
20,000
15,000
10,000
5,000
0,000
Abbildung 53: Monatliches Datenvolumen der VPN-Server in Gigabyte im Jahr 2010
3.2.3 DFN-Roaming
Das LRZ nimmt seit Anfang 2005 am DFN-Roaming-Dienst des DFN (Deutsches Forschungsnetz) Vereins teil. Damit ist es den Wissenschaftlern möglich, mittels einer vorhandenen Kennung ihrer HeimatHochschule einen einfachen Zugang ins Internet zu erhalten, wenn sie sich im Bereich des MWN aufhalten. Als Zugangspunkte dienen die vorhandenen WLAN-Accesspoints (an praktisch allen Standorten).
In der erweiterten Form mit der SSID 'eduroam' statt '802.1X' ist nicht nur das Roaming innerhalb
Deutschlands, sondern auch in vielen Länden Europas und in Australien möglich. Auch in den USA beginnen sich die ersten Universitäten zu beteiligen.
Die SSIDs 'eduroam' und '802.1X' werden auf fast allen Accesspoints im MWN zur Verfügung gestellt.
Nur an 2 Standorten mit je einem Accesspoint, die über DSL-Leitungen angeschlossen sind, war es aus
technischen Gründen nicht möglich, das DFN-Roaming anzubieten.
Neben der bisher im Bereich des MWN obligaten Methode TTLS/PAP wurde 2010 auch die Authentifizierung über PEAP/ MSCHAPv2 ermöglicht. Dies wurde erforderlich, da Windows 7 Systeme diesen
Dienst nur mit kostenpflichtiger Zusatzsoftware TTLS/PAP nutzen können. Außerdem wurde der von
vielen Systemen bisher benutzte Client (SecureW2) nicht mehr kostenfrei angeboten. Aus diesen Gründen
118
wurde ein eigenes Windows-basiertes Directory für Eduroam mit Anbindung an das IdentityManagement-System des LRZ eingerichtet. Mittels PEAP können nun Systeme mit Windows 7 und viele
Smartphones Eduroam ohne zusätzliche kostenpflichtige Software nutzen.
Das nachfolgende Bild zeigt die Benutzungs-Statistik für das 802.1X/eduroam.
Abbildung 54: Anzahl der Eduroam-Nutzer im Jahr 2010
3.2.4 Unterstützung von Veranstaltungen
Das LRZ richtet für Veranstaltungen im Münchner Wissenschaftsnetz (MWN) bei Bedarf ein spezielles
Netz ein, damit die Tagungsteilnehmer das Netz ohne besondere Authentifizierung nutzen können. Hierbei wird davon ausgegangen, dass die Nutzer dieses Netzes nicht unbedingt aus dem Kreise der Münchner Hochschulen stammen, sondern auch Firmen u. dgl. das Internet und das MWN ohne spezielle Vorkehrungen (ohne VPN-Client-Installation, ohne Validierung) nutzen sollen. Eine Anmeldung und die bei
frei zugänglichen Netzanschlüssen ansonsten obligatorische Verwendung eines VPN-Zugangs werden
hier nicht gefordert.
Diese „offene" Konfiguration bleibt auf den Zeitraum und den Ort der Veranstaltung begrenzt. Der Zugang ist drahtlos (WLAN nach IEEE 802.11b/g/n) möglich. Nur in Ausnahmefällen werden feste Netzanschlussdosen (100 Mbit/s LAN) zur Verfügung gestellt. Für Geräte, die keine eingebaute Funkschnittstelle haben, werden vom LRZ Wireless-Client-Bridges (WCB) bereitgestellt. Die Realisierbarkeit des
Dienstes hängt aber von der vorhandenen Infrastruktur ab, nicht in allen Gebäuden und Räumen ist eine
solche Möglichkeit gegeben. Allerdings ist dies meistens der Fall.
Der Zugang wird seit 2006 bevorzugt per WLAN zur Verfügung gestellt. Der Netzname (SSID) ist dabei
´con´. Es wird keine Verschlüsselung verwendet, um Probleme mit der Weitergabe und Einstellung der
Schlüssel zu vermeiden. Für länger dauernde Kurse oder auf Wunsch des Veranstalters werden aber auch
verschlüsselte Netze eingerichtet.
Für reisende Wissenschaftler gibt es außerdem die Möglichkeit, sich mittels eduroam (vgl. Abschnitt
3.2.3) mit der Kennung ihrer Heimat-Universität im Netz anzumelden und verschlüsselt zu kommunzieren. In den letzten Jahren wird dieser Dienst vermehrt auch bei Veranstaltungen genutzt. Das heißt, diese
sichere Art der Kommunikation setzt sich immer mehr durch.
2010 wurden 215 Veranstaltungen unterstützt (42 mehr als im Vorjahr).
119
Datum
Veranstaltung
Datum
Veranstaltung
10.06.2010-11.06.2010
10JahreVHB-2010
02.08.2010-03.08.2010
IPComm-2010
25.11.2010-26.11.2010
10_Jahre_VHB
03.12.2010-05.12.2010
ISARMUN-2010
19.06.2010-24.06.2010
22-IKOM-2010
28.10.2010-31.10.2010
ISMA-2010
22.07.2010-23.07.2010
ADG-2010
04.03.2010-05.03.2010
ISO20K-Maerz2010
11.10.2010-13.10.2010
ASCENS-2010
12.07.2010,25.07.2010-28.07.2010
ISSAC-2010
23.11.2010
Abschlusskolloquium_SFB453-2010
23.02.2010-24.02.2010
IVK2010
13.04.2010-16.04.2010
Adipositas-2010
02.07.2010
Ideenboerse-LfP-2010
20.09.2010
Agrarwissenschaftliches_Symposium-2010
14.06.2010
ImmerSence-Juni2010
05.10.2010-09.10.2010
Alpenforum-2010
20.07.2010
InKoMBio-2010
15.02.2010-17.02.2010
Annex54-2010
21.10.2010
Infoblox-Meeting
02.11.2010
Apple_on_Campus-Event2010
03.12.2010-05.12.2010
Integration_hoergeschaedigter_Kinder-Dez2010
25.11.2010-26.11.2010
Architektur-Konferenz-Dez2010
14.04.2010-15.04.2010
Intel_Round_Tabelle-April2010
18.11.2010
Autodesk-Nov2010
22.03.2010-23.03.2010
Interact-2010
23.09.2010
BRZL-AK-2010
11.05.2010
International_Day_HM-2010
15.04.2010
BULL-April2010
29.11.2010-03.12.2010
Internationale-Woche-TUM-2010
18.11.2010-19.11.2010
Biofilm-Nov2010
24.11.2010
Internationaler_Tag-NOV2010
15.04.2010-19.04.2010
Bright-2010
22.08.2010-29.08.2010
Isotopeschool-08-2010
02.12.2010
Britische-Hochschulmesse-2010
04.10.2010-08.10.2010
Iterative-Gleichungssystemloeser-und-Parallelisierung
21.05.2010
Bull-05-2010
01.12.2010
JOBcon-Finance-2010
10.06.2010
CC-Fachtagung-FK07-2010
07.05.2010
KIT-Mai2010
15.03.2010
CISCO-Besprechung
21.09.2010,23.09.2010-24.09.2010
Kanzlertagung-WZW-2010
12.10.2010-13.10.2010
COIN-Okt-2010
17.11.2010
KinderUni-2010
18.03.2010-19.03.2010
COST_Action_D41-2010
11.02.2010-22.02.2010
Klimagerechtes_Bauen-2010
21.10.2010-23.10.2010
CRC-Symposium-2010
07.09.2010
LERU-2010
16.08.2010
Chemistry-meets-Biology-2010
26.07.2010-27.07.2010,29.07.2010-30.07.2010
LSR-SummerSchool-2010
06.12.2010
Chinese-Delegation-Dez2010
17.11.2010,21.11.2010
Landesastenkonferenz-Nov2010
02.06.2010
Cisco_Ironport-Juni2010
14.10.2010-15.10.2010
Largecells_Kickoff_Meeting-Okt2010
04.02.2010
Cloud_Computing_LRZ-2010
18.11.2010
Leading-Entrepreneurs-Nov2010
13.10.2010-14.10.2010
CoTeSys-Workshop-Okt2010
23.06.2010
Lehrerfortbildung-Informatik-2010
09.07.2010
Concrete-Causation-2010
02.07.2010,03.07.2010
MHS-2010
26.04.2010-27.04.2010
CoteSys-Course-April2010
16.03.2010-17.03.2010
MMK-2010
12.03.2010
Courses_in_English-2010
16.03.2010
MMK-20109
09.02.2010-11.02.2010
DEISA-Meeting-Feb2010
05.10.2010
MMS-2010
29.06.2010 30.06.2010
DEISA2_Review-Juni2010
09.07.2010
Marketing-Symposium-2010
10.05.2010 11.05.2010
DES-2010
14.05.2010-16.05.2010
Marokkanischer_Verein-2010
13.04.2010-16.04.2010
DFG-FOR538-April2010
04.11.2010-05.11.2010
Megacities-2010
05.03.2010
DFG-Schwerpunkt-05.03.2010
17.03.2010
Menschliche_Zuverlaessigkeit-2010
07.07.2010-09.07.2010
DFG-Tagung-IMETUM-Juni-2010
26.11.2010
Mentor_meets_Mentee-Nov2010
07.10.2010-09.10.2010
DG-GT-Meeting-2010
09.03.2010-12.03.2010
Metabolomics_and_More-2010
27.09.2010-28.09.2010
DGSI-Sept2010
03.02.2010
Microsoft-Roadshow-2010
04.11.2010-07.11.2010
DPT-2010
04.02.2010-05.02.2010
Mittelstandssymposium-2010
04.08.2010-05.08.2010
DRIHM-Proposal-Meeting-2010
30.04.2010
Moodle-2010
17.05.2010-18.05.2010
DRIHMS-MAI-2010
06.12.2010
Moskau-Delegation
25.02.2010,03.03.2010-05.03.2010
DZT-2010
18.05.2010-19.05.2010
Muenchener_Unternehmenstag-2010
120
23.02.2010-24.02.2010
Design_und_Elektronik-2010
19.10.2010-20.10.2010
NIXU-Workshop-2010
02.09.2010-03.09.2010
Double-Chooz-Experiment-2010
30.03.2010
Nanocem-2010
07.05.2010-09.05.2010
DrupalDevDays-2010
05.10.2010
Netzneutralitaet-Okt-2010
23.08.2010-27.08.2010
EARLI_SIG_14-2010
14.10.2010-16.10.2010
Niere-2010
04.05.2010-05.05.2010
EFSA-2010
08.03.2010-09.03.2010
OASE-Projektmeeting-Maerz2010
17.12.2010
EGI-InSPIRE-PMB-2010
14.03.2010-20.03.2010
OGF28-2010
14.10.2010-16.10.2010
EGU_Fall-2010
04.10.2010-06.10.2010
Oekolandbau-Okt-2010
06.09.2010-09.09.2010
EHEDG-Seminar-Sept2010
04.12.2010-05.12.2010
Open-HW_SW-Event
07.10.2010-09.10.2010
ELOA-2010
02.12.2010
PDF_und_Geodaten_II-2010
13.09.2010
EPS-EWG-2010
15.01.2010
PERC-2010
24.06.2010
ERC-2010
30.08.2010-31.08.2010
PRACE-Kickoff-Mtg-2010
28.09.2010-02.10.2010
ESF-COST-A32-2010
01.03.2010-02.03.2010
PRACE_Workshop-Maerz2010
12.04.2010-13.04.2010
ETG-Workshop-2010
05.05.2010
PROSPECT-Mai2010
26.11.2010-27.11.2010
EU-Project-FP7-Nov2010
13.10.2010
PROSPECT-Okt2010
14.10.2010
EXASCALE-Meeting-Okt2010
20.12.2010
PROSPECT_STRATOS-2010
27.10.2010
EXPO-Wege-ins-Ausland-Okt2010
20.09.2010-24.09.2010
PWA-Workshop-2010
26.08.2010-27.08.2010
EcoMove-AUG2010
15.10.2010
PWiB-2010
14.09.2010-15.09.2010
EcoMove-SEPT2010
06.12.2010
ParTec-MSU-Dez2010
14.09.2010-17.09.2010
Economics_of_Food-2010
11.05.2010
Personalmesse-AUDIT-2010
08.10.2010-09.10.2010
Ernmed-2010
18.05.2010
Personalmesse-CONSULTING-2010
27.09.2010-01.10.2010
ExMar-2010
05.05.2010
Personalmesse-MEDIEN-2010
18.06.2010
Exascale-FS-2010
12.05.2010
Personalmesse-RECHT-2010
18.05.2010
FET-MAI-2010
11.03.2010-25.03.2010
Pervasive_Health-2010
27.09.2010
FH-RZ-Leiter-Sept2010
06.10.2010-07.10.2010
PhiBot10-2010
27.11.2010
FIRST_LEGO_League-November2010
13.12.2010
Pressekonferenz-SuperMUC-2010
12.04.2010-16.04.2010
FOG-April2010
06.10.2010
Produktionskongress-2010
17.07.2010-18.07.2010
FUH-psy2-ss10-2010
24.02.2010-26.02.2010
Reprotagung-2010
13.08.2010-15.08.2010
FernUni-2010-Bod
23.04.2010-24.04.2010
Roboticswettbewerb-April_2010
14.10.2010-16.10.2010
FernUni-2010-PsyE
22.02.2010-26.02.2010
SENSORIA-Feb2010
08.04.2010-10.04.2010
FernUni-EL-2010
08.10.2010
SFB453-Okt2010
12.06.2010
FernUni-Neve-Mai2010
01.03.2010-03.03.2010
SFB607-2010
31.05.2010-02.06.2010
Firmenkontaktgespraech-LMU-2010
03.03.2010
STRATOS-Meeting-Maerz2010
24.03.2010-25.03.2010
Forstlicher-Unternehmertag-2010
11.05.2010
Sophos-Tag-Mai2010
26.04.2010-27.04.2010
Forum_der_Lehre-2010
05.10.2010
Spiegelausschuss-2010
05.10.2010-08.10.2010
Freiflaechenworkshop-Okt-2010
04.10.2010,11.10.2010-14.10.2010
Stat-Woche-M2010
15.10.2010
Fundraisingtag_Muenchen-2010
07.12.2010
Stratos-Management-Board-Dez2010
16.06.2010-17.06.2010
G-Node-Symposium-2010
27.10.2010
Studienfinanzierung-2010
05.03.2010-12.03.2010
GDM-2010
20.03.2010
Studieninformationstag-2010
04.10.2010-06.10.2010
GEARS-2010
16.10.2010
Studieninfotag-Okt2010
06.07.2010
GI-Herausgebertreffen-2010
19.11.2010-22.11.2010
Studieren-Down-Under-2010
18.03.2010-19.03.2010
GMA-ELearning-2010
26.07.2010-06.08.2010
Summer-School-2010
15.03.2010-17.03.2010
GPZ2010
18.05.2010
SuperMUC-SGI-2010
20.05.2010
GROW-2010
10.03.2010-16.03.2010
THIS-Maerz2010
27.09.2010-29.09.2010
Ganga-Developer-Sept2010
08.07.2010-09.07.2010
TIME-Meeting-2010
09.12.2010-10.12.2010
Geist-Gehirn-Maschine-2010
28.10.2010-29.10.2010
Technologieseminar-Okt-2010
121
04.11.2010-05.11.2010
Geodaesie-Nov-2010
24.03.2010
Telekom_Stiftung-2010
10.03.2010-11.03.2010
Geoinformationssysteme-2010
19.03.2010
TextGrid-2010
05.08.2010-07.08.2010
GlobalHands-2010
17.05.2010-20.05.2010
Thermoacoustics-Mai-2010
25.06.2010
Governance-Network-2010
10.06.2010
Unternehmertag-2010
29.11.2010-01.12.2010
Gradewood-2010
04.06.2010-07.06.2010
VDE-Fallstudien-2010
08.04.2010-10.04.2010
HETDEX-2010
01.05.2010-02.05.2010
VDI-Aktiven-Treffen-2010
14.07.2010
HP-Networking-Day-2010
14.10.2010-15.10.2010
VERCE-Okt-2010
21.04.2010
HP-Procurve-Manager-April2010
11.03.2010,15.03.2010,17.03.2010-19.03.2010
Vertragsverhandlungen-SuperMUC-2010
02.11.2010-03.11.2010
HoKo-2010
08.10.2010,12.10.2010-13.10.2010
Vorkurs-Physik-Herbst2010
22.10.2010
IAS-Symposium-Okt2010
07.10.2010-08.10.2010
WMHT-2010
29.11.2010-03.12.2010
IATUL-Tagung-NOV2010
22.02.2010-24.02.2010
WS_Vegetationsoekologie-Feb2010
01.06.2010
ICS-Symposium-Juni2010
22.10.2010-26.10.2010
Wissenschaftstage-Okt-2010
28.06.2010-01.07.2010
ICTON-2010
06.12.2010-10.12.2010
Workshop_Fluorescence_Imaging-2010
23.06.2010
IFO-Jahresversammlung-2010
19.02.2010
ZHS-Alumni-Feb2010
23.07.2010-31.07.2010
IFTR-2010
10.11.2010-11.11.2010
ZKI_IT-Strategietagung-2010
18.10.2010-19.10.2010
IGE-KickOff-Meeting-Okt2010
15.04.2010-17.04.2010
Ziel-Seminar-Apr2010
26.11.2010
IGSSE_Meeting-Nov2010
18.02.2010-20.02.2010
Ziel-Seminar-Feb2010
20.01.2010
IKOM_Bau-2010
29.09.2010-30.09.2010
excelence-day-Sep-2010
05.05.2010
IKOM_Life_Science-2010
14.01.2010
Interne Sitzung (VER:_GSISSH-Vorführung)
11.10.2010-13.10.2010
IMAPS_Konferenz-2010_
14.04.2010-16.04.2010
mfk2010
Tabelle 33: Liste der unterstützten Veranstaltungen im Jahr 2010
Auch im Jahr 2010 wurden für die Unterstützung der Konferenzen teilweise schon vorhandene Access
Points gegen neuere ausgetauscht, um den erhöhten Bedarf abdecken zu können. Damit können Konferenz-Teilnehmer mit neueren Laptops Transfer-Raten bis zu 300 Mbit/s erreichen und geben dadurch den
Funkkanal schneller wieder für andere Teilnehmer frei.
Außerdem wurden öfters Access Points anlässlich einer Veranstaltung neu aufgebaut, die ansonsten erst
zu einem späteren Zeitpunkt eingerichtet worden wären.
Eine Verteilung der Konferenzen auf die einzelnen Monate zeigt die Statistik in Abbildung 55. Erwartungsgemäß werden die Hörsäle vor allem in vorlesungsfreien Zeiten für Konferenzen genutzt.
Abbildung 55: Konferenzen im Verlauf des Jahres 2010
122
3.2.5 Internet-Zugang
Der Zugang zum weltweiten Internet wird über das Deutsche Wissenschaftsnetz (WiN) realisiert. Im Jahr
2010 war das MWN technisch mit einer 10 Gbit/s-Schnittstelle am WiN angeschlossen. Derzeit ist ein
zweistufiges Ausfallkonzept mit Backups für den Internetzugang umgesetzt (s.u).
Die monatliche Nutzung (übertragene Datenmenge) des WiN-Anschlusses seit Juni 1996 zeigt Abbildung
56
Abbildung 56: Entwicklung der Nutzung des WiN-Anschlusses des MWN (in GByte/s)
Die Steigerungsraten - bezogen auf die jeweils im Vorjahr transportierte Datenmenge - sind in Abbildung
57 graphisch dargestellt. Seit dem Jahr 1999 hat die Datenmenge auf die 100-fache Menge zugenommen.
1,0
1,0
2001
2002
1,4
1,4
2003
2004
1,5
2005
1,7
1,9
1,9
1,6
1,4
2006
2007
2008
2009
2010
Abbildung 57: Steigerungsraten beim übertragenen Datenvolumen
Seit September 2003 ist der WiN-Anschluss vertragstechnisch ein so genannter Clusteranschluss, bei dem
die vom MWN versorgten teilnehmenden Institutionen als eigenständige Partner mit eigenem Tarif bezogen auf den eingehenden Datenverkehr aufgefasst werden. Zu diesem Zweck wurden die laufenden Mes-
123
sungen kumuliert, um eine Verteilung des Datenverkehrs zu bekommen. Die prozentuale Verteilung des
Datenvolumens am WiN-Zugang (Messzeitraum November 2010) zeigt Tabelle 34.
Institution
LRZ und BAdW
TUM
LMU
Hochschule München
Sonstige
Hochschule Weihenstephan
Gate
Total Bytes %
78,1
8,7
8
1,6
2,5
0,9
0,2
Tabelle 34: Prozentuale Verteilung des Datenverkehrs am WiN-Zugang
Die prozentuale Verteilung des gesamten Verkehrs gegenüber Werten des Vorjahres hat beim LRZ um
7% zugenommen. In etwa im gleichen Verhältnis hat der Verkehr bei der TUM abgenommen.
Die technische Realisierung der Anbindung des MWN an das Internet zeigt Abbildung 58:
Abbildung 58: Anbindung des MWN an das Internet
Der Standardzugang zum Internet ist über das vom DFN betriebene Wissenschaftsnetz (WiN) realisiert.
Der WiN-Anschluss des LRZ erfolgt über das IPP (Max-Planck-Institut für Plasmaphysik) in Garching
mit einer Anschlußbandbreite von 10 Gbit/s. Dort wurde vom DFN der zugehörige WiN-Kernnetz-Router
installiert. Derzeit ist ein zweistufiges Ausfallkonzept für den Internetzugang umgesetzt.
1. Falls die Hauptleitung zwischen LRZ und IPP oder eines der entsprechenden Interfaces an den
beiden Routern ausfallen sollte, wird automatisch auf den Backup-Link zwischen Maschinenwesen und IPP umgeschaltet. Durch diese Backup-Verbindung entstehen keine zusätzlichen Kosten.
2. Sollten beide Leitungen oder aber der Kernnetzrouter des DFN in Garching ausfallen, wird ohne
merkliche Unterbrechungen für den Benutzer auf eine über M-net realisierte Backup-Verbindung
umgeschaltet. Die Backup-Verbindung zum Internet wird über eine LWL-Strecke mit 1 Gbit/s
124
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 2010 wurde die Backup-Strecke in sechs Fällen aktiv. In der Regel handelte es sich dabei um sehr
kleine Störungen und der Backup war nur für wenige Minuten aktiv. Am 27.08.2010 kam es zu RoutingProblemen im X-WiN. Auslöser war ein Test von RIPE und ein Software-Fehler in einigen DFNRoutern. Bei diesem Vorall wurde der Verkehr für knapp zwei Stunden über die Backup-Strecke abgewickelt.
3.2.6 Service Load Balancer (SLB)
3.2.6.1
Big-IP-3400
Die beiden Big-IP-3400 Server Load Balancer von F5 Networks sind schon seit 2006 produktiv mit großem Erfolg im LRZ im Einsatz. Über sie laufen Dienste wie Webserver, Radiusproxies, Zeitschriftenproxies und SSH-Logins für das Linux-Cluster.
Weitere technische Informationen dazu sind in den Jahresberichten der Vorjahre zu finden.
3.2.6.2
Big-IP-8900
Für das Projekt Hochschulstart.de wurden im Oktober 2010 zwei Big-IP-8900 Server Load Balancer beschafft. Diese werden zunächst nur für Hochschulstart.de (vgl. Abschnitt 2.9) eingesetzt. Ab Februar
2011 sollen sie dann die beiden Big-IP-3400 ersetzen. Alle Dienste werden dann umgezogen.
Technische Daten der Big-IP-8900:
• 2x AMD Quad Core 2,2 GHz
• 2x 320 GB Festplatte als Raid 1
• 16 GB RAM
• Hauptanbindung: 2x 10 Gb-Ethernet-Glasfaser
• 8 x 1 Gb-Ethernet-Glasfaser (2x nur intern genutzt)
• 16 x 1 Gb-Ethernet-Kupferkabel (2x für Serveranbindung genutzt)
• Max. 58.000 SSL-Transaktionen pro Sekunde in Hardware.
3.2.7 Proxies und Zeitschriftenzugang
Das Angebot der elektronischen Zeitschriften und Datenbanken wurde von den Universitätsbibliotheken
weiter ausgebaut. In vielen Fakultäten ist es eine wichtige Informationsquelle für Mitarbeiter und Studenten. Viele Studenten recherchieren auch von zu Hause, wo sie meist über einen DSL-Anschluss mit Flatrate verfügen.
3.2.7.1
Webplattform für den Zeitschriftenzugriff
Die vom LRZ betriebene Webplattform DocWeb (http://docweb.lrz-muenchen.de) wurde am 31.12.2010
eingestellt, da die zugrundeliegende Software (CGIProxy) nicht mehr weiter gepflegt wird und zunehmend Probleme mit dynmischen Webseiten (vor allem mit Javascript) machte. Das führte dazu, dass viele
Zeitschriftenzugänge und Zeitschriften nicht mehr benutzbar waren, da ständig JavascriptFehlermeldungen erschienen oder die Webseiten keinen sinnvollen Inhalt mehr anzeigten.
Die Universitätsbibliothek der TU-München hat mit eAccess (https://eaccess.ub.tum.de :2443/login) seit
Sommer 2010 einen Nachfolger am Start. Nutzer der LMU können nur noch den Zugang über VPN verwenden.
3.2.7.2
125
Shibboleth
Für die Bibliothekszwecke wird das Authentifizierungsverfahren Shibboleth eingesetzt. Als verlagsübergreifendes Authentisierungsverfahren Shibboleth ist es zwar schon seit einiger Zeit bei beiden Bibliotheken im produktiven Einsatz, allerdings beteiligen sich daran zurzeit nur große Verlagshäuser. Bei Shibboleth wird der Nutzer von der Verlagsseite direkt zu einer Authentifizierungseite des LRZ umgeleitet und
muss sich nur einmal für einige Stunden und beliebige teilnehmende Verlage einloggen. VPN oder ein
spezielles Webportal sind dann nicht mehr notwendig.
3.2.8 Domain Name System
Neben IPv4- werden auch IPv6-Einträge unterstützt. Der Webdns-Dienst wird inzwischen von 255 Nutzern zur Pflege der DNS-Einträge verwendet. Die Anzahl der über Webdns verwalteten DNS-Zonen stieg
(von 1688) auf 1857. Es wurden 123 neue Domains unter verschiedenen Toplevel-Domains (z.B. de, org,
eu) für Institute und Organisationen registriert oder von anderen Providern transferiert.
Abbildung 59 und Abbildung 60 zeigen die Frequenz der Anfragen für den autoritativen und ResolvingDienst über 7 Tage (6.12.2010 – 12.12.2010).
Abbildung 59: Statistik für alle DNS-Server (Autoritativ)
Abbildung 60: Statistik für alle DNS-Resolver
Eine Übersicht aufgeteilt nach Domains im MWN zeigt Tabelle 29. Die reale Anzahl der Zonen und Einträge ist um einiges höher, kann aber nicht ermittelt werden, da manche der von den Instituten selbst betriebenen DNS-Server keine Auflistungs-Abfragen beantworten.
126
Domain
Anzahl
Anzahl
Zonen
Sub-Domains
Anzahl
ARecords
Anzahl Anzahl
AAAARecords Aliase
Anzahl
MX-Records
uni-muenchen.de
359
2879
26025
1383
4113
3572
lmu.de
104
2076
3744
272
1636
2933
tu-muenchen.de
286
7257
18831
340
1967
7687
tum.de
323
2466
10429
593
2590
1959
fh-muenchen.de
50
288
3566
0
233
525
hm.edu
68
228
7509
0
228
307
3
18
114
0
48
2
fhweihenstephan.de
hswt.de
badwmuenchen.de
1
6
61
0
39
2
25
74
28
0
29
92
badw.de
24
70
1
0
63
82
lrz-muenchen.de
72
185
6669
901
1120
55
lrz.de
59
128
20394
286
588
14
mhn.de
62
321
78113
40
1263
274
mwn.de
42
117
2914
113
269
26
Sonstige
503
683
2495
63
788
501
Gesamt
1981
16796
180893
3991
14974
18031
Tabelle 35: Domains im MWN
3.2.8.1
Teilnahme am deutschen DNSSEC-Testbed
Die Einführung der Domain Name System Security Extensions (DNSSEC), einer Erweiterung des DNS,
mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden, wurde angegangen. Das LRZ hat hierzu die ersten Domains (z.B. mwn.de) digital signiert und nimmt am DNSSECTestbed der DENIC (zentrale Regesteriungsstelle für alle .de-Domains) teil. Dabei war das LRZ im zweiten Halbjahr 2010 der (nach Abfragen gemessen) mit Abstand größte Teilnehmer am DNSSEC-Testbed.
Die Erfahrungen und Ergebnisse wurden in einem Vortrag beim DENIC-DNSSEC-Workshop, einem
zusammen mit Nixu Software organisierten Workshop für universitäre Anwender aus ganz Deutschland
im LRZ, sowie in vielen Einzelgesprächen, verarbeitet. Das LRZ hat sich dadurch einen Namen in diesem
Bereich erarbeitet und wird diesen Kurs im nächsten Jahr fortsetzen.
3.2.9 DHCP-Server
Seit ca. acht Jahren betreibt das LRZ einen DHCP-Dienst, der von allen Münchener Hochschulen für die
automatische IP-Konfiguration von institutsinternen Rechnern genutzt werden kann. Außerdem wird dieser Dienst für einige zentrale Anwendungen verwendet, wie z.B. für die WLAN-Zugänge im MWN oder
die Netzanschlüsse in Hörsälen und Seminarräumen. Insgesamt wird der DHCP-Dienst von ca. 250 Instituten genutzt und verwaltet dabei ungefähr 670 Subnetze mit knapp 90.000 IP-Adressen. Falls gewünscht,
tragen die DHCP-Server die Namen der Clients auch automatisch in den zuständigen DNS-Server ein
(Dynamic DNS).
127
Physisch betrachtet besteht der DHCP-Dienst aus drei Servern, von denen sich z.Zt. zwei im LRZGebäude und einer im LMU-Stammgelände befinden. Die drei Server bilden zwei Paare, wobei einer der
beiden Server im LRZ der primäre Server ist und der zweite Server im LRZ bzw. der im LMUStammgelände als sekundärer Server fungiert. Zur Ausfallsicherheit arbeiten die Server redundant, d.h.
bei einem Ausfall eines Servers übernimmt der jeweils zweite automatisch die Funktion des anderen.
Außerdem findet zwischen den Servern eine Lastteilung statt.
Bzgl. DHCPv6 (DHCP für IPv6) fanden im Jahr 2010 weitere Tests statt. Im Laufe des Jahres 2010 wurden die Produktionsserver mit der neuesten Version der DHCP-Software (ISC DHCP 4.2.0) versehen, so
dass im Zuge der geplanten flächendeckenden Einführung von IPv6 (vgl. Kapitel 3.2.12) auch entsprechende DHCPv6-Dienste zur Verfügung stehen.
3.2.10 Voice over IP (VoIP) im Jahr 2010
Insgesamt wurden durch die VoIP-Telefonanlage des LRZ vom Typ Asterisk ca. 201.000 (2009: 197.000)
Gespräche mit einer durchschnittlichen Länge von 2:57 Minuten oder insgesamt ca. 590.000 (2009:
580.000) Gesprächsminuten vermittelt.
Dies entspricht wieder einem Gesprächsvolumenzuwachs von ca. 2% im Vergleich zum Vorjahr, wobei
die durchschnittliche Dauer der Gespräche gleich blieb.
Es konnten ca. 900 Gesprächsminuten direkt über SIP zu externen Teilnehmern abgewickelt werden, was
in etwa 40% im Vergleich zum Vorjahr entspricht. Grund hierfür ist der starke Rückgang der Gesprächsminuten zu einer externen Institution. Zu den über SIP erreichbaren Zielen gehören die Universitäten Eichstätt, Jena, Regensburg, Wien, Mainz, Mannheim, Würzburg, Innsbruck, Stockholm und der
DFN.
Weitere Informationen zur VoIP-Telefonanlage, wie z.B. Aufbau und Vermittlungsstatistik, können den
Jahresberichten ab 2006 entnommen werden.
3.2.11 Zugang über UMTS: Vodafone Sponsoring der Exzellenz Universitäten
TU München und Ludwig-Maximilians-Universität München
Im Rahmen des Sponsorings mit einem Gesamtvolumen von 5 Mio. Euro in der Laufzeit von fünf Jahren
wurden die beiden Münchner Hochschulen Ende 2007 (LMU) bzw. Anfang 2008 (TU) mit UMTSfähigen Geräten für die mobile Sprach- und Datenkommunikation ausgestattet. Damit ist es für mobile
Nutzer möglich geworden, sich über einen zentralen VPN-Zugangspunkt mit dem MWN und dem Internet zu verbinden. Eine detaillierte Beschreibung der Technik findet sich im Jahresbericht 2008.
Im Jahr 2010 waren die ersten zwei Jahre des Vertrages der TU abgelaufen und so werden die Endgeräte
durch die nächste Generation ersetzt.
Die PCMCIA / ExpressCard UMTS Modems werden durch USB-Sticks ersetzt. Als Austausch für die
anderen Geräte wurde von der TU das Nokia E72 ausgewählt.
Eine Darstellung des übertragenen Datenvolumens ist leider nicht möglich, da die Daten von Vodafone
nicht bereitgestellt werden konnten.
3.2.12 IPv6 im MWN
Zum Jahresende waren für 75 (weitere 15 im Zeitraum eines Jahres) MWN-Institutionen IPv6-Subnetze
reserviert. Diese Zuwächse ziehen sich durch alle Teilnehmerkreise. Wie auch im letzten Jahr sind ein
Großteil dieser Subnetze bereits konfiguriert und in Benutzung.
Nach der bereits im Jahr 2009 erfolgten Ausgliederung des Teredo-Protokollumsetzers auf den zweiten
X-WiN-Zugang erhöhte sich der (nun rein durch Teilnehmer am MWN verursachte) IPv6-Verkehr auf
dem Zugang ins Internet erneut um den Faktor 2. Viele grosse Web-Seiten und Dienste-Anbieter haben
ihre Inhalte im letzten Jahr auch über IPv6 zugänglich gemacht. Der letzte Sprung im Januar 2011 wurde
beispielsweise durch die Aktivierung von IPv6 durch das YouTube Portal verursacht. Mit dem stetig
wachsenden IPv6-Angebot nimmt auch der Verkehr im MWN entsprechend zu.
128
Abbildung 61: IPv6-Verkehr im MWN
Die Anzahl der gleichzeitig aktiven Systeme am X-WiN-Übergang erhöhte sich im Laufe des Jahres
leicht auf 1300 (Vorjahr 1100), bei einem marginal verringerten Anteil des automatischen Tunneldiensts
ISATAP. Die Anzahl der Endsysteme mit nativem IPv6 stieg laut dem Tool Nyx von 1800 auf 4800. Dies
ist auf das fortschreitende Ausrollen von IPv6 im MWN und die zunehmende Installation neuer, von
Haus aus IPv6-kompatibler Betriebssysteme der Kunden verursacht.
Abbildung 62: Gleichzeitig aktive IPv6-Hosts im MWN
Viele weitere Dienste im Angebot des LRZ wurden im Jahr 2010 IPv6-fähig gemacht. Dazu zählen beispiesweise Exchange 2010, der Postausgangsserver mailout.lrz.de, das ID-Portal sowie (experimentell)
das Backup über TSM.
Ein Meilenstein in diesem Bereich war der Beschluss der Leiterrunde des LRZ vom 24. November 2010,
der eine flächendeckende Versorgung mit IPv6 im gesamten MWN bis Ende 2012 und die Bereitstellung
der meisten Dienste des LRZ über IPv6 vorsieht. Damit hat der IPv6-Dienst im MWN entgültig den Status eines Produktionsdienstes erreicht. In diesem Zusammenhang wurden die Netzverantwortlichen auf
dem NV-Treffen im Herbst 2010 noch einmal in diesem Bereich auf den neuesten Stand gebracht.
Die exzellente Reputation des LRZ im Bereich von IPv6 manifestierte sich im Jahr 2010 in vielen Kooperationen und Tests mit Herstellern sowie in diversen Vorträgen.
129
Die Planungen für das Jahr 2011 sehen daher das Ausrollen von IPv6 in einer hohen Anzahl von Kundennetzen und die Migration vieler interner Dienste vor. Die Vorbereitung (insbesondere im Bereich der
Statistiken und Messungen) auf den weltweiten IPv6-Tag am 8. Juni 2011 und die (vollständige) Erweiterung der bestehenden Netzüberwachungsmöglichkeiten auf IPv6 sind umfangreiche Aufgaben für das
nächste Jahr.
3.3
Management
Für das effiziente Management der Netzkomponenten und -dienste setzt das LRZ seit vielen Jahren erfolgreich auf eine Kombination aus Standardsoftwarepaketen und gezielt ergänzende Eigenentwicklungen. Nachfolgend werden die aktuellen Weiterentwicklungen der LRZ-Netzdokumentation sowie der
Einsatz kommerzieller Netz- und Dienstmanagementwerkzeuge – insbesondere auch die mandantenfähige
Überwachung der Dienstqualität im MWN – vorgestellt. Anschließend werden aktuelle Weiterentwicklungen und Statistiken in den Bereichen Incident, Configuration und Change Management, die bislang
durch Remedy ARS unterstützt werden, vorgestellt. Schließlich wird auf die Ausrichtung der LRZ ITService-Management-Prozesse nach ISO/IEC 20000 und die damit verbundene Werkzeugunterstützung
über die iET Solutions ITSM Suite eingegangen.
3.3.1 Weiterentwicklung und Betrieb der Netzdokumentation
In der LRZ-Netzdokumentation werden für den Betrieb des MWN relevante Informationen (Netzkomponenten, Subnetze, Ansprechpartner, Räume usw.) gespeichert. 2010 wurde die Netzdokumentation auf
einen neuen, virtuellen Server mit aktuellem Betriebssystem migriert. Im Zuge dieser Migration wurden
auch der zugrundeliegende Anwendungsserver Zope und die für die Netzdokumentation benötigten Software-Module und Treiber aktualisiert. Neben dieser Migration wurden auch noch einige Erweiterungen
und Verbesserungen vorgenommen; die wichtigsten werden im Folgenden kurz aufgeführt.
3.3.1.1
Erweiterungen und Verbesserungen der Netzdokumentation
Folgende Erweiterungen und Verbesserungen wurden 2010 realisiert:
• “Firewalls / Filter“ wurde als komplett neuer Menüpunkt in die Netzdokumentation aufgenommen. Unter diesem Menüpunkt werden derzeit vor allem Informationen zu virtuellen Firewalls
gespeichert. Prinzipiell könnten hier aber auch alle anderen Arten von Firewalls oder Filtern auf
Subnetzen (Hardware-Firewalls, Router-Filter usw. gespeichert werden, da die Felder für die abgelegten Informationen (Name, Typ, Modus, Status der Komponente, Transportnetz, Kundennetz
usw.) allgemein genug gehalten sind (siehe Abbildung 63 mit einem Ausschnitt des Ergebnisses
einer Suche über die Firewall-Kontexte). Die Informationen zu Firewalls und Filtern wurden auch
an einigen anderen Stellen in der Netzdokumentation (bei Personen, bei Instituten, bei Subnetzen
und bei Komponenten) integriert und damit mit den bereits vorhandenen Daten in Beziehung gesetzt.
• Bei Personen wurde ein Attribut für die LRZ-Kennungen der Netzverantwortlichen neu eingeführt. Das Attribut wurde anschließend durch einen Abgleich mit LRZ-SIM per Skript bei allen
Personen gesetzt, bei denen eine eindeutige Zuordnung der Person in der Netzdokumentation zu
einer Kennung in LRZ-SIM möglich war. Anschließend wurde die Kennung per E-Mail an alle
Netzverantwortlichen entweder überprüft (falls ein Abgleich per Skript möglich war) oder neu
abgefragt. Das Attribut LRZ-Kennung dient derzeit vorwiegend dazu, dass Netzverantwortlichen,
die sich in die neue WWW-Schnittstelle NeSSI mit ihrer persönlichen Kennung eingeloggt haben, ihre Daten in der Netzdokumentation zugeordnet werden können.
• Die Switch-Betreuer und die Arealbetreuer der Netzwartung können jetzt auch (wie bisher schon
die Arealbetreuer) bei Bezirken und Unterbezirken gespeichert werden.
• Das IP-Sperren-Attribut bei Subnetzbereichen wird jetzt automatisch bei der Eingabe gemäß den
Vorgaben des Arbeitskreises Security gesetzt.
• Das Attribut Ort bei Bezirken und Unterbezirken wurde in die Attribute Name, Straße und Ort
aufgeteilt.
• Die DHCP-Administratoren werden bei Änderungen an Subnetzen oder Subnetzbereichen, die für
die DHCP-Konfiguration relevant sind, per E-Mail benachrichtigt.
130
Abbildung 63: Ergebnis (Ausschnitt) einer Suche über die Firewall-Kontexte
3.3.1.2
Inhaltliche Aktualisierung der Netzdokumentation
Um die Aktualität der Informationen zu den Netzverantwortlichen zu sichern, wurde 2010 wieder eine
Benachrichtigung und Überprüfung der Kontaktinformationen durchgeführt. Jeder der 844 Netzverantwortlichen erhielt per E-Mail die Liste der Subnetze und Subnetzbereiche, für die er zuständig ist, und die
in der Netzdokumentation gespeicherten persönlichen Daten. Diese Daten sollten entweder bestätigt oder
eventuelle Fehler korrigiert werden. An die Netzverantwortlichen, die auch nach einem Monat noch nicht
geantwortet hatten, wurde per Skript automatisiert eine E-Mail zur Erinnerung geschickt.
Bei rund 273 Einträgen zu Netzverantwortlichen waren kleinere oder größere Änderungen während der
Aktualisierung notwendig. Bei allen anderen Netzverantwortlichen blieben die Einträge unverändert.
Neben dieser jährlichen Aktualisierung werden aktuelle Änderungen im MWN laufend in die Netzdokumentation übernommen.
3.3.2 Netz- und Dienstmanagement
Das Netz- und Dienstmanagement bildet die Basis für die Qualität der Netzdienstleistungen des LRZ im
MWN. Wesentliche Komponenten des Netz- und Dienstmanagements sind das Konfigurations-, das Fehler- und das Performance-Management. Die Aufgaben des Konfigurations- und Fehler-Managements
werden im MWN durch den Netzmanagement-Server und die auf dem Server eingesetzten Netzmanagement-Software erfüllt. Die Aufgaben des Performance-Managements werden im Service-LevelManagement-Werkzeug InfoVista umgesetzt (siehe auch nächster Abschnitt).
3.3.2.1
Netzmanagement Software und Netzmanagement Server
Im Jahr 2008 wurde der IBM Tivoli Network Manager IP (ITNM) als neue Netzmanagement-Software
ausgewählt. ITNM löst den HP OpenView Network Node Manager 6.4 ab. Der Auswahlprozess und die
Gründe für die Wahl von ITNM sind im Jahresbericht 2008 zusammengefasst.
Anfang 2009 war die Version 3.8 des IBM Tivoli Network Manager verfügbar. Mit dieser Version wurde
mit der Einführung des Tools am LRZ begonnen. Die Einführung konnte 2009 allerdings nicht abgeschlossen werden. Die Gründe dafür und die für 2010 verbliebenen Arbeitspakete sind im Jahresbericht
2009 aufgeführt.
131
Die Produktivführung des IBM Tivoli Network Manager hat sich auch 2010 noch bis Juli verzögert.
Hauptgrund war das Root-Cause-Analyse-Problem, das schon im Jahresbericht 2009 erwähnt wurde
(RCA; Korrelation der Erreichbarkeits-Abfrage mit der Layer-2-Topologie). Es bewirkte, dass Ausfallmeldungen von Geräten, die hinter dem ursächlich ausgefallenen Gerät liegen, meistens nicht wie erwünscht unterdrückt wurden. Dieses Problem wurde erst im Juli 2010 vom IBM-Support (und erst nach
einer erneuten Eskalation durch das LRZ bei IBM) endgültig behoben. Die technische Ursache des Problems war ein Fehler bei der Erzeugung der Layer-2-Topologie durch das Tool, so dass viele fehlerhafte
Verbindungen im Topologie-Graphen für das MWN vorhanden waren.
Neben der Bearbeitung des RCA-Problems wurden auch noch folgende (aus 2009 noch offenen) Punkte
2010 erledigt:
• Automatisierung der Layer-2-Topologie-Erkennung
• Automatisierung des Backups der Anwendung
• Automatisches und schnelles Entfernen von abgebauten Geräten aus der Layer-2-Topologie
• Vervollständigung der Dokumentation der Installation
• Absolvierung bzw. Organisation von zwei Kursen zum IBM Tivoli Network Manager (ein Administrator-Kurs für die ITNM-Administratoren in Hamburg und ein Anwender-Kurs für die Eventkonsole (OMNIbus) am LRZ)
• Vervollständigung der Konfiguration zur Verarbeitung der SNMP-Traps der Geräte und Benachrichtigung der Geräteadministratoren bei bestimmten (wichtigen) SNMP-Traps über E-Mail und
SMS
• Weitere spezifische Anpassungen für die HP/Coloubris WLAN-Accesspoints aufgrund deren fehlerhafter SNMP-Implementierung. Es ist leider immer noch nicht gelungen, vom Hersteller der
WLAN-Accesspoints eine bzgl. der SNMP-Implementierung fehlerfreie Firmware-Version zu erhalten.
• Erstellung und Umsetzung eines Benutzerkonzepts (Sichten für Geräte-Administratoren, Sichten
für Operateure usw.)
• Korrektur einiger verbleibender kleinerer Probleme bzgl. der Layer-2 Topologie-Erkennung
Für das Jahr 2011 verbleibt damit als einziger wichtiger offener Punkt die VLAN-Unterstützung von
ITNM nochmals zu testen und eventuell einzuführen (2009 wurde entschieden, die VLAN-Unterstützung
aufgrund erheblicher Probleme vorerst zu deaktivieren, siehe Jahresbericht 2009).
Aufgrund des oben beschriebenen RCA-Problems (und einiger kleinerer darüber hinaus) konnte der IBM
Tivoli Network Manager erst im Sommer 2010 in den Produktivbetrieb überführt werden. Der HP OpenView Network Node Manager wurde deshalb noch bis Herbst 2010 parallel dazu betrieben und dann erst
endgültig deaktiviert. In den folgenden drei Abbildungen sind Screenshots des IBM Tivoli Network Manager zu sehen. In Abbildung 64 ist die Layer-2-Topologie des gesamten MWN zu sehen (inklusive des
Auswahl-Fensters mit allen konfigurierten Layer-2-Sichten).
In
Abbildung 65 ist die Layer-2 Topologie des (erweiterten) MWN-Backbone dargestellt. Zusätzlich zu den
Backbone-Routern sind noch einige Switches von wichtigen Standorten und die Anbindungen an das XWiN (das deutsche Forschungsnetz) und an das Netz von M-net (Internet-Backup) zu sehen. Die MWNBackbone-Struktur ist auch gut in der ersten Abbildung des gesamten MWN wiederzuerkennen. In Abbildung 66 ist die Event-Konsole des IBM Tivoli Network Manager mit einigen Meldungen zum Status
des MWN dargestellt. Violett sind hier beispielsweise die von der Root-Cause-Analyse als Symptom
erkannten Meldungen zu sehen.
Ende 2010 wurden vom IBM Tivoli Network Manager ca. 2900 Netzkomponenten und Server (mit netzrelevanten Diensten) überwacht. Das ist eine Steigerung von ca. 300 Geräten gegenüber 2009.
Der Netzmanagement-Server, auf dem der IBM Tivoli Network Manager installiert ist, hat außerdem
noch folgende Funktionen:
• Arbeitsserver für die Geräteadministratoren
• Zentrales Repository für die Gerätekonfigurationen
• Notfallzugriff auf Geräte über serielle Verbindungen und analoge Modems
• Server für diverse Skripte, die für den Betrieb und das Management des MWN benötigt werden
132
Abbildung 64: Layer 2 Topologie des gesamten MWN im IBM Tivoli Network Manager
Abbildung 65: MWN-Backbone im IBM Tivoli Network Manager
133
Abbildung 66: Event-Konsole des IBM Tivoli Network Manager mit Status-Meldungen
3.3.2.2
WWW-Server zum Netzmanagement
Auf einem separaten Webserver sind seit 2002 aktuelle Informationen über die Topologie für die Nutzer
des Münchner Wissenschaftsnetzes und die Performance des MWN-Backbone abrufbar. Unter
http://wwwmwn.lrz-muenchen.de/ werden Performance-Daten zu den wichtigsten Elementen des MWN
(Backbone, X-WiN-Anbindung, IPv6-Verkehr, NAT-o-Mat, Demilitarisierte Zone (DMZ) des LRZ, Modem- und ISDN-Zugang, usw.) dargestellt.
Die Performance-Daten werden dazu jeweils in Form von MRTG-Statistiken bereitgestellt. MRTG (siehe
http://www.mrtg.org) ist ein Werkzeug zur Überwachung des Verkehrs auf Netzwerkverbindungen, kann
aber auch zur Überwachung anderer Kennzahlen eingesetzt werden.
Der WWW-Server zum Netzmanagement dient als Schnittstelle zu den Kunden im MWN, um die NetzDienstleistung MWN des LRZ transparenter zu machen.
In 2010 gab es hier keine wesentlichen Änderungen.
3.3.3 Überwachung der Dienstqualität des MWN mit InfoVista
Das Service Level Management Werkzeug InfoVista dient dazu, die Qualität von IT-Diensten zu überwachen und in Visualisierungen und Reports darzustellen. Es wird seit dem Jahr 2000 zur Überwachung der
Dienstqualität im Münchner Wissenschaftsnetz (MWN) eingesetzt. Das InfoVista-System wird ständig an
die Entwicklungen im MWN angepasst bzw. Veränderungen im Netz werden in InfoVista übernommen.
Im Jahr 2010 wurde der InfoVista-Server auf einen virtuellen Server migriert und gleichzeitig ein Update
auf die Version 4.0 SP2 durchgeführt. Nach dieser Migration traten wiederholt Abstürze des InfoVista
Collector-Service auf. Der Collector-Service, zuständig für die Sammlung der Daten per SNMP von
Netzkomponenten, ist teilweise mehrmals pro Woche abgestürzt. Bis Ende 2010 konnte auch mit Hilfe
des InfoVista-Supports noch nicht endgültig geklärt werden, ob diese Abstürze durch die Migration auf
den virtuellen Server verursacht sind oder andere Gründe haben. Dieses Problem verbleibt für 2011 zur
134
endgültigen Klärung. Im Folgenden werden neue und veränderte Reports, die 2010 implementiert wurden, vorgestellt.
3.3.3.1
TSM-Reports
Für die TSM-Server wurden 2010 einige Reports neu aufgesetzt, um die Auslastung der Netzanbindung
und das Verkehrsvolumen zu überwachen. In Abbildung 67 ist als Beispiel ein Report über den Durchsatz
zweier Router-Interfaces zu den TSM Servern zu sehen.
Abbildung 67: Report zum Durchsatz zweier Router-Interfaces zu den TSM Servern
3.3.3.2
Signal-Rausch-Verhältnis der WLAN Funkstrecken
In diesem Report wird das Signal-Rausch-Verhältnis aller Funkstrecken im MWN dargestellt und überwacht. Bei Unterschreiten eines Schwellwerts (derzeit 20 dB) wird eine E-Mail an die Administratoren
der Geräte verschickt.
Abbildung 68: Report zum Signal-Rausch-Verhältnis der WLAN-Funkstrecken
135
Das Unterschreiten des Schwellwerts deutet auf eine schlechtere Verbindungsqualität bzw. auf eine höhere Fehlerrate der Funkstrecke hin. In
Abbildung 68 ist der Report mit dem Signal-Rausch-Verhältnis zu drei Funkstrecken zu sehen.
3.3.3.3
Switch-Reports für Netzverantwortliche
Die Institute haben mit den Switch-Reports für Netzverantwortliche über die WWW-Schnittstelle VistaPortal (http://vistaportal.lrz.muenchen.de) zu InfoVista eine Übersicht über das Gerät und auch über die
Port-Auslastung der Switche, an denen sie angeschlossen sind. Durch die Reports wird die Diensterbringung des LRZ transparenter, außerdem kann die Fehlersuche im Institut dadurch erleichtert werden. Die
Reports können im HTML-, GIF-, PNG-, PDF-, Text- oder Excel-Format abgerufen werden.
Zu den bereits in den Jahren 2003-2009 instanziierten Reports für Netzverantwortliche kamen 2010 noch
Reports für folgende Einrichtungen hinzu:
• Lehrstuhl für Kommunikationsnetze, Technische Universität München
• ITW Weihenstephan
• Physik-Department, Technische Universität München
• Hochschule Weihenstephan-Triesdorf
3.3.4 Action Request System (ARS)
Das Action Request System (ARS) von BMC wird am LRZ seit 16 Jahren für Incident Management,
Change Management, Beschaffungswesen, Asset-Management und IP-Adressverwaltung eingesetzt.
Die Arbeiten im Jahr 2010 haben sich vorwiegend auf Wartung und Pflege konzentriert. Zahlreiche Schulungen wurden für die Hotline-Mitarbeiter, studentischen Operateure und LRZ-Mitarbeiter zur Benutzung
des ARS-Tools und der Formulare durchgeführt.
2010 wurden insgesamt 1189 (2009: 924) KOM-Change-Record-Tickets abgeschlossen. Dieses Formular
unterstützt den Change-Management-Prozess in der Abteilung Kommunikationsnetze.
Am Trouble-Ticket Formular (TT) wurden folgende Änderungen vorgenommen:
• Neue Teams in ARS aufgenommen: Posterdruck mit der Mail an poster@lrz.de und VMware
Team mit der Mail an vmware-admin@lrz.de
• Der Dienst "Virtuelle Firewalls" in das Netz/Systemdienste Menü aufgenommen.
• Ab sofort werden die ARS E-Mail Error Systemmeldungen auch an die Hotliner verschickt. Bis
jetzt ging sie nur an ARS-Admins.
• Die Anzahl der Anhänge wurde im Trouble-Ticket auf sieben erhöht, außerdem kann man jeweils
Dateien bis max. 10 MB speichern.
• Neuer Button "Offene Tickets HLRB + Linux" in TT-Formular eingebaut.
• Der Erfasser des Tickets in KCR und TT wird bei der Anzeige auf Read-Only gesetzt.
• Die Sucheinträge in der Hilferufliste werden jetzt mitgeloggt, um heiße Themen zu identifizieren.
• Auf Hotline-Webformularen das Textfeld Applikation in Kurzbeschreibung umbenannt. Außerdem wurde es Pflichtfeld. (https://www.lrz.de/services/beratung/hotline- web-allgemein)
Auch in den Masken zum Einzelteil- und IP-Adress-Ticket wurden zahlreiche Detailverbesserungen vorgenommen.
3.3.4.1
Übersicht über die Nutzung des Trouble-Ticket Systems
Ein Trouble-Ticket dient der Erfassung von Anfragen oder Störungen und der Ablaufdokumentation der
Bearbeitung. Es ist immer einem Verantwortlichen (oder einer Gruppe) zugeordnet. Im Jahr 2010 wurden
insgesamt 3554 (Vorjahr: 2966) Trouble-Tickets eingetragen, davon waren:
28 (39)
Tickets mit der Dringlichkeit „kritisch“
3487 (2914) Tickets mit der Dringlichkeit „mittel“
39 (13)
Tickets mit der Dringlichkeit „gering“
136
Abbildung 69 gibt einen Überblick über die Gesamtanzahl der monatlich erstellten Tickets und verdeutlicht den im Jahre 2010 stark angewachsenen Anteil an Standard-Störungsmeldungen, die über die Hotline-Webschnittstelle (ARWeb, 1392 Tickets) eingegangen sind. Die Meldungen von Benutzeranfragen
per Webschnittstelle werden neben den Nutzern von Standarddiensten ebenfalls von HLRB- und LinuxCluster-Nutzern intensiv verwendet. Im Jahr 2010 sind 231 HLRB-Tickets (bis 01.12.2010, danach Migration nach iET-Solutions) und 261 Linux-Cluster-Tickets (bis 17.08.2010, danach ebenfalls Migration
nach iET-Solutions) per Webschnittstelle im ARS eingetragen worden. 2010 wurden insgesamt 1884 von
3554 Tickets per Web-Formular erfasst und somit bearbeitet.
Abbildung 69: Trouble-Tickets pro Monat
Die Diagramme in
Abbildung 70 zeigen die Entwicklung der Bearbeitungszeiten von Trouble-Tickets über die letzten drei
Jahre hinweg.
137
Abbildung 70: Bearbeitungszeiten von Trouble-Tickets
Abbildung 71: Trouble-Tickets, klassifiziert nach Dienstklassen
Die Ursache für die extrem lange Bearbeitungszeit von Tickets mit der Priorität niedrig im Monat Oktober waren Tickets, die länger im Status „erfasst“ waren (anstelle von ausgesetzt) und die erst später geschlossen wurden. Aufgrund der geringen Anzahl von Tickets mit niedriger Priorität (39) haben diese
Tickets mit langer Bearbeitungszeit auch eine große Auswirkung auf die Jahresübersicht.
Abbildung 71 zeigt die Verteilung der Tickets auf Dienstklassen. Der Großteil der Tickets betrifft Netzund Systemdienste.
Zu folgenden zehn Diensten wurden die meisten Tickets geöffnet:
Dienst
Anzahl
Tickets
VPN
356
Linux-Cluster
290
Mail -> Anwenderproblem
233
HLRB
223
WLAN -> eduroam
161
Verbindungsproblem
134
WLAN per mobilem Gerät
126
Groupware (Exchange)
96
Softwarebezug
87
Netzkomponenten -> Patchungen
86
138
3.3.4.2
Übersicht über die Nutzung des Quick-Ticket-Systems (QT)
Im Laufe des Jahres 2010 wurde die Benutzung des Quick-Ticket-System durch die Hotline eingestellt.
Die notwendigen Daten zur Verbesserung der Beratungsqualität konnten auch durch die Auswertung der
generierten Trouble-Tickets in hinreichendem Maße gewährleistet werden.
Im Jahr 2010 wurden insgesamt 210 Quick-Tickets (2009: 1480) eingetragen, davon entfielen auf:
Dienst
Anzahl Tickets
telefonische
tung
Bera-
151 (1072)
LRZ-Post
0 (247)
Präsenzberatung
59 (161)
Zu folgenden Diensten bzw. Dienstleistungen wurden die meisten Quick-Tickets erzeugt:
3.3.4.3
Dienst
Anzahl Tickets
Verbindungsproblem
58
VPN
40
Mitarbeiterkennungen
25
WLAN
21
Ausdruck
11
Gastkennungen
9
Studentenkennungen
7
Reservierungen
7
Mail Anwenderproblem
7
Benutzeranfragen der Technischen Universität München
An der Technischen Universität München (TUM) wurde im Jahr 2008 ein Service Desk eingeführt, der
Benutzeranfragen der TUM entgegen nimmt. Diese Benutzeranfragen werden in einem TUM-eigenen
Trouble-Ticket-System (OTRS) erfasst. Der TUM-Service-Desk koordiniert diese Benutzeranfragen ggf.
mit nachgelagerten Dienstanbietern, wozu auch das LRZ als IT-Dienstleister der TUM gehört.
Anzahl TUM IT-Support
Tickets in ARS 2010
100
50
0
Abbildung 72: Anzahl der von der TUM weitergeleiteten Anfragen
139
Anfragen von TUM-Benutzern für das LRZ werden per E-Mail an das LRZ weitergegeben. Eine automatisierte Einspeisung in das ARS-System war aufgrund organisatorischer Änderungen nicht mehr möglich,
d.h. die eingehenden Emails des TUM-Supports mussten jeweils manuell in ARS-Tickets überführt werden. Das führte allerdings dazu, dass die Bearbeitung dieser Benutzeranfragen sowohl auf TUM-Seite als
auch auf LRZ-Seite komplexer wurde.
In
Abbildung 72 ist die Anzahl der vom TUM-Service-Desk an das LRZ weitergeleiteten Anfragen (531
Tickets, 2009: 497 Tickets) ersichtlich. Deutlich erkennbar ist auch der Anstieg der Anfragen um ca. 50%
ab der zweiten Jahreshälfte.
3.4
Sicherheit
Durch die gezielte Kombination aus der Bereitstellung von Werkzeugen zur Prophylaxe und der kontinuierlichen Überwachung des Netzbetriebs konnten die Auswirkungen IT-sicherheitsrelevanter Vorfälle
auch in diesem Jahr erfreulich gering gehalten werden.
Im Folgenden werden zunächst das am LRZ entwickelte Intrusion Detection und Prevention System Nato-Mat und seine aktuelle, als Secomat bezeichnete Version beschrieben. Daran anschließend wird auf den
Einsatz des Security Information und Event Management Systems OSSIM sowie die zentralen Logserver
und Sperrlisten eingegangen. Ferner werden die Mechanismen zum Monitoring am WiN-Zugang und das
ebenfalls am LRZ entwickelte Sicherheitswerkzeug Nyx, das 2010 ins NeSSI-Portal integriert wurde,
vorgestellt. Abrundend wird ein Überblick über die weiterhin auf sehr großes Kundeninteresse stoßende
Dienstleistung „virtuelle Firewalls“ gegeben.
3.4.1
NAT-o-MAT/Secomat
Das automatische proaktive Intrusion Prevention System (IPS) NAT-o-MAT und dessen Weiterentwicklung Secomat bestehen derzeit aus zwei Clustern mit jeweils drei Nodes (technische Details siehe Jahresbericht 2007 und 2009). Die folgenden Abbildungen zeigen eingehende bzw. ausgehende Datenübertragungsraten und gesperrte Benutzer der sechs Knoten des Secomat- und NAT-o-MAT-Clusters im Zeitraum von einer Woche.
Abbildung 73: secomat1
140
Abbildung 76: natomat1
Tabelle 36 zeigt die Spitzenwerte bei Datenübertragungsrate und gleichzeitigen Benutzern.
Secomat-Cluster
NAT-o-MAT-Cluster
Eingehende Datenübertragungsrate
ca. 450 Mbit/s
ca. 950 Mbit/s
Ausgehende Datenübertragungsrate
ca. 150 Mbit/s
ca. 310 Mbit/s
Gleichzeitige Benutzer
ca. 3000
ca. 4800
Tabelle 36: Spitzenwerte der eingehenden und ausgehenden Datenübertragungsrate,
sowie der Benutzeranzahl
Nach den positiven Erfahrungen mit dem neuen Secomat-Cluster wurden vier leistungsstarke Rechner mit
10GE Netzkarten beschafft. Diese werden als Secomat-Cluster zukünftig den kompletten Verkehr der
beiden bisherigen Cluster, d.h. NAT-o-MAT und Secomat, abwickeln.
3.4.2 Security Information & Event Management
Auch in diesem Jahr unterstützte die 2009 eingeführte Security Information & Event Management
(SIEM) Lösung auf Basis von Alienvaults Open Source SIM (OSSIM) die Arbeit des LRZ Abuse-Teams.
Während bisher nur Systemverantwortliche über am X-WiN-Übergang detektierte Viren-, insbesondere
Conficker-infizierte Systeme automatisch informiert werden konnten, wurde diese Reaktionsmöglichkeit
in diesem Jahr um die direkte Information per VPN eingewählter Nutzer erweitert. Die Weiterleitung
derartiger Informationen stellte bis dahin einen manuell von einem Abuse-Team-Mitarbeiter durchzuführenden Schritt dar, welcher nun ebenfalls komplett automatisiert durchgeführt wird und zur weiteren Entlastung der Mitarbeiter des Abuse-Teams führt. In Vorbereitung ist auch die Umsetzung einer automatisierten Sperrung der RADIUS-Kennung bei wiederholter Auffälligkeit.
Durch Feintuning vorhandener Mechanismen konnte die Anzahl von False Positives auf ein sehr geringes
Maß (2) reduziert werden. Desweitern führte die Erstellung und automatische Abfrage einer Datenbankbasierten Ausnahmeliste erfreulicherweise dazu, dass IP-Adressen zentraler Gateway- und FirewallSysteme nur mehr vereinzelt automatisch gesperrt wurden.
Die Anfang 2010 vom DFN-CERT etwa 30 bis 40 als auffällig gemeldeten IP-Adressen im MWN konnten bis Jahresende auf einige wenige (2 bis max. 5) pro Tag reduziert werden. Da OSSIM eine Reaktion
nahezu in Echtzeit erlaubt, werden kompromitterte Systeme, die nur temporär mit dem MWN verbunden
waren, zeitnah detektiert und die Netzverantwortlichen informiert. So war es möglich, auch Gäste und
Konferenzteilnehmer über eine Viren-Infektion (meist privater) Systeme zu informieren.
141
3.4.3 Zentrale Sperrliste
Die zentrale Sperrliste des LRZ (technische Details siehe Jahresbericht 2009) wurde um eine Ausnahmeliste erweitert. Die Ausnahmeliste wird benötigt, um bestimmte IP-Adressen vor einer manuellen oder
automatischen Sperrung zu schützen. So wird vermieden, dass z.B. der zentrale Webserver eines Institutes oder einer Organisation im Münchner Wissenschaftsnetz (MWN) beim Monitoring auffällt und dann
umgehend gesperrt wird. Denn ein Rechner kann beim Monitoring durch eine vorübergehende Verkehrsanomalie auffallen, die legitime Ursachen hat. Eine Sperrung wäre in solchen Fällen kontraproduktiv.
Der Algorithmus, mit dem entschieden wird, ob ein Rechner gesperrt wird, bewertet zuerst das auffällige
Ereignis und überprüft dann die Ausnahmeliste. Die Ausnahmeliste ruht auf zwei Säulen: einer datenbankgestützten Tabelle, in die einzelne IP-Adressen oder auch -Bereiche eingetragen werden, und der
ebenfalls datenbankgestützten Netzdokumentation, in der über die Vergabe von IP-Subnetzen im MWN
Buch geführt wird. In der Netzdokumentation kann für ein Subnetz vermerkt werden, ob dessen IPAdressen gesperrt werden dürfen oder nicht. Typischer Fall eines IP-Subnetzes, das durch eine entsprechende Markierung vor einer Sperrung geschützt wird, ist ein Server-Netz.
Auch wenn ein Rechner detektiert wird und durch einen Eintrag in der Ausnahmeliste vor einer Sperrung
sicher ist, wird der zuständige Netzverantwortliche verständigt. Denn es nicht ausgeschlossen, dass ein
Rechner in der Ausnahmeliste korrumpiert wird. Die Ausnahmeliste sorgt lediglich für einen Zwischenschritt im Eskalationsmechanismus.
3.4.4 Monitoring am X-WiN-Übergang
Am X-WiN-Übergang wird sowohl die ein- als auch die ausgehende Kommunikation überwacht und
analysiert. Im Unterschied zu vielen Unternehmen und deren Überwachungsstrategien liegt unser
Schwerpunkt auf der Analyse ausgehenden Verkehrs, wobei sich grundsätzlich zwei Verfahren unterscheiden lassen:
• Vergleich mit (bekannten) Angriffsmustern
• Statistische Verfahren
Nennenswerte Auffälligkeiten in ausgehendem Verkehr sind unter anderem
• FTP-Server auf einem Nicht-Standard-Port, welcher von Angreifern genutzt wird.
• SSH-Scans (d.h. Verbindungsversuche zu externen Rechnern auf TCP-Port 22 mit einer Rate von
mindestens 60 Verbindungsversuchen/Minute), um in Verbindung mit Wörterbuch-Angriffen schwache Passwörter zu brechen.
• Die Kommunikation Viren-infizierter und trojanisierter Systeme (Conficker, Mebroot, Gozi, ZeuS,
StormWorm), die versuchen, weitere Systeme insbesondere im Internet zu infizieren und damit auf
die weitere Ausbreitung des Virus abzielen.
• Die Kommunikation mit bekannten Command & Control Servern eines Botnetzes.
• Allgemeine Portscans und Denial-of-Service-Angriffe.
• Ungewöhnlich hohe ausgehende Datenvolumina.
Demgegenüber werden am X-WiN-Übergang auch die meist in der Breite durchgeführten SSH-Scans auf
MWN-interne Ziele erkannt.
Auch dieses Jahr war das Monitoring am X-WiN-Übergang überwiegend geprägt von der Kommunikation MWN-interner, Conficker-infizierter Systeme. Insgesamt 502 betroffene Rechner wurden detektiert.
Auch der Gozi-Trojaner (174 Systeme), mittels dessen versucht wird, per SSL gesicherte Daten, beispielsweise Bankaccounts, zu stehlen und an weltweit verteilte Server zu übermitteln, wurde detektiert.
Die jeweils zuständigen Netzverantwortlichen und seit diesem Jahr auch per VPN verbundene Nutzer
wurden automatisch (OSSIM) über Auffälligkeiten ihrer Systeme informiert und konnten damit zeitnah
reagieren und Gegenmaßnahmen einleiten.
142
3.4.5 Sicherheitswerkzeuge "Nyx" und "Nessi"
3.4.5.1
Nyx
Nyx ist ein Sicherheits- und Netzmanagementwerkzeug, mit dem einzelne Rechner im MWN lokalisiert
werden können. Nach Eingabe einer bestimmten MAC- oder IP-Adresse eines Rechners bekommt man
den Switch und den Port gemeldet, an dem der Rechner angeschlossen ist. Außerdem wird die Bezeichnung der Netzwerkdose ausgegeben, zu welcher der Switchport gepatcht ist.
Dafür müssen über 1100 Switches und 11 Router alle 5 Minuten abgefragt werden, um keine Daten zu
verlieren. Deshalb ist Nyx massiv parallel aufgebaut. Um irrelevante Daten auszufiltern, ist die Kenntnis
der Topologie notwendig. Die Erkennung erfolgt mit einem maschinellen Lernalgorithmus, dessen Genauigkeit im Schnitt bei über 95% liegt.
Im September und Oktober 2010 wurden im Rahmen eines studentischen Praktikums kleinere CiscoRouter und vor allem HP-Access-Points in Nyx integriert, so dass nun auch drahtlose Geräte geortet werden können. Als Standort wird dann der entsprechende Access-Point ausgegeben. Eine echte Standortbestimmung ist so allerdings nicht möglich (und auch nicht vorgesehen).
Nyx fragt insgesamt also ca. 2700 Geräte ab.
3.4.5.2
Nessi
Nyx wurde aus Datenschutzgründen früher nur LRZ-intern verwendet. Immer mehr Netzverantwortliche
aus dem MWN fragten jedoch nach, ob sie diesen Dienst nicht auch selbst z.B. zur Fehlersuche nutzen
könnten. Deshalb wurde 2009 mit der Entwicklung einer mandantenfähigen Plattform für Netzverantwortliche begonnen, die ins LRZ-ID-Portal integriert ist. NeSSI (Network Admin Self Service Interface)
stellt Netzverantwortlichen Werkzeuge zur eigenständigen Nutzung für ihre Bereiche zur Verfügung. Seit
Oktober 2010 ist Nessi produktiv im Einsatz.
Abbildung 79: Nessi-Portal für Netzverantwortliche
143
Nessi umfasst zurzeit folgende Dienste:
• Nyx: Netzverantworliche können Rechner in ihren Subnetzen – und nur dort – orten.
• DHCP: Netzverantworliche können sich vom LRZ-DHCP-Server vergebene IPs anzeigen lassen.
• Anzeige der Kontakte und Subnetze aus der Netzdoku.
Das Nessi-Portal ist in Abbildung 79 dargestellt. Das Portal ist wie Nyx in Java geschrieben und nutzt
Tomcat als Application-Server. Zur Sessionverwaltung wird JavaServer Faces 2.0 eingesetzt. Der Webdesktop ist in Javascript realisiert, unter Verwendung des Javascript-Framework Extjs.
3.4.6 Virtuelle Firewalls
Das LRZ betreibt fünf Cisco Firewall Service Module (FWSM), die sich auf verschiedene BackboneRouter im Münchner Wissenschaftsnetz (MWN) verteilen, und eine ASA5580-40 (technische Details
siehe Jahresbericht 2009). Derzeit werden damit rund 85 Kunden mit virtuellen Firewalls (VFW) bedient.
Bisher waren FWSMs und ASA5580-40 für zwanzig VFWs lizensiert. Da diese an einigen Standorten
nicht mehr ausreichten, wurden alle Komponenten mit Lizenzen für jeweils fünfzig VFWs ausgestattet.
Um die Ausfallsicherheit zu erhöhen, wurde eine zweite ASA5580-40 beschafft. Zukünftig werden die
beiden ASA5580-40 nach einer Testphase im Active-Passive-Mode betrieben. Bei diesem Verfahren
springt bei einem Ausfall der aktiven ASA5580-40 sofort die bis dahin passive ASA5580-40 ein und
übernimmt deren Aufgaben.
Durch ein Update des Web-Interfaces zur Verwaltung von VFWs auf den FWSMs kann jetzt auch auf
den FWSMs die IPv6-Konfiguration bequem über die grafische Benutzerschnittstelle vorgenommen werden. Dies war zuvor nur auf den ASA5580-40 möglich.
Abbildung 80: Web-Schnittstelle Adaptive Security Device Manager (ASDM)
3.5
Projektarbeiten im Netzbereich 2010
Projektarbeiten hatten auch 2010 wieder einen hohen Stellenwert im Netzbereich. Im Folgenden werden
die Tätigkeiten für das D-Grid GIDS-Projekt, das Customer Network Management (CNM) und die Géant3-Tasks zum End-to-End Monitoring, I-SHARe sowie die Visualisierungswerkzeuge und die Arbeiten
zum Performance Monitoring vorgestellt. Schließlich wird über den erfolgreichen Abschluss des 100GET
E3-Projekts berichtet.
144
3.5.1 D-GRID Projekt GIDS
Unter Grid-Computing versteht man die kollektive und kollaborative Nutzung weltweit verteilter heterogener Ressourcen wie z.B. Rechner, Software, Daten, Speicher, aber auch wissenschaftlicher Instrumente
oder Großgeräte (z.B. Beschleunigerring am CERN, astronomische Teleskope) u.ä..
Das Grid-Computing wird seit September 2005 im D-Grid-Projekt vom Bundesministerium für Bildung
und Forschung gefördert. Die Förderung des BMBF verteilt sich auf wissenschaftliche Verbundprojekte,
die Grids nutzen, die so genannten Community-Projekte (CPs), und ein Verbundprojekt von Partnern, die
Grid-Infrastrukturen entwickeln und betreiben und den Community-Projekten zur Verfügung stellen. Das
letztgenannte Projekt wird als D-Grid-Integrationsprojekt (DGI-I) bezeichnet. Das DGI-I hat eine KernGrid Infrastruktur geschaffen, auf der die existierenden Community-Projekte basieren. Ziel war der Aufbau einer nachhaltigen Grid-Basisinfrastruktur, die den Anforderungen der Communities gerecht wird.
Nachdem das Projekt 2007 endete, wurde Mitte des Jahres 2007 ein Nachfolgeprojekt DGI-II beantragt
und bewilligt. Das DGI-II Projekt startete zum 1.1.2008; es wird fachlich und inhaltlich in der Abteilung
HLS bearbeitet.
Im Netzbereich wurde 2010 an einem weiteren Projekt aus dem 2. Call gearbeitet: Zur Sicherung der
Nachhaltigkeit einer deutschlandweiten Grid-Infrastruktur ist insbesondere der Bereich des Sicherheitsmanagements zu berücksichtigen. Das GIDS-Projekt hat die Entwicklung, Projektierung und Inbetriebnahme eines Grid-basierten, föderierten Intrusion Detection Systems (GIDS) sowie die Überführung des
GIDS in den D-Grid Produktionsbetrieb zum Ziel. Die Vision von GIDS ist es, einzelne Sicherheitssysteme, die von Ressourcenanbietern betrieben werden, zu kombinieren, um eine globale Sicht auf Sicherheitsvorfälle im Grid zu erhalten.
Das Projekt, das zum 01.07.2009 begonnen wurde, wird als so genanntes GAP-Projekt gefördert. Die
Projektlaufzeit beträgt 36 Monate und wird neben dem LRZ vom Regionalen Rechenzentrum für Niedersachsen (RRZN) und der DFN-CERT Services GmbH durchgeführt, mit den assoziierten Partnern Stonesoft GmbH und Fujitsu Technology Solutions GmbH, wobei die Konsortialführung beim LRZ liegt.
Details zur Problemstellung, zu den Zielen und den im Jahr 2009 abgeschlossenen Arbeitspaketen des
Projektes sind im Jahresbericht 2009 zu finden.
Im Projekt wurden im Jahr 2010 folgende Arbeitspakete bearbeitet:
• Entwicklung eines Datenschutzkonzepts für ein föderiertes GIDS
• Entwicklung eines Informationsmodells inkl. Datenaustauschformats
• Entwicklung einer Architektur:
o Grobskizze einer Architektur für ein Grid-basiertes IDS
o Detaillierung der Architektur auf Seiten der Ressourcen-Anbieter, inkl. (technischer)
Durchsetzung des Datenschutzkonzepts
o Detaillierung der Architektur auf Seiten eines GIDS-Betreibers zur Erbringung eines
Grid-weiten IDS-Dienstes
o Evaluation des Architekturvorschlags im Hinblick auf Anforderungs- und Kriterienkatalog
• Umsetzung der entwickelten Architektur im D-Grid:
o Implementierung und Realisierung ausgewählter Agenten
o Implementierung und Realisierung einer Benutzeroberfläche
3.5.1.1
Entwicklung eines Datenschutzkonzepts für ein föderiertes GIDS
Ein wichtiger Beitrag zur Akzeptanzsteigerung des GIDS bei den D-Grid-Ressourcenanbietern ist eine
einfache und effiziente Durchsetzung von Datenschutzanforderungen und eine Anpassung der weitergegebenen Daten an die lokalen Sicherheitsrichtlinien. Diesem Ziel wurde im Datenschutzkonzept von
GIDS, Meilensteinbericht Datenschutzmodell für ein Grid-basiertes IDS (MS 13) (http://www.gridids.de/documents/GIDS_MS13.pdf; Juli 2010), Rechnung getragen.
Ziel dieses Arbeitspaketes war die Entwicklung eines Datenschutzkonzeptes, das alle rechtlichen, organisatorischen und technischen Anforderungen erfüllt, die vorher für das GIDS aufgestellt wurden. Dabei
wurde unter anderem das Prinzip des „Least Privilege“ berücksichtigt, das die Rechte und Möglichkeiten
der beteiligten Seiten auf das Notwendige einschränkt. Dadurch werden prophylaktisch die Risiken und
Konsequenzen im Falle eines Sicherheitslecks so gering wie möglich gehalten.
145
Zu diesem Zweck wurde mit einer Literaturrecherche bezüglich der vorhandenen Ansätze für Verfahren
zur Anonymisierung und Pseudonymisierung personenbezogener Daten begonnen. Ziel war es, Komponenten zu bestimmen, die in das Datenschutzkonzept direkt oder mit minimalem Aufwand für Anpassungen übernommen werden können. Als wichtiges Kriterium wurde geprüft, dass das Datenschutzkonzept
konform zu den anderen Arbeitspaketen ist und deren Ergebnisse berücksichtigt.
3.5.1.2
Entwicklung eines Informationsmodells inkl. Datenaustauschformats
Im Rahmen des Projektes ist die Spezifikation eines Informationsmodells inklusive eines Datenaustauschformats entwickelt worden. Für eine effiziente und zuverlässige Erkennung von Angriffen (insbesondere
verteilter Angriffe über mehr als eine Site der D-Grid Infrastruktur) ist der sichere Austausch verschiedenartiger Daten zwischen den auf den Sites installierten GIDS-Komponenten erforderlich. Die Kommunikation findet hier nicht nur Site-lokal, sondern ebenfalls Grid-global statt.
Um ein geeignetes Datenformat zur Übertragung solch sicherheitsrelevanter Informationen zu finden,
wurden zunächst die Anforderungen an ein solches erarbeitet und im Anschluß Recherchen zu bereits
bestehenden Produkten und Formaten durchgeführt. Als ein für das Vorhaben GIDS sehr geeignetes Format hat sich das XML-basierte Intrusion Detection Message Exchange Format (IDMEF) herausgestellt.
Durch eine breite Nutzerschicht und eine aktive Community handelt es sich bei IDMEF im Gegensatz zu
vielen anderen proprietären Formaten um einen lebendigen Standard im Bereich verteilter IDS. Es folgte
eine Untersuchung bereits bestehender Produkte und ihre Fähigkeiten bezüglich einer IDMEFUnterstützung.
Die bereits aufgestellten, speziellen Anforderungen an ein Grid-basiertes Intrusion Detection System
wurden in einem nächsten Schritt bei der Erstellung der Spezifikation Informationsmodell inklusive
Datenaustauschformat
für
ein
Grid-basiertes
IDS
(MS
12)
(http://www.gridids.de/documents/GIDS_MS12.pdf; Juni 2010) berücksichtigt.
Darüber hinausgehend haben wir mehrere Punkte identifiziert, in denen eine Anpassung bzw. Erweiterung von IDMEF erforderlich ist, um die volle Funktionalität von GIDS zu gewährleisten. So ist in IDMEF beispielsweise keine Möglichkeit vorgesehen, kenntlich zu machen, dass gewisse Teile der Nachricht (aus Datenschutzgründen) anonymisiert wurden. Die Einhaltung von Datenschutzbestimmungen ist
jedoch essentiell für die Akzeptanz des GIDS und somit für den Erfolg des Projekts. Entsprechend wurden Erweiterungen über die von IDMEF dafür vorgesehenen Schnittstellen konzipiert und präzise definiert, welche GIDS-spezifischen Werte in die jeweiligen Datenfelder einzutragen sind.
3.5.1.3
Entwicklung einer Architektur
Die Aufgabe in diesem Arbeitspaket bestand darin, die Architektur des zu entwickelnden GIDS festzuschreiben. So wurde im ersten Schritt eine Grobskizze entwickelt, die in den weiteren Schritten näher
spezifiziert wurde. Das daraus entstandene Architekturkonzept ist im Meilensteinbericht
Architekturkonzept für ein Grid-basiertes IDS (MS 16-1) (http://www.grid-ids.de/documents/
GIDS_MS16-1.pdf; Oktober 2010) zu finden. Als Abschluss steht das noch laufende Arbeitspaket der
Evaluation des Architekturvorschlags aus.
3.5.1.3.1
Grobskizze einer Architektur für ein Grid-basiertes IDS
Die Grobskizze umfasst die zentralen technischen und organisatorischen Komponenten der GIDSArchitektur. Daneben existieren viele Abhängigkeiten und Wechselwirkungen zu dem Datenschutzkonzept und dem Datenaustauschformat. Beispielsweise ergeben sich aus den Benutzerrollen Anforderungen
an den Schutz der Daten und deren Verwendung.
Für die Grobskizze der Architektur wurden zunächst die zentralen Rollen, unter denen Organisationen im
Grid-Verbund auftreten können, und deren technische Komponenten für GIDS definiert, wie auch im
Meilensteinbericht Grobskizze einer Architektur für ein Grid-basiertes IDS (MS 10) (http://www.gridids.de/documents/GIDS_MS10.pdf; Mai 2010) nachzulesen. Für die Rolle Ressourcenanbieter sind Sensoren und die wichtigen Vorverarbeitungswerkzeuge Filter, Aggregator/Verdichter und Anonymisierer/
Pseudonymisierer definiert worden. Daneben ist in der Architektur ein GIDS-Agent als Anbindung an
eine Bus-Struktur vorgesehen, die eine Kommunikation zwischen den einzelnen Teilnehmern von GIDS
ermöglicht, sowie eine optionale lokale (G)IDS-Instanz, die unabhängig von den anderen beteiligten
Partnern Alarmmeldungen verarbeiten kann. Darüber hinaus werden jeweils Agentensysteme benötigt,
die Meldungen von bestehenden bzw. zu schützenden und zu überwachenden Systemen erhalten und die
146
diese Meldungen nach Durchlaufen der Vorverarbeitungsschritte an alle anderen für die jeweilige Nachricht relevanten GIDS-Partner verteilen können.
Eine weitere zentrale Rolle ist der Betreiber, der in erster Linie für das Berichtswesen und die Anbindungen der Virtuellen Organisationen (VO) an GIDS über ein Benutzerportal bzw. für proaktive Benachrichtigungen zuständig ist. Weiterhin stellt er eine Grid-globale GIDS-Instanz und eine Datenbank für korrelierte Alarmmeldungen zur Verfügung.
Im Rahmen der Suche nach Implementierungsmöglichkeiten wurden verschiedene Kommunikationsansätze untersucht (Bus vs. Peer-to-Peer). Die Entscheidung ist hierbei auf eine Bus-Architektur gefallen,
die die gegebenen Anforderungen besser erfüllen kann als ein Peer-to-Peer-Ansatz. Neben der Verbreitung sicherheitsrelevanter Informationen über den GIDS-Bus wurde ebenfalls eine Lösung über Repositories diskutiert, um als GIDS-Teilnehmer auf den aktuellen Datenbestand des Grid-basierten IDS zugreifen
zu können. Auch die sichere und effiziente Übertragung von Angriffsdaten wurde beleuchtet.
3.5.1.3.2
Detaillierung der Architektur auf Seiten der Ressourcen-Anbieter, inkl. (technischer) Durchsetzung des Datenschutzkonzepts
Die im vorherigen Arbeitspaket in der Grobarchitektur definierten Komponenten und deren Funktionen
wurden in diesem Arbeitspaket so detailliert spezifiziert, dass eine Implementierung auf dieser Basis erfolgen kann. Dabei wurden die folgenden, in Abbildung 81 gezeigten Komponenten näher betrachtet.
Abbildung 81: Architektur auf Seiten der Ressourcenanbieter
Die Komponente Anonymisierer/ Pseudonymisierer dient in erster Instanz dazu, dass die juristischen und
vor allem datenschutzrechtlichen Randbedingungen, denen GIDS in Deutschland unterliegt, auch technisch durchgesetzt werden können. Als Basis der Spezifizierung diente das in den vorherigen Arbeitspaketen entwickelte Meilensteindokument des Datenschutzkonzepts.
Die Komponente Aggregator/Verdichter dient dazu, eine Vorverarbeitung der registrierten Alarme zu
ermöglichen. Die über den GIDS-Bus zu transportierenden Daten sind nicht die von den Sensoren gelieferten Rohdaten. Stattdessen werden diese Rohdaten zunächst veredelt und in das spezifizierte Datenaustauschformat überführt. Hierbei wird ebenso die Vorverarbeitung vorgenommen. Es werden Zusammen-
147
hänge zwischen Einzelalarmen hergestellt und aggregierte Meldungen erzeugt. Auf diese Weise wird
ebenso die Datenmenge deutlich reduziert, um die Belastung des GIDS-Bus zu minimieren.
Die eigentliche Logik des IDS liegt in den angeschlossenen (G)IDS-Instanzen. Die Installation und der
Betrieb einer lokalen (G)IDS-Instanz ist optional und dem jeweiligen Ressourcenanbieter selbstverständlich eigenverantwortlich überlassen. Es bietet sich jedoch an, auf bereits existierende Mechanismen zurückzugreifen und diese an die Grid-Umgebung anzupassen. Die entsprechenden Vorüberlegungen für
Betriebsmodelle und Integrationsstrategien wurden eruiert.
Die Komponente GIDS-Agent ist die Kommunikationskomponente. Sie dient der Kommunikation zwischen verschiedenen Komponenten der GIDS-Gesamtarchitektur und bildet die Schnittstelle zwischen
den lokalen GIDS-Instanzen und dem GIDS-Bus (und entsprechend auch mit der ebenfalls an den GIDSBus angeschlossenen globalen GIDS-Instanz).
3.5.1.3.3
Detaillierung der Architektur auf Seiten eines GIDS-Betreibers zur Erbringung
eines Grid-weiten IDS-Dienstes
Analog zu den Architekturkomponenten der Ressourcenanbieter wurden in diesem Arbeitspaket Komponenten und deren Funktionen so detailliert spezifiziert, dass eine Implementierung auf dieser Basis erfolgen kann.
Die Grid-globale GIDS-Instanz bildet das Gegenstück zur Site-lokalen GIDS-Instanz. Sie ist beim GIDSBetreiber installiert und verarbeitet nicht durch lokale Sensoren gesammelte Daten, sondern durch andere
GIDS-Teilnehmer übermittelte, veredelte Daten verschiedenster Ressourcenanbieter. Diese Instanz arbeitet entsprechend auf einer deutlich kleineren, aber dafür Grid-globalen Datenbasis und kann entsprechend
Site-übergreifende Angriffe erkennen.
Die zentrale Anlaufstelle des GIDS für Benutzer und Administratoren wird ein Webportal sein. Hierfür
wurden die Anforderungen gesammelt, diskutiert und festgehalten.
Für eine proaktive Benachrichtigung der Kunden des Grid-basierten IDS ist eine mandantenfähige Komponente notwendig, mit deren Hilfe Benachrichtigungen über einen erkannten Sicherheitsvorfall abhängig
von seinem Schweregrad über verschiedene Kommunikationswege, wie beispielsweise E-Mail oder SMS,
versendet werden. Um eine proaktive Benachrichtigungskomponente zu realisieren, wurden Konzepte
zum Einsatz bzw. zur Modifikation bereits existierender Monitoring-Systeme diskutiert.
3.5.1.3.4
Evaluation des Architekturvorschlags im Hinblick auf Anforderungs- und Kriterienkatalog
Der Abgleich des Architekturkonzepts gegen den in der ersten Phase des Projekts aufgestellten Anforderungs- und Kriterienkatalog wurde im Rahmen dieses Arbeitspakets ebenfalls begonnen. Als potenziell
problematisch wird bei der vollständigen Umsetzung der Datenschutzanforderungen die Beurteilung der
Erkennungsleistung der Agenten / Sensoren eingestuft. Die praktischen Auswirkungen sollen im Pilotbetrieb evaluiert werden.
3.5.1.4
Umsetzung der entwickelten Architektur im D-Grid
Aufgrund der Komplexität der Architektur ist es für deren technische Realisierung notwendig, auf bestehenden Systemen aufzubauen. Dabei müssen die bereits getroffenen Enscheidungen bzgl. der Grobarchitektur und des Datenschutzkonzeptes berücksichtigt werden.
Als Baustein bietet sich das Prelude-Rahmenwerk an, das ein verteiltes IDS mit offenen Schnittstellen
realisiert. Als weiterer Vorteil wird das Format IDMEF bereits nativ unterstützt und bietet ein Datenbankschema, in dem Daten gespeichert werden können. Weiterhin werden verschiedene Sensoren inklusive
Snort unterstützt, die im Rahmen von GIDS eingesetzt werden können.
3.5.1.4.1
Implementierung und Realisierung ausgewählter Agenten
In Zusammenarbeit mit den Projektpartnern wurde zunächst ein Testbed für den GIDS-Bus eingerichtet,
um die verschiedenen Organisationen miteinander zu verbinden. Hierfür wurde mit Hilfe von OpenVPN
ein virtuelles Netzwerk implementiert, das durch redundante VPN-Server an den drei Standorten der Projektpartner betrieben wurde. Erste Tests bezüglich des Datendurchsatzes dieser Lösung sind vielversprechend verlaufen. Ebenso wurden erste prototypische Agenten an das Netzwerk angebunden, die von ihnen
148
gesammelte Informationen in Form von GIDS-Meldungen im IDMEF-Format über den GIDS-Bus an
andere Teilnehmer verteilen. Auch hier sind erste Tests erfolgreich verlaufen.
An den Standorten der Projektpartner wurden erste Agenten auf Basis von Prelude eingerichtet, deren
Aufgabe das Sammeln von Sensornachrichten und das anschließende Konvertieren in das GIDSDatenformat ist.
3.5.1.4.2
Implementierung und Realisierung einer Benutzeroberfläche
Schlussendlich wurde angefangen, eine Benutzeroberfläche zu entwickeln, die sowohl Gridbenutzern als
auch Administratoren als zentrale Anlaufstelle für das GIDS dienen soll. In einem ersten Schritt wurden
die Anforderungen an eine solche Benutzerschnittstelle gesammelt, diskutiert und bewertet. Basierend auf
den Ergebnissen wurden Mockups entwickelt und Oberflächendesigns diskutiert. Hierbei haben sich zwei
wesentliche Sichten herauskristallisiert. Zum einen wird es eine Überblicksseite geben, auf welcher die
aktuelle Lage graphisch und tabellarisch dargestellt wird. Zum anderen wird es eine wesentlich detailliertere Ansicht geben, die es Administratoren erlaubt, gezielt und zeitlich beschränkt nach bestimmten Angriffsarten und Angriffszielen zu suchen.
Im Folgenden galt es, eine technische Lösung für das Webportal zu erarbeiten. Hierfür wurden Recherchen zu verschiedenen technischen Umsetzungen durchgeführt. Nach Gesprächen mit dem DFN-CERT
ist die Entscheidung für das Python-Framework Django gefallen. Django ist ein quelloffenes Webframework, welches ein direktes objektrelationales Mapping für verschiedene Datenbanksysteme ermöglicht.
Ein weiterer Vorteil an Django ist die Kapselung der einzelnen Module. Da das DFN-CERT-Portal ebenfalls mit Hilfe des Django-Frameworks entwickelt wurde, ist eine spätere Integration von GIDS ohne
größere technische Hürden machbar.
3.5.2 Customer Network Management
Das Customer Network Management (CNM) wurde ursprünglich für das MWN (Münchner 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
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 aussagekräftige Informationen über die Einhaltung der vertraglich
ausgehandelten Dienstvereinbarungen.
Die CNM-Anwendung für das X-WiN ist unterteilt in die drei Anwendungen Topologie, Datenvolumen
und XY-Accounting:
1. Die CNM-Anwendung Topologie dient der Visualisierung der X-WiN-Topologie/des Zustands
der IP-Infrastruktur (siehe Abbildung 82).
Anhand dieser Anwendung wird den DFN-Kunden (Anwender) ein Überblick über den aktuellen
und historischen Zustand und Qualität der IP-Infrastruktur gegeben. Für jede im X-WiN bestehende Verbindung werden Bandbreite, Auslastung und Durchsatz graphisch dargestellt, und für
jeden Knoten (Router) die weitergeleiteten Pakete. Auf der Netzebene gibt es 59 Standorte, die
jeweils einen Router enthalten. Diese Router sind direkt mit den Kundeninfrastrukturen verbunden und enthalten auch verschiedene Verbindungen zu kommerziellen Netzbetreibern sowie dem
europäischen Wissenschaftsnetz Géant. Die auf hierarchischen Karten aufgebaute Anwendung
wurde im April 2004 für alle X-WiN-Anwender freigegeben und ist seitdem im Betrieb.
149
Abbildung 82: Die CNM-Anwendung Topologie
2. Die CNM-Anwendung Datenvolumen dient der Bereitstellung von IP-Interfacestatistiken für die
DFN-Anwender.
Die DFN-Anwender können mit Hilfe der CNM-Anwendung Datenvolumen die 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.
Die zwei Anwendungen können separat und unabhängig voneinander benutzt werden oder alternativ ihre
Daten korrelieren. Beispielsweise wird für das LRZ als DFN-Anwender beim Starten der TopologieAnwendung und Auswählen des Knotens (Routers) GARx1 ein Fenster mit den entsprechenden Verbindungen geöffnet, zu denen weitere Dienstinformationen angezeigt werden können (siehe Abbildung 83).
Abbildung 83: Dienstinformationen in Knotenkarten
Beim Anklicken des Felds ServiceInfo wird für den Anwender (hier das LRZ) das Dienst-Ressourcen
Fenster geöffnet, das alle von diesem Anwender benutzte Netzressourcen beinhaltet (siehe Abbildung
84). Wenn man aber nur einen der gelisteten Dienste auswählt, werden auch nur die zu diesem Dienst
zugeordneten Ressourcen angezeigt. Die Liste umfasst alle vergangenen und aktuellen Netzressourcen
150
mit deren Nutzungszeitraum. In einzelnen Spalten werden die Komponente, der Interfacename, der
Dienstname, der Dienstname und der Zeitraum der Ressourcennutzung aufgeführt.
Abbildung 84: Dienst-Ressourcen pro Kunde
Wenn aus dieser Liste eine Ressource und dann über das Kontextmenü die Option ,,Öffne ServiceFenster‘‘ ausgewählt wird, so wird das neue Service-Fenster der CNM-Anwendung Datenvolumen geöffnet. Von diesem aus können die entsprechenden Datenvolumenstatistiken angefordert werden (siehe Abbildung 85).
Abbildung 85: Das Dienstfenster (CNM-Datenvolumen) für das LRZ
3. Die CNM-Anwendung XY-Datenvolumen dient der Bereitstellung von detaillierten IPAccounting-Daten.
Diese Anwendung ist neu und befindet sich zur Zeit noch im prototypischen Betrieb. Mit ihr können die
DFN-Anwender nachvollziehen, mit welchen anderen DFN-Anwendern sie innerhalb des X-WiN wie
viel IP-Verkehr ausgetauscht haben. Der Prototyp sieht eine Admin- und einen Kundensicht vor. Die erste
ist in Abbildung 86 dargestellt. Angezeigt wird die Top-10-Liste der Datenvolumina, die zwischen den
links ausgewählten Bereitstellungsorten zu allen anderen Anwendern ein- bzw. ausgegangen sind.
Alle oben genannten Anwendungen werden den Benutzern als Java-Applets angeboten. Darüberhinaus
wird seit 2004 im MWN eine Webinterface-basierte Sicht der CNM-Anwendung Topologie angeboten,
das sogenannte WebCNM. Diese zeigt ausschließlich hierarchische Netzkarten mit dem aktuellen Status
der Routerinterfaces.
Bei der CNM-Anwendung handelt es sich um eine verteilte Client/Server-Architektur. Wie bereits erwähnt wurde, ist der Client als Java-Applet bzw. WebCNM-Anwendung erhältlich. Der Server ist in C++
implementiert. Der Server bedient sich einer XML-Datenbank, GIS2 (Globale X-WiNInformationssystem), die alle X-WiN Daten verwaltet. Als Kommunikationsmiddleware sowohl zwischen
dem Client und dem Server als auch zwischen dem Server und GIS2 dient CORBA. Derzeit läuft der
Server unter Solaris (Sparc-Rechnerarchitektur).
151
Abbildung 86: Die XY-Accounting Anwendung (Prototyp)
Da am LRZ zukünftig alle Server nach Möglichkeit als virtuelle Server in der VMware-Infrastruktur laufen sollen und diese unter Sparc-Solaris Architektur mit VMware nicht virtualisiert werden können, ist
eine Portierung des CNM-Systems auf Linux-x86 nicht nur empfohlen, sondern unabdingbar. Hierfür
wurde ein Portierungsplan erstellt, der schrittweise den Server (C++ Implementierung, CORBA Anbindung, Datenbankanbindung u.a.) von Sparc-Solaris auf Linux-x86 umstellt. Am Ende des Jahres wurde
in Kooperation mit dem DFN mit dem ersten Schritt, der Auswahl eines geeigneten ORBs unter Linux,
begonnen. Die Portierung soll Ende 2011 abgeschlossen sein.
Weitere Einzelheiten zum CNM-Projekt und zum CNM für das X-WiN sind zu finden unter:
http://www.cnm.dfn.de .
3.5.3 Géant E2E Link Monitoring
Géant ist eine Weiterentwicklung des europäischen Wissenschaftsnetzes, das ca. dreißig nationale Wissenschaftsnetze verbindet. Neben klassischen IP-Verbindungen können im Rahmen des Géant-Verbundes
auch End-to-End (E2E) Links eingerichtet werden. Das LRZ arbeitet seit Jahren aktiv in Projektteilen
mit, die Konzepte, Verfahren und Tools zum Management dieser Ende-zu-Ende Links bereitstellen. Ein
wesentlicher Bestandteil dieses Projekts ist das E2E Link Monitoring System (E2Emon), das unter Federführung des LRZ konzipiert und entwickelt wurde. Eine ausführliche Beschreibung des zugrunde liegenden Projekts und des Monitoring Systems kann dem Jahresbericht 2008 entnommen werden.
In Géant wird das E2E Monitoring System von der E2E Coordination Unit (E2ECU) betrieben, die gezielt für den Betrieb von E2E Links ins Leben gerufen wurde. Sie überwacht derzeit (Stand Anfang 2011)
35 produktive Links. Weitere 14 Links sind aktuell in der Aufbauphase. Zu den größten Kunden dieses
Dienstes zählen internationale Forschungsprojekte wie das LHC am Cern sowie die europäische GRIDInitiative DEISA.
Bereits seit Mitte 2008 erfüllt E2Emon die von der E2ECU spezifizierten funktionalen Anforderungen.
Deshalb lag 2010 der Fokus hauptsächlich auf einer weiteren Verbesserung der Benutzerfreundlichkeit.
Beispielsweise können die grafischen Ansichten der E2E Links vom Benutzer konfiguriert werden, sodass nicht nur eine horizontale, sondern auch eine vertikale Repräsentation möglich ist (siehe Abbildung
87). Desweiteren können die Listen der Links anhand verschiedener Kriterien sortiert werden. Auch die
konfigurierbare automatische E-Mail Benachrichtigung wurde erweitert und deckt nun zusätzliche Fehlerfälle ab.
152
Abbildung 87: Vertikale Darstellung eines End-to-End Links
Da E2Emon sich in den letzten Jahren als äußerst erfolgreich erwiesen hat und einen hohen Bekanntheitsgrad genießt, wird der Fokus des Tools nun auch in Zusammenarbeit mit internationalen Partnern im
Kontext dynamischer Verbindungen erweitert, wofür 2010 in enger Zusammenarbeit mit amerikanischen
Forschungsnetzen wie Internet2 oder ESnet eine erste Anforderungsanalyse gestartet wurde. Die Liste der
Anforderungen, die in dem derzeitig noch andauernden Prozess erstellt werden, dient als Grundlage für
die Analyse der Defizite existierender Versionen von E2Emon hinsichtlich der Überwachung solcher
dynamischer Verbindungen. In einem nächsten Schritt wird dann untersucht und evaluiert, wie diese Defizite behoben werden können.
3.5.4 Géant I-SHARe
Beim Betrieb von Netzdiensten, die die Zusammenarbeit mehrerer unabhängiger Provider erfordern, ergeben sich neuartige Herausforderungen, die von etablierten IT Service Management Frameworks nicht
adressiert werden. Im Umfeld des von der EU geförderten Géant-Projektes werden diese insbesondere im
Zusammenhang mit sog. Ende-zu-Ende-Verbindungen deutlich, bei denen es sich um dedizierte optische
Multi-Gigabit-Verbindungen - i.A. jeweils über mehrere heterogene optische Netze - handelt. Die 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
153
wurde. Der Pilotbetrieb von I-SHARe, der bis Ende März 2011 andauernd soll, wird vom LRZ übernommen (siehe Abbildung 88). I-SHARe wird derzeit von fünf NRENs für die Planung neuer End-to-End
Links genutzt.
Abbildung 88: I-SHARe Pilotinstallation am LRZ
Nach Beendigung der Pilotphase sollen mögliche Änderungswünsche berücksichtigt und implementiert
werden. Für eine erfolgreiche Überführung in den Produktivbetrieb werden derzeit Management-Prozesse
definiert, die die Zusammenarbeit aller beteiligten Partner definieren sollen.
3.5.5 Géant-Visualisierungswerkzeuge und Performance Monitoring
Das CNM (siehe Kapitel 3.5.2) wird seit 2004 im europäischen Forschungsumfeld als 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 und einigen der 34 angeschlossenen nationalen Forschungsnetze in hierarchischen
Netzkarten visualisiert. Zusätzlich wird das Web-CNM in einer speziell angepassten Version für die
Netzüberwachung des LHCOPN (Large Hadron Collider Optical Private Network) eingesetzt.
Der über Géant realisierte europäische Verbund von 34 nationalen Forschungsnetzen (NRENs) stellt
Netzdienste im paneuropäischen Maßstab zur Verfügung. Ein Beispiel für einen solchen Dienst sind Optical Private Networks (OPNs), die z.B. im Umfeld des LHC-Grid verwendet werden, um das CERN
(Tier-0) mit den Tier-1- und Tier-2-Zentren zu verbinden. Die Dienste werden in einer multinationalen
Kooperation unabhängiger nationaler Forschungsnetzen (NRENs) und DANTE erbracht.
Die entwickelte LHCOPN-Wetterkarte, die den Web-Zugriff auf Status und Kennzahlen der LHCOPNInfrastruktur (Tier-0- zu Tier-1-Verbindungen) einer HTML/CSS-, Java-Script-basierten Implementierung ermöglicht, wird über den Web-Browser angesprochen. Abbildung 89 zeigt ihre Übersichtskarte. Im
letzten Jahr wurde die Anbindung an die produktive E2EMon-Instanz realisiert und die Wetterkarte wird
im LHCOPN-Portal von den Operateuren der LHCOPN aufgerufen. Diese können je ein Paar von zwei
LHCOPN-Standorten (T0/T1 oder T1/T1) auswählen, um Informationen und Kennzahlen über den Link
dazwischen zu erhalten. Für jeden Link werden dabei Ende-zu-Ende (E2E) Kennzahlgraphen von verschiedenen Netzschichten der letzten 24 Stunden angezeigt, nämlich: Hop-Anzahl, One-Way-Delay, Jitter, Paketverlust, verfügbarer TCP-Durchsatz, Verbindungsauslastung, IO-Errors. Diese Kennzahlgraphen
wurden mit einer Funktionalität erweitert, die es ermöglicht, nicht nur die letzten 24 Stunden, sondern
auch bestimmte zurückliegende Zeitintervalle abzufragen und die damit verbundenen Kennzahlen darzustellen. Ein Beispiel einer solchen Abfrage ist in Abbildung 89 dargestellt. Ebenso wird für den ausgewählten Link eine detaillierte Ansicht der Schicht-2-Abschnitte in den verschiedenen beteiligten administrativen Domänen angezeigt
154
Abbildung 89: Hauptansicht der LHC-OPN Wetterkarte
Weiterhin wird für den ausgewählten Link eine detaillierte Ansicht der Schicht-2-Abschnitte in den verschiedenen beteiligten administrativen Domänen angezeigt (siehe Abbildung 90).
Abbildung 90: Historische Kennzahlen für ein LHCOPN-link
Diese Kartenübersicht wurde erweitert und verfeinert zu einer tabellarischen Übersicht, auch
,,Dashboard‘‘ genannt. Hier werden dieselben Kennzahldaten zusammengefasst wie in der Wetterkarte,
nur in einer komprimierter Form: alle Links auf einen Blick. Die Kennzahlen können allein oder kombiniert (z.B. One-Way-Delay und Paketverlust) ausgewählt werden. Ein Tooltip zeigt den entsprechenden
Wert beim Durchlaufen der Matrix.
155
Abbildung 91: Prototypische LHCOPN Dashboard
Zu dieser Sicht kommt noch eine ausführliche dazu, die pro ,,Kästchen‘‘ auch die entsprechenden Kennzahlen anzeigt. Eine zusätzliche Sicht ist die jedes Knoten zu oder von allen anderen. In der Abbildung
werden die kombinierten Kennzahlen für alle eingehenden Verbindungen zu einem Tier-1 Center (FRCCIN2P3) gezeigt.
Abbildung 92: Eingehende Verbindungen zu FR-CCIN2P3 (Ausschnitt)
Auf Basis der im MWN prototypisch entwickelten WebCNM und der LHCOPN Wetterkarte wurde dieses Jahr ein ausführliches WebCNM-Konzept formuliert. Die Funktionalitäten der bestehenden JavaCNM, die sehr vielfältig und seit vielen Jahren im Einsatz sind, werden in diesem WebCNM - Konzept
vollständig auf eine Web-basierte Implementierung übertragen. Abbildung 93 zeigt eine mögliche Sicht
des WebCNM.
156
Abbildung 93: WebCNM - Vision
Für weitere Informationen zum Géant-Projekt und perfSONAR-System, siehe:
http://www.geant.net/Services/NetworkPerformanceServices/Pages/perfSONARMDM.aspx
3.5.6 100GET-E3
Im Rahmen des europäischen Dachprojektes 100 Gbit/s Carrier-Grade Ethernet Transport Technologies
(100GET), das vom BMBF gefördert wurde, wurden Ultra-Hochgeschwindigkeitsnetze basierend auf
Ethernet-Technologien für Übertragungsraten von 100 Gigabit pro Sekunde entwickelt. Durch den breiteren Einsatz von Ethernet-Technik auch in den Backbone-Netzen (sogenanntes Carrier-Grade Ethernet)
erwartet man sich erhebliche Kosteneinsparungen. Das von Nokia Siemens Networks (NSN) geführte
Teilprojekt "End-to-End Ethernet (E3)" entwickelte in Zusammenarbeit mit dem Leibniz-Rechenzentrum
solche Technologien und Protokolle. Das Projekt mit einer Laufzeit von 36 Monaten endete nach einer
dreimonatigen Verlängerung am 31. Dezember 2010.
Im Rahmen dieses Teilprojektes wurde ein Konzept und eine Architektur für ein integriertes InterDomain Network Management System für Ultra-Hochgeschwindigkeitsnetze basierend auf Ethernet- und
DWDM-Techniken spezifiziert. Um extrem breitbandige Verbindungen zwischen zwei Kunden zu schalten, sind häufig mehrere Provider beteiligt, die i.d.R. jeweils unterschiedliche eigene Systeme und Geräte
verschiedener Hersteller verwenden (Heterogenität). Um einen solchen Dienst erbringen zu können, muss
ein Managementsystem in der Lage sein, mit diesen Domänen-übergreifenden (Inter-Domain) Aspekten
umgehen zu können.
Das Themengebiet des IT-Managements lässt sich in die fünf Aufgabengebiete Fault (Fehlermanagement), Configuration, Accounting, Performance und Security Management aufteilen (FCAPS). Im Rahmen dieses Teilprojektes waren insbesondere das Fehler-, Konfigurations- sowie das Performance Management von Interesse. Außerdem wurden die Fragen des Organisationsmodells für domänenübergreifende Zusammenarbeit untersucht.
2010 wurden ein Konzept für Service Level Agreements (SLA) und entsprechende Quality of Service
(QoS) Parameter, ein Konzept für ein Ende-zu-Ende Monitoring System und Incident und Problem Management Prozesse für providerübergreifende Dienste entwickelt. In der dreimonatigen Verlängerung
wurde zusätzlich ein Konzept für einen Proxy-Dienst erstellt, der zwischen Kontrollschicht und Managementschicht vermittelt. Dieser Proxy-Dienst ermöglicht die Kombination verschiedener Protokolle zur
providerübergreifenden Signalisierung von Diensten und damit zu einer schnelleren Verbreitung von
providerübergreifenden Diensten. Abbildung 94 zeigt die prinzipielle Funktion des Proxy-Dienstes, der
zwischen der Kontrollschicht (E-NNI) und der Managementschicht (MTOSI) vermittelt.
Das LRZ beteiligte sich darüber hinaus an der Erstellung eines Positionspapiers zu 100 Gigabit/s Ethernet
Netztechniken.
157
Der Projektpartner Alcatel-Lucent konnte bereits 2010 ein erstes Produkt vorstellen, das im Rahmen von
100GET entwickelt wurde.
Abbildung 94: Konzept des Proxy-Diensts
159
4 Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen
Die Komplexität vieler Tätigkeiten, insbesondere im IT-Service-Management und in Sicherheitsfragen,
erfordert die enge Zusammenarbeit der Spezialisten des LRZ über die Grenzen der internen Organisation
hinweg. Zu diesem Zweck wurden in der Vergangenheit spezielle Arbeitskreise eingerichtet, über deren
Arbeit nachfolgend berichtet wird.
4.1
Arbeitskreis Security
Im Fokus der Arbeit des abteilungsübergreifenden Arbeitskreises „Security“ steht, das bisher erreichte
Sicherheitsniveau im MWN zu überwachen und weiter zu steigern. Auch in diesem Jahr wurde versucht,
dieses Ziel nicht einfach durch den Einsatz weiterer IT-Security-Werkzeuge zu erreichen, sondern vorhandene, bereits bewährte Mechanismen weiter zu optimieren. Neben der Betrachtung rein technischer
Aspekte standen vor allem organisatorische Aspekte im Vordergrund, um die komplexen Problemstellungen in diesem Themengebiet zu lösen. Die technische Umsetzung der erarbeiteten Lösungen erfolgt weiterhin durch die jeweils zuständige Abteilung, mit dem Unterschied, dass diese Lösungen von nun an in
einen hausweiten Gesamtkontext eingebettet und somit aufeinander abgestimmt sind.
Nennenswerte Themen, mit denen sich der Arbeitskreis „Security“ im Jahr 2010 unter anderem auseinander gesetzt hat, sind
• Entwurf einer hausweiten Richtlinie zum Umgang mit Log-Daten, insbesondere die Speicherung,
Verarbeitung und Löschung personenbezogener Daten unter rechtlichen Rahmenbedingungen.
• Entwurf einer MWN-weit gültigen Richtlinie zum Thema „Sichere Passwörter“ und Verschärfung der bis dato gültigen Anforderungen.
• Entwurf einer Richtlinie für den abgesicherten Management-Zugang zu internen Ressourcen von
Hersteller- und Wartungsfirmen und Entwicklung eines Konzepts zur technischen Umsetzung.
• Erstellung einer Richtlinie zur Absicherung von Management-Zugängen zu Netzkomponenten
(Switches, Router) sowie Konzeption und Zeitplanung zu deren technischer Umsetzung.
Das wohl herausragendste Ergebnis der Arbeit des Arbeitskreises „Security“ war 2010 die Erstellung
eines hausweiten Security-Incident-Response-Prozesses sowie dessen offizielle Einführung. Zielsetzung
des Prozesses ist die strukturierte Bearbeitung von detektierten Sicherheitsvorfällen durch ein LRZCSIRT (Computer Security Incident Response Team). Der Prozess beschreibt unter anderem den Ablauf
der Vorfallsbearbeitung und legt Verantwortlichkeiten in Form von definierten Rollen fest. Somit ist gewährleistet, dass bei der Bearbeitung die Tätigkeiten von CSIRT-Mitarbeiter festgelegt sind und damit
keine essentiellen Schritte vergessen oder doppelt durchlaufen werden.
Auch im Jahr 2011 wird die Arbeit des Arbeitskreises „Security“ überwiegend von der Erstellung von
Richtlinien und der Konzeption technischer Umsetzungsmöglichkeiten dieser Richtlinien geprägt sein.
Insbesondere stellt auch die Absicherung des neuen Höchstleistungsrechners SuperMUC eine interessante
Aufgabe dar, mit der sich der Arbeitskreis beschäftigen wird.
4.2
Arbeitskreis IT-Service-Management
Die Zuverlässigkeit und Verfügbarkeit von IT-Services ist in erheblichem Maß auch von der effektiven
Kommunikation, Kooperation und Koordination zwischen den Mitarbeitern des IT-Service-Providers
abhängig. Ein optimales Management von IT-Diensten muss folglich über die Überwachung und Steuerung der technischen Komponenten hinausgehen und auch die betrieblichen Abläufe bzw. die Prozesse
des IT-Service-Providers kontrollieren und lenken.
Die Ausgestaltung eines solchen prozessorientierten IT-Service-Managements (ITSM) ist Gegenstand
sowohl verschiedener so genannter ITSM-Rahmenwerke wie der IT Infrastructure Library (ITIL), als
auch des vergleichsweise neuen internationalen Standards ISO/IEC 20000. Wie bereits im letzten Jahresbericht dargelegt, arbeitet das LRZ daran, seine ITSM-Prozesse an den Vorgaben von ISO/IEC 20000
auszurichten.
Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen
160
4.2.1 Aktivitäten im Bereich IT-Service-Management am LRZ
Der Arbeitskreis IT-Service-Management (AK ITSM) hat zur Aufgabe, ein organisatorisches und technisches Konzept für das ITSM am LRZ zu entwickeln. Er koordiniert die ITSM-Aktivitäten am LRZ, welche jedoch nicht auf Arbeiten innerhalb des Arbeitskreises selbst beschränkt sind. Die bereits im Juli
2009 gegründeten Prozess-Teams „Control“ und „Resolution“ haben ihre Planungen zu einem prozessorientierten Betrieb weiter vorangetrieben.
Im „Control Team“ wurde die Implementierung eines LRZ-weiten, d.h. abteilungsübergreifenden Change- und Configuration-Managements weiter konkretisiert. Prozesse und Konzepte wurden erarbeitet und
in ersten kleinen Pilotprojekten umgesetzt. Im Rahmen des „Resolution Teams“ hat man sich auf die Planung und Einführung eines LRZ-weiten Incident-Managements fokussiert, um dieses zeitnah ausrollen
und damit das alte Trouble-Ticket System ablösen zu können. Beide Teams bestehen wie der AK ITSM
ebenfalls aus Vertretern aller Abteilungen und sind daher auch dafür verantwortlich, den Status der Entwicklungen in den Prozessen dorthin zu berichten.
Die wichtigsten ITSM-Aktivitäten im Jahr 2010 sind analog zur Gliederung der ITSM-Planungen im
letzten Jahresbericht im Folgenden anhand der drei Hauptaspekte „People, Process, Technology“ (Menschen, Prozesse, Technologie) strukturiert.
4.2.1.1
„People“
Auch 2010 wurden Schulungen zu Grundlagen der ISO/IEC 20000 durchgeführt. Insgesamt haben sich so
mittlerweile über 100 LRZ-Mitarbeiter mit dem erfolgreichen Absolvieren einer durch die TÜV SÜD
Akademie durchgeführten Prüfung für das „Foundation Certificate in IT Service Management according
to ISO/IEC 20000“ qualifiziert. Die Schulungen auf dem Professional Level wurden dieses Jahr durch
den weltweit ersten Kurs zur Erlangung der neuen Zertifizierung „Associate Consultant / Auditor“ ergänzt, an dem neben zehn LRZ-Mitarbeitern auch Hochschuldozenten aus verschiedenen Teilen Deutschlands teilnahmen.
Erstmals wurden im Jahre 2010 auch interne Schulungen für das neue ITSM-Tool durchgeführt. Im Rahmen dieser Schulungen wurden über 30 Mitarbeiter an das neue Tool herangeführt und in hands-on Tutorien geschult, wie der vom „Resolution Team“ erarbeitete Incident-Management-Prozess mit dem Tool
umzusetzen ist.
4.2.1.2
„Process“
Die 2008 eingeführten „KOM Change Records (KCRs)“ zur Koordination von Neuanschlüssen, Installationen und Wartungsarbeiten wurden konsequent weiterentwickelt. Die Erfahrungen, die durch die KCRs
gewonnen wurden, sind ebenfalls bei der Planung und Einführung eines abteilungsübergreifenden Change-Managements mit eingeflossen.
Das 2009 definierte Verfahren zur geeigneten und kontrollierten Reaktion auf Störungen mit größerer
Auswirkung, den sogenannten „Major Incidents“, wurde durch den Arbeitskreis „Continuity“ diskutiert
und weiterentwickelt. Als Input diente hierbei in erster Linie die Analyse laufender Vorfälle bzw. derer
Behandlung.
Im Rahmen des „Resolution Teams“ wurde ein LRZ-weiter Incident-Management-Prozess definiert. Dieser Prozess beschreibt ein einheitliches Verfahren, wie mit Störungen und Ereignissen, die eine Minderung der Servicequalität zur Folge haben könnten, umgegangen werden soll. Im Rahmen dieses Prozesses
wurde ein Incident Manager benannt, welcher für den effektiven und effizienten Betrieb des Prozesses
verantwortlich ist. Im August 2010 wurde dann der Incident-Management-Prozess im Rahmen eines Pilotbetriebes eingeführt. Zunächst wurden nur Störungen behandelt, die sich auf den Dienst „LinuxCluster“ bezogen. Nach erfolgreicher Einführung wurde der Betrieb sukzessive auf weitere Dienste ausgeweitet. Im ersten Quartal 2011 soll die Einführung abgeschlossen werden, so dass ab diesem Zeitpunkt
das gesamte LRZ nach einem einheitlichen Prozess arbeitet.
Im Bereich der Control Prozesse wurde ein CMDB-Konzept erarbeitet nach dem künftig im ITSM-Tool
die Infrastruktur und die Dienste des LRZ abgebildet werden. Auch wurde ein Change-Management Prozess definiert, welcher festlegt, wie innerhalb des LRZ mit Änderungen an Komponenten, Applikationen
oder Diensten umgegangen werden soll. Das 2009 definierte Verfahren für „Major Changes“ wurde dabei
in diesen Prozess integriert. Analog zum Incident-Management-Prozess wurde auch hier ein Prozessma-
161
nager benannt, welcher für die Autorisierung von Changes mit größerer Auswirkung verantwortlich ist.
Für ausgewählte Fälle wurde der Prozess bereits herangezogen und getestet.
4.2.1.3
„Technology“: Unterstützung der Prozesse durch die ITSM-Suite
Nachdem 2009 viel Energie in die Auswahl einer ITSM-Suite gesteckt wurde, stand im Jahr 2010 an,
diese Tool-Suite an die Gegebenheiten und Prozesse des LRZ anzupassen und in den Produktivbetrieb zu
überführen. Speziell im Rahmen des Incident-Managements wurde hier viel Aufwand investiert, um das
LRZ-spezifische Incident-Management optimal zu unterstützen. Mit dem Pilotbetrieb des IncidentManagement-Prozesses im August 2010 wurde auch das neue ITSM-Tool für die Mitarbeiter des LRZ
ausgerollt und zur Benutzung freigegeben.
Neben Aktivitäten im Incident-Management wurde 2010 auch an der Tool-Unterstützung für das Changeund Configuration-Management gearbeitet. In kleinen Pilotprojekten wurde evaluiert, wie sich das ITSMTool für die Unterstützung, der durch das „Control Team“ definierten Konzepte eignet. Das Feedback
wurde vom Tool-Entwickler-Team gesammelt und entsprechende Änderungen am Tool durchgeführt.
Eine Anpassung und Weiterentwicklung des Tools wird auch 2011 ein zentraler Aspekt in der Einführung
eines LRZ-weiten IT-Service-Managements sein.
Das Entwickler-Team ist sowohl im Control wie auch Resolution Team vertreten und kann somit die
Anforderungen an die Prozesse gezielt umsetzen. Auch kann dadurch Feedback in die Prozess-Teams
einfließen, so dass ein effektives und effizientes Zusammenspiel zwischen Prozessen und Tool erreicht
werden kann.
4.2.2 Weitere Aktivitäten im Bereich IT-Service-Management
Auch 2010 wurden für Studenten der LMU und der TU München in Zusammenarbeit mit dem Lehrstuhl
Prof. Hegering / Prof. Kranzlmüller zwei Seminare zum Thema „prozessorientiertes IT-Service Management“ angeboten. Wie bei den Schulungen für die Mitarbeiter des LRZ gab es auch für die Studenten die
Möglichkeit, im Anschluss an das Seminar die Prüfung „Foundation in IT Service Management according
to ISO/IEC 20000“ abzulegen und das entsprechende Zertifikat zu erwerben.
Auch ist das LRZ mit Herrn Prof. Dr. Heinz-Gerd Hegering und Herrn Dr. Michael Brenner im Komitee
für die IT-Personenzertifizierung nach ISO/IEC 20000 vertreten. Im Rahmen dieses Komitees wurde das
Rahmenkonzept für Schulungen, Prüfungen und IT-Personenzertifizierung nach ISO/IEC 20000 festgelegt und wird kontinuierlich weiterentwickelt.
4.3
Arbeitskreis Continuity
Der Arbeitskreis trifft sich halbjährlich, um vorgefallene Major Incidents daraufhin zu bewerten, ob Verbesserungen oder Änderungen am Prozess erforderlich sind. Die Revisionssitzung im Frühjahr 2010 befasste sich weitgehend mit Standarthemen wie der Aktualisierung und Verbesserung der Dokumentation
in den roten Ordnern. Eine weiter gehende Veränderung am Prozess wurde im Herbst 2010 beschlossen,
weil sich viele als Major Incidents einzustufende Ereignisse auf den Fall beschränken, dass ein Administrator einen gestörten Dienst wieder in Gang bringt und der Major Incident Coordinator (MIC) dafür sorgt,
dass die betroffenen Nutzer und gegebenenfalls andere Administratoren über die Störung informiert werden.
Die bisher zwingende vorgeschriebene Anwesenheit des MIC im Krisenraum wurde gelockert und seine
Arbeitsweise auf Grund der vorliegenden Störung und ihrer Anforderungen in das Ermessen des MIC
gestellt. Bei einzelnen ausgefallenen Diensten, die keine weitere Koordination innerhalb des LRZ erfordern, kann der MIC daher beispielsweise jetzt auch von zu Hause agieren. Angeregt wurde die vollständige Einbindung des Prozesses ins Incident Management, was zu einer automatischen Einschaltung der
MICs führen würde. Für die Roten Ordner wurde die technische Dokumentation auf den neuesten Stand
gebracht. In der Herbstsitzung des Arbeitskreises Continuity standen darüber hinaus Fragen der Kundenbenachrichtigung im Vordergrund. Es soll eine Kundenliste aufgebaut werden, in die auch die eventuell
vorhandene SLAs einfließen, so dass der MIC seine Koordinationstätigkeit entsprechend priorisieren
kann.
162
4.4
Tätigkeiten in LRZ-weiten strategischen Arbeitskreisen
Arbeitskreis Informationsmanagement
Wie im Jahresbericht 2009 bereits beschrieben, setzt das LRZ historisch bedingt viele Werkzeuge für die
verschiedenen klassischen Aspekte des IT-Managements (Netzmanagement, Systemmanagement usw.)
ein. 2010 wurde als wichtiger Erfolgsfaktor für ein effektives und effizientes Werkzeugkonzept die Realisierung von LRZ-weit gültigen Prozessen für Informationsmanagement und Configuration-Management
identifiziert. Nur durch optimale Integration von Information und Bereitstellung konsistenter Dokumentation lassen sich Konsolidierungen von Tools und Optimierungen erreichen. Um diesen Anforderungen
Rechnung zu tragen, wurde zusätzlich zum bereits existierenden Control-Team der Arbeitskreis Informationsmanagement gegründet.
Im Rahmen des Arbeitskreises Informationsmanagement wurden 2010 unterschiedliche Aktivitäten gestartet, um die Dokumentations- und Informationsstruktur am LRZ zu verbessern. Von insgesamt 38 identifizierten Informationsquellen hat man sich zunächst auf vier Quellen fokussiert, die nach Einschätzen
des Arbeitskreises die wichtigsten und verbreitetsten Ablagen für Dokumentation sind. Ziel des Arbeitskreises war es dann, diese vier Quellen derart zu verbessern, dass übrige Quellen mittelfristig durch diese
zentralen Quellen abgelöst werden können. Ein zentraler Aspekt ist dabei die Einführung eines einheitlichen Dienstleistungsbaumes (DLB) gewesen. Dieser Baum repräsentiert eine Kernstruktur, welche Dienste sowohl intern wie auch extern durch das LRZ erbracht werden. Somit spiegelt dieser Baum eine bestimmte Sichtweise auf den Betrieb des LRZ wider. Der Arbeitskreis hat 2010 damit begonnen, den
Dienstleistungsbaum auf die vier zentralen Informationsquellen zu übertragen und die Struktur der Quellen auf diesen Baum hin anzupassen. Folgende Ziele werden durch diese Maßnahme verfolgt:
• Eine einheitliche Struktur verschiedener Informationsquellen nutzt den Wiedererkennungseffekt.
Kunden sowie auch Nutzer finden sich dadurch auch in Informationsquellen, die sie selten nutzen, schnell zurecht.
• Der DLB gibt eine Struktur wieder, die möglichst unabhängig vom Vorwissen des Nutzers nachvollziehbar und intuitiv ist.
• Der DLB beschreibt eine bestimmte Sichtweise auf das Dienstportfolio des LRZ. Mit der LRZweiten Etablierung des Dienstleistungsbaumes wird auch ein einheitliches Vokabular angestrebt.
• Mit dem Ziel des LRZ, eine ISO-20000-Zertifizierung zu erlangen, sollte das LRZ eine dienstorientierte Sicht auf den Betrieb zunehmend der gruppen- und abteilungsorientierten Sicht vorziehen. Der DLB ist hierfür ein Startpunkt und eine wichtige Voraussetzung.
Des Weiteren hat sich der Arbeitskreis damit beschäftigt, Richtlinien und Beispiele zu veröffentlichen,
wo und wie Informationen abzulegen sind und wie der Dienstleistungsbaum zu verwenden ist. Hierdurch
sollen Hemnisse bei der Dokumentation verringert und die Akzeptanz der zentralen Informationsquellen
gesteigert werden. Dieser Punkt wird auch 2011 weiterhin ein zentraler Aspekt sein, mit dem sich der
Arbeitskreis beschäftigen wird.
163
5 Organisatorische Maßnahmen im LRZ
5.1
Personalveränderungen 2010
5.1.1 Zugänge
Datum
Name
Dienstbezeichnung
Abteilung
01.01.2010
Schaaf Thomas, Dr.
wiss. Mitarbeiter
Hochleistungssysteme
01.01.2010
Übelacker Thomas
wiss. Hilfskraft
Zentrale Dienste
01.02.2010
Goyal Sadhna
wiss. Mitarbeiter
Benutzernahe Dienste und Systeme
01.02.2010
Laschka Christiane
techn. Angest.
01.03.2010
Georgius Danny
techn. Angest.
Zentrale Dienste
01.03.2010
Kloppe Andreas
techn. Angest.
Zentrale Dienste
01.03.2010
Pointner Gernot
stud. Hilfskraft
01.03.2010
Satria Winnu
stud. Hilfskraft
01.03.2010
Schmid Benjamin
techn. Angest.
Zentrale Dienste
15.03.2010
Gong Jing
Werkvertrag
01.04.2010
Bernau Christoph
stud. Hilfskraft
01.04.2010
Crispien Marco
stud. Hilfskraft
01.04.2010
Kam-Thong Tony
stud. Hilfskraft
01.04.2010
Sollinger Florian Martin
stud. Hilfskraft
Kommunikationsnetze
01.05.2010
Busam Benjamin
stud. Hilfskraft
01.05.2010
Etzel Oliver
stud. Hilfskraft
01.05.2010
Heins Julius
stud. Hilfskraft
01.05.2010
Kostadinovski Daniel
techn. Angest.
Zentrale Dienste
01.05.2010
Vicedo Jover Esmeralda
stud. Hilfskraft
01.05.2010
Wiesner Christian
stud. Operateur
Zentrale Dienste
01.06.2010
Eickeler Felix
stud. Hilfskraft
01.06.2010
Kirnberger Albert
techn. Angest.
Zentrale Dienste
01.08.2010
Haltmair Gena
stud. Hilfskraft
Zentrale Dienste
01.08.2010
Lindinger Tobias, Dr.
wiss. Mitarbeiter
01.08.2010
Scherzei Mashud
stud. Hilfskraft
Zentrale Dienste
01.08.2010
Wank Andreas
stud. Hilfskraft
Zentrale Dienste
01.09.2010
Neumann Daniel
techn. Angest.
01.09.2010
Ostermeier Christoph
Auszubildende
Zentrale Dienste
01.09.2010
Podo Alessandro
Auszubildende
Zentrale Dienste
01.09.2010
Schöfer Renate
wiss. Hilfskraft
20.09.2010
Thiele Roman
Praktikant
Kommunikationsnetze
01.11.2010
Hubert Mario
stud. Operateur
Zentrale Dienste
01.11.2010
Längle Bernadette
stud. Hilfskraft
Kommunikationsnetze
01.11.2010
Willoweit Benno
Praktikant
01.12.2010
Auweter Axel
wiss. Mitarbeiter
01.12.2010
Leicht Ludwig
stud. Hilfskraft
Zentrale Dienste
Organisatorische Maßnahmen im LRZ
164
5.1.2 Abgänge
Datum
Name
Dienstbezeichnung
Abteilung
31.01.2010
Güntner Benjamin
Informationselektroniker
Kommunikationsnetze
05.02.2010
Hartmann Daniel
Praktikant
Kommunikationsnetze
28.02.2010
Weidle Stefan
stud. Hilfskraft
31.03.2010
Donauer Martin
stud. Hilfskraft
30.04.2010
Anger Christian Andreas
stud. Hilfskraft
30.04.2010
Dlugosch Sabine
wiss. Hilfskraft
31.05.2010
Turgut Petra
Verw. Angest.
Zentrale Dienste
30.06.2010
Berner Stefan
wiss. Mitarbeiter
31.07.2010
Sollinger Florian Martin
stud. Hilfskraft
Kommunikationsnetze
31.08.2010
Carlson Arthur, Dr.
wiss. Mitarbeiter
31.08.2010
Metko Kerstin
stud. Hilfskraft
Zentrale Dienste
31.08.2010
Pointner Gernot
stud. Hilfskraft
31.08.2010
Sutter Christopher
techn. Angest.
Zentrale Dienste
31.08.2010
Zellner Michael
Hilfskraft
30.09.2010
Schöfer Renate
wiss. Hilfskraft
30.09.2010
Stecklum Martin
stud. Hilfskraft
Zentrale Dienste
30.09.2010
Wagner Frederik
wiss. Mitarbeiter
15.10.2010
Thiele Roman
Praktikant
Kommunikationsnetze
31.10.2010
Maier Andreas, Dr.
wiss. Mitarbeiter
31.10.2010
Spanner Thomas
stud. Operateur
Zentrale Dienste
15.11.2010
Übelacker Thomas
wiss. Hilfskraft
Zentrale Dienste
31.12.2010
Beronov Kamen, Dr.
wiss. Mitarbeiter
31.12.2010
Haltmair Gena
stud. Hilfskraft
Zentrale Dienste
31.12.2010
Hazrat Lida
stud. Hilfskraft
31.12.2010
Satria Winnu
stud. Hilfskraft
31.12.2010
Strauß Maximilian Thomas
stud. Hilfskraft
31.12.2010
Sytcheva Liudmila
wiss. Hilfskraft
5.2
Gebäudemanagement und Gebäudebetrieb
Die Infrastruktur an Elektrizität und Kühlung als wichtigste Aufgabe im Bestandsbau konnte stabil betrieben werden. Hier gab es keine Betriebsunterbrechungen, auch wenn die anhaltenden Bauarbeiten für
die angrenzenden Erweiterungsbauten durchaus Risiken für den Rechnerbetrieb bargen.
In diesem Zusammenhang wurden u.a. folgende Arbeiten im Bestand durchgeführt:
• einzelne Löschsysteme im Bestand wurden bereits demontiert: die Argonlöschung im Höchstleistungsrechnerraum, das Löschgas FM200 im Elektrogeschoss; als künftiger Ersatz dafür wurde die
Löschtechnik „Hochdruckwassernebel“ in diesen Bereichen vorbereitet
• die bisherige Westfassade einschl. Treppenhäusern wurde abgebaut, um den Erweiterungsbau
nahtlos anschließen zu können. Während dieser Umbruchphase kam es durch Starkregen zu einem Wassereinbruch mit Schäden bis auf die Elektroebene im UG
• die Druckerei musste in Vorbereitung eines Verbindungsganges zum Erweiterungsbau verkleinert
werden
• Strom- und Kältetechnik mussten mit der Bestandsstruktur gekoppelt werden, wobei die starke
Schmutz- und Staubentwicklung Anlass zur Sorge wegen möglicher Langfristschäden gibt.
165
5.2.1 Erweiterung des LRZ (Rechner- und Institutsgebäude)
Die Bauarbeiten hatten mit der Betonierung der beiden Grundplatten für die Rechnergebäudeerweiterung
und die des Institutsgebäudes (Bauteil „E“) bereits im Herbst 2009 begonnen. Im Herbst 2010 konnte der
Rohbau vollendet und das Richtfest mit dem bayerischen Innenminister Herrmann als prominentem Gast
und Redner gefeiert werden. Parallel zum Rohbau konnte die technische Gebäudeausstattung bereits weit
vorangetrieben werden: USVs und Notstromdiesel sind eingebracht, Transformatoren und Kühlungskomponenten folgen noch bis Jahresende, auch der neue Anschluss ans Umspannwerk soll bis dahin fertig
gestellt werden.
Abbildung 95: Prof. Bode (Vorsitzender des Direktoriums des LRZ), Bauherr Innenminister Herrmann,
Landrätin Rumschöttel, Erste Bürgermeisterin von Garching Gabor, Profs Hegering und Kranzlmüller
(Direktorium des LRZ), Baudirektor Hoffmann beim Richtfest am 18.10.2010 (v.l.n.r.)
Die Hauptnutzfläche der Rechnerräume wird um etwa 2/3, die Elektro- und Kühlkapazität auf insgesamt
etwa das Fünffache wachsen.
Die Serverkühlung wird überwiegend Wasserkühlung sein. Freie Außenluftkühlung soll in größerem
Umfang als bisher umgesetzt werden. Die angestrebte sog. „Warmwasserkühlung“ (> 35°C Zulauftemperatur) für große Teile des nächsten Höchstleistungsrechners „SuperMUC“ konnte erreicht werden. Die
entsprechend revidierte Planung - mehr „freie“ Kühlung ohne Kompressorkälte - wird derzeit umgesetzt.
Zurzeit werden mit der Fa. IBM, die den Zuschlag zur Lieferung des „SuperMUC“ erhalten hat, die Betriebsrandbedingungen und die Aufstellungsgeometrie geklärt, damit der Fertigstellungsprozess des Gebäudes mit den neuesten Daten fortgesetzt werden kann.
5.2.2 Energieeffizienz
Der hohe und in absehbarer Zeit (ab etwa 2012) kräftig ansteigende Energieverbrauch des LeibnizRechenzentrums für seine Server, seine Höchstleistungsrechner und deren Kühlungsinfrastruktur verlangt
nach neuen Wegen. Das in diesem Zusammenhang für Umwelt und Budget eminent wichtige Thema
Energieeffizienz wurde mit folgenden Maßnahmen vertieft:
• Strombeschaffung: das LRZ nutzt die Gelegenheit, nicht mehr über die TU München mit Strom
versorgt zu werden, zu einer veränderten Beschaffungsweise für Strom. Der bayernweit ausgeschriebene 2-Jahres-Stromversorgungsrahmen für öffentliche Institutionen soll ab Anfang 2011
166
•
•
•
•
nicht länger genutzt werden, sondern das LRZ wird versuchen, seinen weithin gleichmäßigen und
vorhersehbaren Strombedarf („Grundlast“-Charakteristik) von zurzeit ca. 20 GWh/a am Strommarkt zu decken.
Maßnahmen zur energiebewussten Luftkühlung der Rechnerräume wurden vertieft: die im Vorjahr begonnene Trennung von Warm- und Kaltluftströmen wurde verfeinert, indem Vorhänge
zwischen und Blenden innerhalb der Serverracks die Trennung verstärken.
Die Kühlungsplanungen für den Erweiterungsbau wurden energetisch nochmals revidiert: es gelang, für den künftigen Größtverbraucher SuperMUC die neue Technik der Warmwasserkühlung
(Kühlwassertemperaturen > 35°C) zu sichern, so dass einige Kältemaschinen abbestellt werden
konnten.
Die Virtualisiserung von Servern wurde weiter vorangetrieben.
Der Stromverbrauch der LRZ-Server - ohne Kühlungsaufwand - liegt am Jahresende 2010 bei einem Leistungswert von
o Höchstleistungsrechner:
1.050 KW
o Netz- und Server:
380 KW
o Daten- und Archive:
50 KW
5.2.3 Personalausstattung der Hauswerkstätte
Bedingt durch Altersteilzeit wurde die Stärke des fest angestellten Personals der Hauswerkstätte auf ein
Viertel reduziert. Die sehr positiven Erfahrungen mit unserem Facility-Management-Dienstleister führten
dazu, dass seit Februar nicht nur die Kerndienste der Elektro-, Kühlungs-, Leit- und Gefahrentechnik von
extern betreut werden, sondern auch die komplette Haus- und Veranstaltungstechnik.
Allerdings sprengt die derzeitige Zusatzbelastung durch „die Baustelle“ fast die Kapazität. Hier hat sich
insbesondere die Überwachung der Fremdhandwerker der Baustelle als äußerst zeitintensiv erwiesen.
5.3
Dienstleistungskatalog
Der Wunsch anderer Hochschulen und wissenschaftsnaher Institutionen (Fachhochschulen, Bibliotheken,
Max-Planck-Institute, Studentenwerk usw.), IT-Dienste des LRZ für sie zu betreiben und zu betreuen (ITOutsourcing), hat sich auch 2010 weiter verstärkt. Das LRZ hatte schon Ende 2008 eine erste Version
eines Dienstleistungskatalogs in Absprache mit seinem zuständigen Ministerium (Bayerisches 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“. Diese Schrift hatte 2010 den bisher im Jahresbericht enthaltenen Teil über die Dienstleistungen des Leibniz-Rechenzentrums ersetzt und
soll zukünftig regelmäßig den aktuellen Gegebenheiten angepaßt werden.
Teil dieses Dienstkatalogs ist auch eine aktualisierte Klasseneinteilung möglicher Nutzer/Kunden. Anhand dieser Einteilung werden die Antragsteller klassifiziert und die für die Dienstleistung anzusetzenden
Kosten berechnet. Dieser Entscheidungsprozess über die Einteilung ist immer noch nicht vollständig abgeschlossen; er erfolgt in enger Abstimmung mit der Bayerischen Akademie der Wissenschaften und
unserem Ministerium. Die Aktualisierung des sonstigen Regelwerks (u.a. auch der „Benutzungsrichtlinien
des LRZ“) wurde vom Plenum der Bayerischen Akademie der Wissenschaften am 11.06.2010 ohne Gegenstimmen beschlossen und liegt derzeit zur rechtsaufsichtlichen Genehmigung beim Bayerischen
Staatsministerium für Wissenschaft, Forschung und Kunst.
Trotz der noch ausstehenden Entscheidungen wurden im letzten Jahr zusätzlich zu den schon in den Vorjahren erbrachten Dienstleistungen aus dem Bereich der Kommunikationsnetze (Mitnutzung des Münchner Wissenschaftsnetzes sowie die Betreuung lokaler Infrastrukturen), dem Bereich des Hostings von
Clusterknoten für die Exzellenz-Initiative, dem Bereich Backup-/Archiv- und Langzeitarchivierung für
die Bayerische Staatsbibliothek, weitere Dienste für die Hochschulen und die Bayerische Staatsbibliothek
insbesondere aus dem Bereich Hosting virtueller Server erbracht.
5.4
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
167
Mitarbeit in Gremien
BRZL: Arbeitskreis der bayerischen Rechenzentrumsleiter
ZKI: Zentren für Kommunikation und Information
ZKI-Arbeitskreis Universitäts- und Fachhochschul-Rechenzentren
MPG: Beratender Ausschuss für Rechensysteme
MPG: Kuratorium der Institute für Extraterrestrik und Astrophysik
DFN: Diverse Gremien und Ausschüsse
DFG-Gutachtersitzungen
Wissenschaftsrat: Nationaler Koordinierungsausschuss für Höchstleistungsrechnen
IFIP/IEEE: Diverse Working Groups, Program and Organization Committees
GI: Erweitertes Leitungsgremium Fachgruppe KIVS
IT-Beirat fuer das Bibliothekswesen Bayerns (Bayerische Universitäts- und Fachhochschulbibliotheken), ehemals: Kommission für EDV-Planung
D-Grid Beirat
DEISA Executive Committee
Gauss Centre for Supercomputing (GCS)
Gauß Allianz
PRACE Management Board
PRACE Council
PROSPECT
GEG (Géant Expert Group)
5.4.1 Abteilung „Benutzernahe Dienste und Systeme“
•
•
•
•
•
•
•
•
ZKI-Arbeitskreis Verzeichnisdienste
ZKI-Arbeitskreis Multimedia und Grafik
ZKI-Arbeitskreis Verteilte Systeme
Regionale DOAG-Arbeitsgruppe München (Deutsche Oracle Anwendergemeinde)
Arbeitskreis vernetzter Arbeitsplatzrechner (AKNetzPC)
Bayerischer Arbeitskreis Metadirectory und Arbeitskreis AAIVHB-Arbeitskreis
Authentifizierungs- und Autorisierungsinfrastruktur
DFN-Arbeitsgruppe DFN-AAI
DFN-Arbeitsgruppe E-Learning
5.4.2 Abteilung „Hochleistungssysteme“
•
•
•
•
•
•
•
•
•
•
ZKI-Arbeitskreis Supercomputing
KONWIHR (Kompetenznetzwerk für Technisch-Wissenschaftliches Hoch- und Höchstleistungsrechnen in Bayern)
UNICORE Forum (UNICORE User Group)
D-Grid Technical Advisory Board (TAB)
OGF Production Grid Interoperability (PGI) working group
NGI-DE Joint Research Unit (JRU)
SGI User Group
Fortran Standardisierung (International Organization for Standardization (ISO) and the
International Electrotechnical Commission (IEC) through their Joint Technical Committee 1
(JTC1), International Standardization Subcommittee for programming languages (SS22),
Working Group 5 Fortran)
STRATOS (PRACE Advisory Group for Strategic Technologies)
IESP (International Exascale Software Project)
168
•
EESI (European Exascale Software Initiative)
5.4.3 Abteilung „Kommunikationsnetze“
•
•
•
•
•
•
•
•
•
•
•
•
•
•
BHN (Bayerisches Hochschulnetz)
ZKI-Arbeitskreis Netzdienste
Projektgruppe Datenverkabelung (öffentlicher Gebäude in Bayern)
Arbeitskreis IT Service Management in Hochschulen
IT Service Management Forum itSMF
TÜV Komitee Personenzertifizierung nach ISO/IEC 20000
TÜV Komitee Personenzertifizierung nach ISO/IEC 27000
International Conference on Networking and Services (ICNS 2010)
The Fourth International Conference on Advanced Engineering Computing and Applications in
Sciences (ADVCOMP 2010)
DFN Forum Kommunikationstechnologien 2010
DFN CERT Workshop 2010
Second International Conference on Resource Intensive Applications and Services (INTENSIVE
2010)
International Symposium on Integrated Network Management (IM 2011)
Principles, Systems and Applications of IP Telecommunications (IPTComm 2011)
5.4.4 Abteilung „Zentrale Dienste“
•
•
•
5.5
ZKI-Arbeitskreis Softwarelizenzen
ZKI-Arbeitskreis Service-Management und Sicherheit
BSK-Arbeitskreis (Bayerische Software-Kooperation)
Veranstaltungen am LRZ
Titel
Datum
Cloud Camp
21.01.2010
ISO/IEC 27000 Foundation (ITSM 0401)
02.02.2010
Microsoft Uni Roadshow
02. – 03.02.2010
Programming with Fortran
08. – 12.02.2010
DEISA WP 3,4,6
09. – 10.02.2010
PRACE Languages and Prototype Workshop
01. – 02.03.2010
ISO/IEC 20000
01. – 05.03.2010
Paralleles Programmieren
08. – 12.03.2010
NGI-DE Meeting
19.03.2010
ITSM Kompaktseminar
13. – 16.04.2010
Girls Day
22.04.2010
ISO/IEC 20000 Kurs
03. – 05.05.2010 und 07.05.2010
PROSPECT Meeting
05.05.2010
ISHARe Meeting
10. – 12.05.2010
169
DRIHMS Workshop
17. – 18.05.2010
ITSM Workshop Airport Simulation
29.06.2010
DEISA Review Meeting
29. – 30.06.2010
BGCE Research Day
01.07.2010
KONWIHR Workshop
12.07.2010
Parallel Programming with CILK
12. – 13.07.2010
HP Networking Technology Day
14.07.2010
Bayerischer Arbeitskreis Virtualisierung
23.09.2010
DGSI Plenarmeeting
27. – 28.09.2010
PRACE 1IP KickOff
30. – 31.09.2010
Iterative Gleichungslösung und Parallelisierung
04.- 08.10.2010
Advanced Fortran
11. – 15.10.2010
ITSM Kompaktseminar
12. – 14.10.2010
IGE Kickoff
18. – 22.10.2010
Strategisches IT-Management
21.10.2010/11.11.2010/25.11.2010/09.12.2010
Stratos Management Board Meeting and General 07.12.2010
Assembly
Stratos Steering Board Meeting
5.6
20.12.2010
Mitarbeit bei und Besuch von Tagungen und Fortbildungsveranstaltungen
5.6.1 Abteilung „Benutzernahe Dienste und Systeme“
•
•
•
•
•
•
•
•
•
•
•
HW-Beschaffung Bayern Vorbereitung PC-Ausschreibung -Herstellerpräsentation27.01.2010 - 27.01.2010 Nürnberg (Hartmannsgruber)
HW-Beschaffung Bayern Vorbereitung PC-Ausschreibung -Herstellerpräsentation04.02.2010 - 04.02.2010 Nürnberg (Hartmannsgruber)
ZKI Treffen des AK Verzeichnisdienste
08.02.2010 - 09.02.2010 Mannheim (Ebner)
AK Netz PC Treffen
11.03.2010 - 11.03.2010 Regensburg (Fakler)
Treffen mit Vodafone - Mobile Tarife und Best Practice
13.04.2010 - 13.04.2010 Regensburg (Schreiner)
ATT Novel Identity Manager
19.04.2010 - 24.04.2010 Düsseldorf (Goyal)
Transport der Poster in die Uni
12.05.2010 - 12.05.2010 München (Podo)
HW-Beschaffung Bayern Vorbereitung Apple Ausschreibung
12.05.2010 - 12.05.2010 Nürnberg (Hartmannsgruber)
EUNIS Konferenz (eigener Vortrag)
22.06.2010 - 25.06.2010 Warschau -PL (Gillmeister)
Security-Vorträge am Gymnasium
06.07.2010 - 06.07.2010 Penzberg (Bötsch)
AK Meta Directory und AK AAI
07.07.2010 - 07.07.2010 Passau (Ebner)
170
•
•
•
•
•
•
•
•
Besprechung zur Nachfolgelösung des SOPHOS Landeslizenzvertrages
16.09.2010 - 16.09.2010 Regensburg (Fakler, Hartmannsgruber)
Solaris System Performance Tuning
20.09.2010 - 24.09.2010 Heimstetten (Braun)
Secuity-Vorträge am Gymnasium
22.09.2010 - 22.09.2010 Landshut (Bötsch)
DV-Fachseminar
22.09.2010 - 29.09.2010 Paderborn (Oesmann)
Sitzung des AK Netz PC
23.09.2010 - 23.09.2010 Nürnberg (Feck)
ZKI Herbsttreffen
03.10.2010 - 05.10.2010 Duisburg (Ebner)
14.10.2010 - 14.10.2010 Regensburg (Fakler , Hartmannsgruber)
AntiVir-Bayern Marktanalyse und Ausschreibungsvorbereitung
01.12.2010 - 03.12.2010 Regensburg (Hartmannsgruber)
5.6.2 Abteilung „Hochleistungssysteme”
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
VM Ware-Kurs bei HP
18.01.2010 - 22.01.2010 Hulb (Berner)
Workshop Virtualisierung im D-Grid
28.01.2010 - 28.01.2010 Erlangen (Maier)
PRACE TB Meeting
02.02.2010 - 02.02.2010 Paris -FR (Christadler)
PRACE-Hearing, Vormeeting
08.02.2010 - 10.02.2010 Brüssel -BE (Heller)
IBM Laborbesuch
08.02.2010 - 08.02.2010 Böblingen (Brehm, Huber)
EU Proposal Hearing, Call FP7 Infrastructures 2010-2
09.02.2010 - 12.02.2010 Brüssel -BE (Jamitzky, Satzger)
Hearing für EU-Projekt VERCE
09.02.2010 - 11.02.2010 Brüssel -BE (Frank)
AK Netz PC Techn. Workshop VM Ware View
09.02.2010 - 09.02.2010 Nürnberg (Berner)
Meeting of ISO/IEC JTC1/SC22/WG5
14.02.2010 - 21.02.2010 Las Vegas -US (Bader)
Besuch des Klimarechenzentrums
17.02.2010 - 17.02.2010 Hamburg (Baur, Peinkofer)
GCS Marketing Meeting
19.02.2010 - 19.02.2010 Bonn (Brehm)
GPFS Expertenworkshop
22.02.2010 - 23.02.2010 Mainz (Kleinhenz)
PRACE WP6 HPC Workshop (eigener Vortrag)
27.02.2010 - 02.03.2010 Leogang -AT (Rivera)
Konferenz Globus World
01.03.2010 - 06.03.2010 Argonne -US (Heller)
ZKI Arbeitskreis Supercomputing
04.03.2010 - 05.03.2010 Hamburg (Wagner)
LRZ Workshop Parallel Programming of High Performance Systems
08.03.2010 - 12.03.2010 Erlangen (Bader)
LRZ Workshop Parallel Programming of High Performance Systems
08.03.2010 - 10.03.2010 Erlangen (Müller)
ZKI Treffen des AK Sys
09.03.2010 - 11.03.2010 Witten (Biardzki)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
OGF-Meeting
15.03.2010 - 18.03.2010 München (Maier)
DEISA2 WP8 Face-to-Face Meeting
17.03.2010 - 19.03.2010 Barcelona -ES (Leong)
Konferenz "Facing the Multicore-Challenge"
17.03.2010 - 19.03.2010 Heidelberg (Christadler)
BG/P Extreme Scaling Workshop
21.03.2010 - 24.03.2010 Jülich (Allalen)
D-Grid All Hands Meeting
22.03.2010 - 24.03.2010 Dresden (Paisios)
Workshop
22.03.2010 - 25.03.2010 Kochel am See (Guillen)
22.03.2010 - 24.03.2010 Dresden (Carlson, Saverchenko)
Workshop EU-Russia Joint Call
25.03.2010 - 25.03.2010 Brüssel -BE (Brehm)
IGE Meeting
29.03.2010 - 31.03.2010 Brüssel -BE (Frank)
Operations Workshop EGEE-NGI-DE-transition
30.03.2010 - 30.03.2010 Karlsruhe (Saverchenko)
IGE Meeting
EGI-Meeting Cern
06.04.2010 - 07.04.2010 Genf -CH (Heller)
IESP Workshop
12.04.2010 - 14.04.2010 Oxford -GB (Huber)
CUDA Training
18.04.2010 - 22.04.2010 Jülich (Allalen, Weinberg)
DEISA All Hands Meeting (WP 4)
19.04.2010 - 20.04.2010 Paris -FR (Laitinen)
DEISA All Hands Meeting (WP 7)
19.04.2010 - 20.04.2010 Paris -FR (Beronov)
SLA4 Dgrid 2. Workshop
04.05.2010 - 04.05.2010 Berlin (Paisios)
IDRIS Seminar on Co-array Fortran (eigener Vortrag)
05.05.2010 - 06.05.2010 Paris -FR (Bader)
DEISA Training
05.05.2010 - 06.05.2010 London -GB (Leong)
DEISA PRACE Symposium (eigener Vortrag)
11.05.2010 - 12.05.2010 Barcelona -ES (Huber)
LRZ-CEA Collaboration
19.05.2010 - 20.05.2010 Paris -FR (Brehm, Huber, Steinhöfer)
Lustre Workshop
25.05.2010 - 26.05.2010 Jülich (Steinhöfer)
ISC 2010
28.05.2010 - 03.06.2010 Hamburg (Brehm, Christadler Jamitzky, Satzger, Steinhöfer)
Engaging European DCIs together
ROD Teams Workshop
31.05.2010 - 03.06.2010 Amsterdam -NL (Zrenner)
ISC 2010
31.05.2010 - 02.06.2010 Hamburg (Huber)
ROD Teams Workshop
01.06.2010 - 03.06.2010 Amsterdam -NL (Frank)
6 th Erlangen International High-End-Computing Symposium
171
172
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
04.06.2010 - 04.06.2010 Erlangen (Rivera)
2. Treffen der DGI Monitoring Task Force
09.06.2010 - 09.06.2010 Jülich (Saverchenko)
Workshop High Performance Computing, Grids and Clouds
20.06.2010 - 26.06.2010 Cetraro -IT (Heller)
CiHPC Meeting
21.06.2010 - 24.06.2010 Schwetzingen (Hesse)
EESI WP3 and WP4 joint preliminary meeting
28.06.2010 - 28.06.2010 Paris -FR (Huber)
Erweitertes VO-Management Workshop und Mailingliste
29.06.2010 - 29.06.2010 Karlsruhe (Paisios)
Projekttreffen SLA4 Dgrid
05.07.2010 - 05.07.2010 Stuttgart (Paisios)
Kooperation und Besuch der Lomonossov Universität und t-platforms
07.07.2010 - 09.07.2010 Moskau –RU (Brehm, Huber)
Intel Ct Training
24.08.2010 - 26.08.2010 Feldkirchen (Weinberg)
Inca Workshop
25.08.2010 - 31.08.2010 San Diego -US (Saverchenko)
Eigener Vortrag an der Summer School der KTH
26.08.2010 - 27.08.2010 Stockholm -SE (Christadler)
Workshop Distributed Computing and Multidisciplinary Sciences
28.08.2010 - 03.09.2010 Washington -US (Heller)
EuroPar Konferenz
29.08.2010 - 03.09.2010 Ischia -IT (Guillen)
Workshop DGI-2/ FG-2
01.09.2010 - 02.09.2010 Jülich (Paisios, Saverchenko )
PRACE Management Board Meeting
03.09.2010 - 03.09.2010 Frankfurt am Main (Huber)
Globus-Schulung (eigener Vortrag)
06.09.2010 - 10.09.2010 Karlsruhe (Laitinen, Zrenner)
Workshop Open LUSTRE-for Linux
06.09.2010 - 07.09.2010 Jülich (Biardzki)
EGI Technical Meeting
12.09.2010 - 18.09.2010 Amsterdam -NL (Zrenner)
DEISA Training Course
13.09.2010 - 16.09.2010 Edinburgh -GB (Leong)
EGI Technical Forum
14.09.2010 - 17.09.2010 Amsterdam -NL (Heller, Saverchenko)
EGI Technical Meeting (Projektbetreuung)
15.09.2010 - 17.09.2010 Amsterdam -NL (Frank)
ENA-HPC Konferenz
15.09.2010 - 17.09.2010 Hamburg (Biardzki)
Briefing zum Archivserversystem
20.09.2010 - 20.09.2010 Mainz (Baur, Peinkofer)
DV-Fachseminar
22.09.2010 - 29.09.2010 Paderborn (Hufnagl)
Arbeitstreffen SGI User Group
26.09.2010 - 28.09.2010 Hamburg (Weinberg)
ScalaLife Kick-off Meeting
27.09.2010 - 29.09.2010 Stockholm -SE (Allalen, Jamitzky, Satzger)
PRACE Final Review
30.09.2010 - 01.10.2010 Brüssel -BE (Huber)
2nd European Workshop on HPC Centre Infrastructures
05.10.2010 - 08.10.2010 Dourdan -FR (Huber)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Mapper Kick-Off-Meeting
06.10.2010 - 08.10.2010 Amsterdam -NL (Saverchenko)
Projekttreffen SLA4 Dgrid
07.10.2010 - 08.10.2010 Jülich (Paisios)
DEISA Arbeitstreffen WP 3,4,6
12.10.2010 - 15.10.2010 Helsinki -FI (Maier, Saverchenko)
DEISA-Arbeitstreffen WP 2, 3, 4, 6
12.10.2010 - 15.10.2010 Helsinki -FI (Heller)
DEISA-Arbeitstreffen WP 8
12.10.2010 - 15.10.2010 Helsinki -FI (Leong)
DEISA-Arbeitstreffen WP 3, 4, 7
12.10.2010 - 15.10.2010 Helsinki -FI (Laitinen)
DEISA Arbeitstreffen WP 2,5,7
13.10.2010 - 15.10.2010 Helsinki -FI (Beronov)
Face-to-Face Meeting PRACE 1 IP
18.10.2010 - 20.10.2010 Amsterdam -NL (Christadler)
Face-to-Face Meeting
19.10.2010 - 20.10.2010 Amsterdam -NL (Huber)
OGF 30 /Grid 2010
PRACE Autumn School
24.10.2010 - 30.10.2010 Barcelona -ES (Allalen)
6 th International Conference on Network and Services Management (eigene Präsentation)
24.10.2010 - 01.11.2010 Toronto -CA (Lindinger)
UNICORE Forum Members ZKI Arbeitskreis Supercomputing Herbsttreffen
27.10.2010 - 28.10.2010 Göttingen (Wendler)
Blender Conference 2010 (eigener Vortrag)
28.10.2010 - 01.11.2010 Amsterdam -NL (Satzger)
Open Source CFD Intern. Conference 2010
04.11.2010 - 05.11.2010 München (Rivera)
EESI International Workshop
08.11.2010 - 09.11.2010 Amsterdam -NL (Huber)
ISC 2010
12.11.2010 - 20.11.2010 New Orleans -US (Brehm, Bader, Jamitzky)
WP Leaders Face-to-Face Meeting
12.11.2010 - 12.11.2010 Jülich (Huber)
ISC 2010
12.11.2010 - 20.11.2010 New Orleans -US (Christadler, Satzger)
ISC 2010
14.11.2010 - 20.11.2010 New Orleans -US (Huber)
BMBF-Statustagung zum HPC-Isar-Projekt
23.11.2010 - 24.11.2010 Berlin (Guillen)
Meeting zum Deep-Projekt
26.11.2010 - 26.11.2010 Jülich (Huber)
Intel Software Customer Advisory Board (eigener Vortrag)
30.11.2010 - 03.12.2010 Nizza -FR (Bader)
Vmware vSpere 4: Troubleshooting
06.12.2010 - 09.12.2010 Hallbergmoos (Roll)
PRACE 1IP WP7 Face-to-Face Meeting
14.12.2010 - 17.12.2010 Bologna -IT (Rivera, Weinberg)
e-IRGSP3-proposal Kick-off
14.12.2010 - 15.12.2010 Den Haag -NL (Frank)
PRACE 1IP WP7 Face-to-Face Meeting
14.12.2010 - 16.12.2010 Bologna -IT (Christadler)
Seminar (eigener Vortrag)
173
174
15.12.2010 - 16.12.2010 Paris -FR (Heller)
5.6.3 Abteilung „Kommunikationsnetze“
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
First TF/ CSIRT Meeting
25.01.2010 - 27.01.2010 Hamburg (Metzger)
EWNI 2010 - Call for Papers
27.01.2010 - 27.01.2010 Hamburg (von Eye)
Workshop Virtualisierung im D-Grid
28.01.2010 - 28.01.2010 Erlangen (von Eye)
D-Grid Beiratssitzung
05.02.2010 - 05.02.2010 Hannover (Reiser)
Jährlicher LKN Workshop
05.02.2010 - 05.02.2010 Grainau (Lichtinger)
17. DFN Workshop "Sicherheit in vernetzten Systemen
09.02.2010 - 10.02.2010 Hamburg (Reiser)
Sitzung des BHN-AK
25.02.2010 - 25.02.2010 Erlangen (Reiser, Tröbs)
52. DFN Betriebstagung
02.03.2010 - 03.03.2010 Berlin (Marcu)
22.03.2010 - 24.03.2010 Dresden (von Eye)
Konferenz ICN2010 (eigener Vortrag)
10.04.2010 - 16.04.2010 Les Menuires -FR (Fritz)
Treffen mit Vodafone - Mobile Tarife und Best Practice
13.04.2010 - 13.04.2010 Regensburg (Gebert)
Weltleitmesse für Architektur und Technik
15.04.2010 - 15.04.2010 Frankfurt (Glose)
MeetITil Kongress
18.04.2010 - 22.04.2010 Bad Neuenahr (Brenner)
MeetITil Kongress
19.04.2010 - 22.04.2010 Bad Neuenahr (Richter Chr.)
OSI Forum 2010
27.04.2010 - 28.04.2010 Schlangenbad (Glose)
RIPE 60 Meeting
03.05.2010 - 07.05.2010 Prag -CZ (Schmidt)
Seminar Cisco Forum für Forschung und Lehre
05.05.2010 - 06.05.2010 Würzburg (Meschederu)
RES-ITIL Seminar + Präsentation
17.05.2010 - 20.05.2010 Santander -ES (Brenner)
DFN Forum 2010
26.05.2010 - 27.05.2010 Konstanz (Reiser)
DFN: 60. Mitgliederversammlung
07.06.2010 - 08.06.2010 Berlin (Reiser)
Beiratstreffen D-Grid
11.06.2010 - 11.06.2010 Frankfurt (Reiser)
Statusmeeting des 100GET-Projektes
15.06.2010 - 17.06.2010 Stuttgart (Lichtinger)
DNSSEC Meeting
16.06.2010 - 16.06.2010 Frankfurt (Schmidt)
Secure Code Training
21.06.2010 - 24.06.2010 Poznan -PL (Fritz)
9th RoEduNet Conference (eigener Vortrag)
23.06.2010 - 27.06.2010 Sibiu -RO (Hommel, Marcu)
GIDS Meeting
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
30.06.2010 - 30.06.2010 Hamburg (von Eye)
7th International Conference on Services Computing IEEE SCC 2010
03.07.2010 - 12.07.2010 Miami -US (Yampolskiy)
1st International Workshop on the perfSONAR Network Measurement Infrastructure
06.07.2010 - 10.07.2010 Washington -US (Fritz)
10th Workshop on IP EuroView 2010
01.08.2010 - 03.08.2010 Würzburg (Lichtinger)
GN3 Summer Developers School
29.08.2010 - 03.09.2010 Gdansk -PL (Fritz, Marcu, Schmitz, Yampolskiy)
Internet 2000 Konferenz
19.09.2010 - 26.09.2010 Valencia -ES (Yampolskiy)
IBM Tivoli Network Manager 3.8 Workshop
19.09.2010 - 22.09.2010 Hamburg (Loidl, Tröbs)
D-Grid Security Workshop
29.09.2010 - 30.09.2010 Göttingen (von Eye)
Beiratssitzung D-Grid
04.10.2010 - 04.10.2010 Hannover (Reiser)
BHN-Sitzung
14.10.2010 - 14.10.2010 Passau (Reiser, Tröbs)
DFN Tutorium und Betriebstagung
25.10.2010 - 27.10.2010 Berlin (Metzger)
Netforum Expertentagung
27.10.2010 - 28.10.2010 Meckenbeuren (Glose)
DENOG2-Meeting
04.11.2010 - 04.11.2010 Frankfurt (Schmidt)
Schulung F5 LTM Training
11.11.2010 - 12.11.2010 Dornach (Kornberger)
Service Computation 2010 (eigener Vortrag)
20.11.2010 - 26.11.2010 Lissabon -PT (Yampolskiy)
IPv6 Deployment Council (eigener Vortrag)
23.11.2010 - 23.11.2010 Hallbergmoos (Reiser, Schmidt)
2th GN3 Symposium
24.11.2010 - 26.11.2010 Wien -AT (Fritz, Schmitz)
DFN-Mitgliederversammlung
30.11.2010 - 01.12.2010 Bonn (Reiser)
5.6.4 Abteilung „Zentrale Dienste“
•
•
•
•
•
•
•
•
•
2. Netzwerktreffen NEMO Green IT
14.01.2010 - 14.01.2010 Meckenbeuren (Breinlinger)
BSK Sitzung
27.01.2010 - 27.01.2010 Würzburg (Diehn)
Gutachtersitzung Netz 2010
17.02.2010 - 18.02.2010 Münster (Apostolescu)
BSK-Sitzung
02.03.2010 Hochschule München (Diehn, Palm)
ZKI Arbeitskreis Software-Lizenzen
21.03.2010 - 22.03.2010 Berlin (Diehn)
Wirtschaftsprüfer Dr. Küfner
16.04.2010 - 16.04.2010 Landshut (Apostolescu)
BRZL-Klausurtagung
20.04.2010 - 21.04.2010 Hirschberg (Apostolescu)
Workshop „Punktgenau Texten“
28.04.2010 gate Garching (Palm)
Personal-Fachinformation
175
176
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
5.7
29.06.2010 - 29.06.2010 München (Apel)
DFN Betriebsausschussitzung
30.06.2010 - 30.06.2010 Berlin (Apostolescu)
Teilnahme am erweiterten Projektsteuerkreis GCS in Bonn
25.08.2010 - 25.08.2010 Bonn (Apostolescu)
DV-Fachseminar
22.09.2010 - 29.09.2010 Paderborn (Mende)
4th Workshop on HPC Best Practices: Power Management
25.09.2010 - 01.10.2010 San Francisco -US (Breinlinger)
ZKI Arbeitskreis Software-Lizenzen Herbsttreffen
27.09.2010 - 29.09.2010 Merseburg (Diehn)
Query-Schulung
06.10.2010 - 06.10.2010 München (Apel)
BSK Sitzung
12.10.2010 - 12.10.2010 Bamberg (Diehn)
Power Building Kongress
13.10.2010 - 14.10.2010 München (Kirnberger)
14.10.2010 - 14.10.2010 Regensburg (Diehn)
Werksabnahme von Schaltschränken
15.11.2010 - 15.11.2010 Salzburg -AT (Kirnberger)
Meeting zum Deep-Projekt
25.11.2010 - 26.11.2010 Jülich (Palm)
AntiVir-Bayern Marktanalyse und Ausschreibungsvorbereitung
02.12.2010 - 03.12.2010 Regensburg (Diehn)
Jahresschluss-Tagung TVöD/TV-L
08.12.2010 - 08.12.2010 München (Apel)
Info-Veranstaltung zur Verlängerung des Campus-Vertrages mit Microsoft
15.12.2010 - 15.12.2010 Nürnberg (Diehn)
Öffentlichkeitsarbeit
Seine originären Dienstleistungen als Rechenzentrum der Hochschulen stellte das LRZ u.a. wieder bei der
Erstsemesterbegrüßung an der LMU vor.
Wie auch in den vergangenen Jahren war das LRZ „Location“ für Foto- und Filmaufnahmen z.B. des
Bayerischen Rundfunks oder RTL, für das MPI für Astrophysik, einen Werbefilm für das Informatikstudium an der TU München oder künstlerische Technik-Aufnahmen. Der Dokumentarfilm „Plug & Pray“
von Jens Schanze, für den ebenfalls Szenen am LRZ gedreht wurden, wurde vielfach, u.a. mit dem Bayerischen Filmpreis als „Bester Dokumentarfilm 2010“ ausgezeichnet. Immer häufiger suchen auch die
überregionalen Printmedien den Direktor des LRZ oder seine Wissenschaftlichen Mitarbeiter als Gesprächspartner.
In der „Langen Nacht der Wissenschaften“ am 15. Mai 2010 nutzten etwa eintausend Besucherinnen und
Besucher die Möglichkeit, das LRZ zu besichtigen. Auch das Angebot des LRZ zum Girls Day war wieder vollständig ausgebucht. Insgesamt nahmen ca. 2.650 Besucherinnen und Besucher an etwa 90 Führungen teil.
Bemerkenswert ist die Zunahme der europaweiten und internationalen Aktivitäten des LRZ, die auch in
der wissenschaftlichen und allgemeinen Öffentlichkeit wahrgenommen werden. So beteiligte sich das
LRZ an der Organisation des Open Grid Forums im März 2010. Dessen Besuch nutzten Dr. Kostas Glinos und Dr. Kyriakos Baxevanidis von der Kommission der Europäischen Union für eine Besichtigung
des LRZ. Im August trafen sich am LRZ 121 Teilnehmer aus 21 europäischen Ländern, um den Eintritt
177
des europäischen PRACE-Projektes in eine wichtige Phase zu starten. Und im Oktober besichtigte der
Russische Staatsminister für Kommunikation und Massenmedien Igor Shchegolev das LRZ.
Einen weiteren Ministerbesuch und ein äußerst großes nationales und internationales Medienecho erlebte
das LRZ anlässlich der Unterzeichnung des Vertrages über den nächsten Höchstleistungsrechner. In Anwesenheit des Bayerischen Staatsministers für Wissenschaft, Forschung und Kunst, Dr. Wolfgang Heubisch, unterzeichneten am 13. Dezember 2010 Prof. Dr. Arndt Bode und Martin Jetter, Vorsitzender der
Geschäftsführung der IBM Deutschland GmbH, den Vertrag für den „SuperMUC“.
Das LRZ gab gemeinsam mit dem NIC Jülich und dem Hochleistungsrechenzentrum Stuttgart zweimal
im Jahr anlässlich der Supercomputing-Konferenzen die Zeitschrift „inSiDE – Innovatives Supercomputing in Deutschland“ mit Beiträgen über Projekte, die auf dem Höchstleistungsrechner des LRZ bearbeitet
wurden, heraus.
Darüber hinaus erschien monatlich der LRZ-Newsletter, in dem u.a. Termine, Veranstaltungen, Kurse
und Stellenangebote mitgeteilt wurden und der über eine Mailingliste verteilt sowie im Web angeboten
wird. Dort ist auch ein Newsletter-Archiv verfügbar.
Ferner stehen Faltblätter zur Verfügung, die sich auf Deutsch oder Englisch an die allgemeine Öffentlichkeit wenden oder speziell für Studenten die Dienstleistungen des LRZ vorstellen.
Für die Zusammenarbeit mit den Medien erwies es sich als äußerst vorteilhaft, ihnen einen festen Ansprechpartner (http://www.lrz.de/presse/) nennen zu können.
5.8
LRZ als Ausbildungsbetrieb
Seit 2007 ist das LRZ als Ausbildungsbetrieb anerkannt und bietet Ausbildungsplätze für IT-SystemElektroniker und Fachinformatiker Systemintegration an. Im Jahr 2010 haben die ersten Auszubildenden
ihre Ausbildung am LRZ erfolgreich abgeschlossen. Durch eine im Rahmen der Altersteilzeit freiwerdende Stelle konnte ein Auszubildender erfolgreich übernommen werden. Die bisherigen Erfahrungen mit
den Auszubildenden sind so positiv, dass auch mit Beginn des Ausbildungsjahres 2010/2011 zwei weitere
Auszubildende eingestellt wurden (1 Fachinformatiker Systemintegration, 1 IT-Systemelektroniker).
Auch für das Ausbildungsjahr 2011/2012 ist geplant, wieder zwei Auszubildende einzustellen. Die Bewerberauswahl hierzu hat bereits Ende 2010 in Kooperation mit der Technischen Universität München
stattgefunden.
5.9
Betreuung von Diplom-, Bachelor-, Master- und Studienarbeiten
Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung Benutzernahe Dienste und Systeme betreut:
•
•
Xia, W., Evaluation des TUM–Trouble Ticket Systems als Ersatz für bestehende lokale Konfigurationsmanagementdatenbanken, Fortgeschrittenenpraktikum, Ludwig–Maximilians–Universität
München, Januar, 2010.
Nguyen, T. H., Erweiterung des TUM Trouble Ticket Systems um IT Service Management Komponenten, Systementwicklungsprojekt, Technische Universität München, März, 2010.
Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung
Kommunikationsnetze betreut:
•
•
•
Abeldt, P., Einführung von Multi–Protocol Label Switching (MPLS) im Münchner Wissenschaftsnetz, Diplomarbeit, Ludwig–Maximilians–Universität München, September 2010.
Hauser, M., Toolgestützte Umsetzung von Change–Verfahren für VM–Provisioning nach
ISO/IEC 20000, Diplomarbeit, Ludwig–Maximilians–Universität München, Juni 2010
Müller, A., Linux-basierte Personal Firewall für den Einsatz am LRZ, Fortgeschrittenenpraktikum, Ludwig-Maximilians-Universität München, November 2010.
Folgende Diplom-, Bachelor-, Master- und Studienarbeiten wurden von Mitarbeitern der Abteilung Hochlseitungssysteme betreut:
178
•
Schulz, Chr., Beurteilung der Sicherheit von Proxy Zertifikaten im Globus Toolkit, Fortgeschrittenenpraktikum, Ludwig-Maximilians-Universität München, September 2010.
5.10 Veröffentlichungen der Mitarbeiter 2010
ALLALEN M., M. BREHM, H. STUEBEN, Combining MPI with OpenMP Parallelism in Large Scale
QCD Simulations, inSiDE Vol. 8, No. 2, Spring (2010)
ALLALEN M., H. SATZGER, F. JAMITZKY, Real World Application Acceleration with GPGPUs,
inSiDE Vol. 8, No. 1, Spring (2010)
BADER R., A. BLOCK, PGAS – Incorporating parallelism into C and Fortran. PRACE workshop, LRZ.
Februar 2010. (http://www.prace-project.eu/documents/12_cafupc_rb.pdf)
BADER R., A. BLOCK, PGAS concepts for classical HPC programming languages. Vortrag am IDRIS,
Frankreich. Mai 2010. (http://www.idris.fr/data/seminaires/2009-2010/Seminaire-IDRIS-du-6-mai2010.html)
BADER R., Contributions to WG5 paper N1835 (Requirements for TR of further coarray features, by J.
Reid). September 2010. (ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1835.txt)
BODE A., IntegraTUM-Lehren aus einem universitären Großprojekt. In: Bode/Borgeest (Hrsgb.): Informationsmanagement in Hochschulen. pp.3-12, Springer, Heidelberg 2010
BODE A., R. BORGEEST, Informationsmanagement in Hochschulen. 446 pp., Springer, Heidelberg,
2010
BENEDICT S., M. BREHM, M. GERNDT, C. GUILLEN, W. HESSE, V. PETKOV, Automatic Performance Analysis of Large Scale Simulations. In: Proceedings of the Euro-Par 2009 Parallel Processing
Workshops. Springer, 2010
BIARDZKI C., W. BAUR, B. REINER, Integrierte Speichersystem-Architektur zur Unterstützung hochschulübergreifender IT-Dienste. In: Informationsmanagement in Hochschulen. Springer, 2010
CARLE G., H. REISER, G. CAMARILLO, V. K. GURBANI, (Eds.): Principles, Systems and Applications of IP Telecomunications; Proceedings of IPTComm 2010, Network Architecture and Services, NET
2010-08-1, August 2010
CARLE G., H. REISER, G. CAMARILLO, V. K. GURBANI, (Eds.): Principles, Systems and Applications of IP Telecommunications; Proceedings of IPTComm 2010, ACM Digital Library, 2010
CHRISTADLER I., V. WEINBERG, RapidMind: Portability across Architectures and its Limitations. In:
Facing the Multicore-Challenge: Aspects of New Paradigms and Technologies in Parallel Computing
(Lecture Notes in Computer Science / Theoretical Computer Sci), Springer 2010
DIAZ M., D. AVRESKY, A. BODE, C. BRUNO, E. DEKEL, Cloud Computing. 271 pp., Springer Heidelberg, 2010
DIEHN M., IntegraTUM Teilprojekt E-Mail: Aufbau eines man-dantenfähigen Groupware-Services und
seine Integration in Identity Management und E-Mail Infrastruktur der Technischen Universität München.
In: Informationsmanagement in Hochschulen. Springer, Januar 2010
DIEHN M., A. HAARER , A. SCHREINER, M. STORZ, IntegraTUM Teilprojekt E-Mail: Rezentralisierung von E-Mail-Services. In: Informationsmanagement in Hochschulen. Springer, Januar 2010
GONG J., W. TIANDI, R. W. STARK, F. JAMITZKY, W. M. HECKL, H. J. ANDERS, M. LECH, S. C.
RÖSSLE, Inhibition of Toll-like receptors TLR4 and 7 signaling pathways by SIGIRR: A computational
approach, Journal of Structural Biology, Volume 169, Issue 3, March 2010, Pages 323-330
GONG J., W. TIANDI, N. ZHANG, F. JAMITZKY, W. M. HECKL, S. C. RÖSSLE, R. W. STARK,
TollML: a database of toll-like receptor structural motifs Journal of Molecular Modeling, Volume 16,
Number 7, 1283-1289
HAMM M. K., S. KNITTL, P. MARCU, M. YAMPOLSKIY, Modellierung Interorganisationaler It–
Service–Managementprozesse, Praxis der Informationsverarbeitung und Kommunikation, 2010, K.G.
Saur, München, Germany, Dezember, 2010
ILGENFRITZ M., K. KOLLER, Y. KOMA, G. SCHIERHOLZ, V. WEINBERG, Topological Structure
of the QCD Vacuum Revealed by Overlap Fermion. In: High Performance Computing in Science and
Engineering, Garching/Munich 2009, Springer 2010
179
JAMITZKY F., R. W. STARK, Intermittency in amplitude modulated dynamic atomic force microscopy,
Ultramicroscopy Volume 110, Issue 6, May 2010, Pages 618-621
KONIGES A. E., K. YELICK, R. RABENSEIFNER, R. BADER, D. EDER, Supercomputing Tutorial
S10: Introduction to PGAS (UPC and CAF) and Hybrid for Multicore Programming. Refereed Tutorial.
November 2010. (http://sc10.supercomputing.org/schedule/event_detail.php?evid=tut117)
LICHTINGER B., O. HANKA, Secure setup of inter-provider Ethernet services based on a novel naming
schema. In: NOMS 2010: 12th IEEE/IFIP Network Operations and Management Symposium. Osaka,
Japan, April, 2010
MARCU P., W. HOMMEL, Requirements and concepts for an inter–organizational fault management
architecture, In Proceedings of the 9–th RoEduNet International Conference, IEEE Computer Society,
Sibiu (Hermannstadt), Romania, Juni, 2010.
MARCU P., D. SCHMITZ, A. HANEMANN, S. TROCHA, Monitoring and Visualization of the Large
Hadron Collider Optical Private Network, In Proceedings of the 9–th RoEduNet International Conference, IEEE Computer Society, Sibiu (Hermannstadt), Romania, Juni, 2010
SATZGER H., Frankie im Wunderland. In: Aviso. Bayerisches Staatsministerium für Wissenschaft, Forschung und Kunst, 2010
STUEBEN H., M. ALLALEN, Extreme scaling of the BQCD benchmark, Jülich BlueGene/P Extreme
Scaling Workshop March 22 - 24, 2010. (http://www.fz-juelich.de/jsc/docs/printable/ib/ib-10/ib-201003.pdf)
YAMPOLSKIY M., W. HOMMEL, P. MARCU, M. K. HAMM, An information model for the provisioning of network connections enabling customer–specific End–to–End QoS guarantees. In: Proceedings
of the IEEE SCC 2010 International Conference on Services Computing, IEEE Computer Society, Miami, USA, Juli, 2010
YAMPOLSKIY M., W. HOMMEL, B. LICHTINGER, W. FRITZ, M. K. HAMM, Multi–Domain End–
to–End (E2E) Routing with multiple QoS Parameters — Considering Real World User Requirements and
Service Provider Constraints. In: Proceedings of 2010 Second International Conference on Evolving Internet, 9–18, IARIA, Valencia, Spanien, September, 2010
YAMPOLSKIY M., W. HOMMEL, D. SCHMITZ, M. K. HAMM, Generic Function Schema for Operations on Multiple Network QoS Parameters. In: Proceedings of The Second International Conferences on
Advanced Service Computing SERVICE COMPUTATION 2010, IARIA, Lisabon, Portugal, November,
2010
WAGNER S., M. STEINMETZ, A. BODE, M. M. MÜLLER, High Performance Computing in Scienöce
and Engineering, Garching/Munich 2009, 780 pp. Springer Berlin, Heidelberg, 2010
WEINBERG V., M. BREHM, I. CHRISTADLER, OMI4papps: Optimisation, Modelling and Implementation for Highly Parallel Applications. In: High Performance Computing in Science and Engineering,
Garching/Munich 2009, 51-62, Springer Berlin Heidelberg, 2010
181
6 Regelwerk des LRZ
Auf den in den früheren Jahren üblichen Abdruck der Dokumente wird verzichtet. Stattdessen finden Sie
hier die Sammlung der URLs für die Webseiten des LRZ, auf denen diese Dokumente zu finden sind.
Dies dient u. a. der höheren Aktualität, da auf den Webseiten des LRZ immer die aktuelle Fassung steht.
http://www.lrz-muenchen.de/wir/regelwerk/
6.1
Satzung der Kommission für Informatik
http://www.lrz-muenchen.de/wir/regelwerk/satzung/
6.2
Mitglieder der Kommission für Informatik
http://www.lrz-muenchen.de/wir/komm-mitgl/
6.3
Benutzungsrichtlinien für Informationsverarbeitungssysteme
http://www.lrz-muenchen.de/wir/regelwerk/benutzungsrichtlinien/
6.4
Betriebsregeln des Leibniz-Rechenzentrums
http://www.lrz-muenchen.de/wir/regelwerk/betriebsregeln/
6.5
Richtlinien zum Betrieb des Münchner Wissenschaftsnetzes (MWN)
http://www.lrz-muenchen.de/wir/regelwerk/netzbenutzungsrichtlinien/
6.6
Richtlinien zur Nutzung des Archiv- und Backupsystems
http://www.lrz-muenchen.de/services/datenhaltung/adsm/Richtlinien/
6.7
Gebühren des Leibniz-Rechenzentrums
http://www.lrz-muenchen.de/wir/regelwerk/gebuehren/
6.8
Zuordnung von Einrichtungen zu LRZ-Betreuern
http://www.lrz-muenchen.de/wir/betreuer/
6.9
Betriebs- und Organisationskonzept für den Höchstleistungsrechner
in Bayern (HLRB)
http://www.lrz-muenchen.de/services/compute/hlrb/rules/organisationskonzept/
6.10 Nutzungs- und Betriebsordnung für den Höchstleistungsrechner in
Bayern (HLRB)
http://www.lrz-muenchen.de/services/compute/hlrb/rules/betriebsordnung/
6.11 Mitglieder des Lenkungsausschusses des Höchstleistungsrechners in
Bayern (HLRB)
http://www.lrz-muenchen.de/services/compute/hlrb/steering/
182
Regelwerk des LRZ
183
7 Technische Ausstattung
7.1
Speicher
BRUTTOKAPAZITÄTEN ONLINESPEICHER (NAS+SAN)
Typ
Modell
Anwendung
NAS
2x NetApp FAS 3050
E-Mail LRZ, interne Server, ArbeitsplatzFiledienste, Speicherhosting LMU, WWW
NAS
1 x NetApp FAS 3050
Linux compute cluster repository
NAS
2 x NetApp FAS 3170
Speicher für LZA-Projekte der BSB
586 TB
NAS
1 x NetApp FAS 270c
Staging / Testsystem
0,4 TB
NAS
1 x NetApp R200
Replikation (asynchrones Spiegeln)
36 TB
NAS
2 x NetApp FAS 6070
Speicher für die Wissenschaft (SFW)
117 TB
NAS
1 x NetApp FAS 6070
Replikation für den SFW und VMWare
305 TB
NAS
2 x NetApp FAS 3170
Metrocluster für VMWare
168 TB
NAS
8 x NetApp FAS 3050
Projektspeicherplatz HLRB II
Replikation Projektspeicherplatz HLRB II
NAS
6 x NetApp FAS 3170
Linux-Computecluster
NAS
2 x SUN 7310
Speicher für Datenbanken und VMWare
22 TB
NAS
1 x SUN 7210
Replikation für SUN7310
23 TB
NAS
2 x NetApp FAS 3170
Metrocluster für Hochschulstart.de
50 TB
NAS
Gesamt
NAS
SAN
2 x SUN Flex Line 380
Cache für Archiv- und Backupsystem
49 TB
SAN
2 x SUN 6540
61 TB
SAN
1 x STK D280
Datenbanken, AFS
14 TB
SAN
1 x IBM DS3500
58 TB
SAN
3 x SUN 6780
454 TB
SAN
SGI
Paralleles Filesystem des HLRB II
600 TB
SAN
6x SGI IS4500
170 TB
SAN
Gesamt
SAN
1.406 TB
Gesamt
NAS+SAN
3.490 TB
Kapazität
46 TB
9 TB
97 TB
49 TB
576 TB
2.084 TB
Technische Ausstattung
184
Die Tabelle gibt differenziert nach Speicherarchitektur einen Überblick über die Bruttokapazität der Plattenspeichersysteme des LRZ Ende 2010 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
7.2
Bandbibliothek
Bandlaufwerke
Kassetten
IBM TS3500 Tape Library
10 x IBM LTO 4
8 x IBM LTO 5
5.000
7.500 TB
Library SUN SL8500
16 x IBM LTO 5
16 x IBM LTO 5
6.500
9.750 TB
Library SUN SL8500
26 x SUN T10K
9.300
9.300 TB
Gesamt
76
20.800
26.550 TB
Rechner und Server
7.2.1 Höchstleistungsrechner SGI Altix 4700
Komponenten
(Anzahl
und
Typ)
Gesamter
Hauptspeicher
(in GB)
Systemdaten
Anzahl
der
Typ der KomKompo- ponenten
nenten
Anzahl der
Prozessoren
der Komponente
Hauptspeicher Aufgabe
der Komponente
Kapazität
Komponenten
(Anzahl
und
Typ)
Gesamter
Hauptspeicher
(in GB)
19 Parti- 38912
tionen
185
Systemdaten
Hauptspeicher Aufgabe
der Komponente
Anzahl
Typ der Komder
Kompo- ponenten
nenten
Anzahl der
Prozessoren
der Komponente
19
Je Partition: 19 x 2 TB
512 Montecito Prozessorkerne
6 SharedMemoryPartitionen mit
Dual-SocketBlades
13 SharedMemoryPartitionen mit
Single-SocketBlades
Alle Partitionen
sind über das
NumaLink4Verbindungsnetzwerk eng
gekoppelt.
Höchstleistungsrechner für
Benutzer aus den Hochschulen in Deutschland; für die
Nutzungsberechtigung ist
eine spezielle Begutachtung
durch den wissenschaftlichen
Lenkungsausschuss notwendig. Typ: Parallel-Rechner
7.2.2 Hochleistungs-Linux-Systeme
Am LRZ selbst konfigurierter Linux-Cluster, der aus 838 Komponenten mit insgesamt 14.165 GB Hauptspeicher besteht, die mit Gbit, Myrinet oder 10 Gbit Ethernet vernetzt sind.
Systemdaten
Anzahl
Anzahl der Hauptder
Typ der Kom- Prozessoren speicher Aufgabe
Kompo- ponenten
der Kompo- der Komnenten
ponente
nente
837
Linux-Cluster zur Bearbeitung üblicher,
auf Linux verfügbarer Anwendungsprogramme und für Programme, die mittels
MPI parallelisierbar sind. Der Cluster
besteht aus den im folgenden aufgezählten Komponenten
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
Zentraler nagios-Überwachungsserver
18
diverse
2 x 64 GB Komponente des Linux-Clusters:
8 x 2 GB Log-, Monitoring, Installations- u.a. Ser1 x 4 GB ver
7 x 8 GB
4-8
186
Systemdaten
Anzahl
Anzahl der HauptTyp der Kom- Prozessoren speicher Aufgabe
der
Kompo- ponenten
ponente
nente
1 x 5 GB
4 x 2 GB
1 x 8 GB
9 x 6 GB
Test-cluster
MEGWARE
4
EM64T,
3600
MHz
2 GB
x86_64-Interaktivrechner
2
MEGWARE
8
Opteron,
2600
MHz
32 GB
Komponente
des
Linux-Clusters:
x86_64-Interaktivrechner
2
INTEL
8
Itanium2 (Montecito),
1600
MHz
16 GB
Komponente
des
IA64-Interaktivrechner
9
MEGWARE
2
Opteron,
2400
MHz
1 x 8 GB
8 x 4 GB
Attended Cluster-Housing-Knoten des
Lehrstuhls für Bauinformatik der TUMünchen
8
MEGWARE
8
Xeon
E5462,
2800 MHz
16 GB
Lehrstuhls für Geodäsie der TUMünchen
15
SUN 4600
16
Opteron,
2800
MHz
64 GB
Lehrstuhls für Mathematik der TUMünchen
8
SGI Altix XE 4
240 Xeon, 2333
MHz
16 GB
Münchner Astro-GRID-Projektes
35
MEGWARE
4
Xeon
X3230,
2667 MHz
8 GB
Attended Cluster-Housing-Knoten der
Bayerischen Staatsbibliothek
37
SUN
Opteron,
MHz
4
8 GB
Komponente
des
Linux-Clusters:
LCG Tier-2 Rechen-Knoten
124
MEGWARE
4
Xeon
X3230,
2667 MHz
8 GB
Komponente
des
Linux-Clusters:
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
15
diverse
1
2
2600
Linux-Clusters:
187
Systemdaten
Anzahl
der
Kompo- ponenten
ponente
nente
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:
10
FMS
Opteron,
MHz
2 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
48
LMU, LS Prof. Ruhl
6
NVIDIA Tesla 960 GPUs
S1070-1/2MX16
16
LMU, LS Prof. Ruhl
20
SUN
Opteron, 4
2600 MHz
8 GB
Komponente
des
Linux-Clusters:
Serielle x86_64-Cluster Knoten
36
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
1
SGI Altix 4700 256
Montecito, 1600
MHz
1024 GB
IA64-SMP-Rechner:
• 2 Prozessorkerne dediziert für
OS
interaktives Arbeiten
par. Jobs
2200
2
4
188
Systemdaten
Anzahl
der
Kompo- ponenten
ponente
nente
1
SGI
Altix 512
ICE8200
Xeon
E5540,
2533 GHz
1536 GB
X86_64-MPP-Rechner
1
SGI uv1000
256
Xeon
X7550,
2000 GHz
528 GB
X86_64-SMP-Rechner
7.2.3 Grid-Rechner
Anzahl Hersteller Typ
Anzahl
Prozessor
kerne
Hauptspeicher
Aufgabe
Grid Managementserver (Unicore, Monitoring
und Webserver)
3
Sun
X4100 und 2-4
X2200 M2
2-8GB
2
Diverse
Pentium III, 2-4
AMD Opteron
0,25-16GB Grid Managementserver (Monitoring) und
User-Interface
3
Sun
X4150
X4100
4-16GB
und 2-8
LCG Service Node
7.2.4 Hochleistungs-Graphik-System
Systemdaten
(Bei Systemen, die aus mehreren Komponenten bestehen,
stehen die Daten der einzelnen Komponenten in den
Zeilen darunter)
System
Hersteller
und System-Typ
GrafikHochleistungsCluster
Mit 10 Gbit-E
Am LRZ
vernetzte AMD
selbst
konfiguriert Opteron Systeme
5
GrafikHochleistungsCluster
Mit 10 Gbit-E
Am LRZ
vernetzte Intel
selbst
konfiguriert Xeon Systeme
3
Struktur
Aufgabe
Anzahl der
Prozessoren der
Komponente
Hauptspeicher
der
Komponente
FSC
Opteron 2400 MHZ
2
8 GB
Immersive 3D-Projektionstechnik (im
Visualisierungs-Labor) als RechenCluster für eine Holobench
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
Anzahl
der
Kompo- Typ der Komponenten
nenten
System
Hersteller
und System-Typ
189
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
SUN Fire
Remote
Visualisie- X4600
rungssysteme
1
Mit 10 Gbit-E
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
4
Mit 10 GbitE
vernetztes AMD
Opteron System
8
AMD Quad-Core Opteron
16
128 GB
Nvidia Quadro FX5800
Grafikkarte
240 GPUs
4 GB
Remote Visualisierung von umfangreichen Datensätzen, speziell im
Rahmen von D-GRID
Intel Xeon
System
Intel Xeon Quadcore
8
62 GB
GPGPU
System
FluiDyna
TWS
2
Nvidia Tesla Grafikkarte 240 GPUs
GPGPU Testsystem
4 GB
7.2.5 Server-, Benutzer- und Mitarbeiter-Arbeitsplatzrechner
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
ca. 350 PCs und andere Desktop-Workstations als Arbeitsplätze
ca. 18
Dell
Dual QuadCore 2,8 GHz
2
ca.
180
Dell
Intel Core i5 3,2 GHz
1
8 GB Benutzerarbeitsplätze LRZ
1-4 GB Mitarbeiter-Arbeitsplätze, incl. Operateure,
Hotline, Beratung, stud. Hilfskräfte, Windows
XP, VISTA oder Linux
190
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
ca. 90
Dell, FujitsuSiemens
Intel Core i5 M 2.66 Ghz
1
256MB - 4 Laptops für Präsentationen, Notebooks für
GB Mitarbeiter
ca. 25
Dell, Apple
Verschiedene
1-4
0,5-4 GB Benutzerarbeitsplätze für spezielle Geräte
(Multimedia ACAD-Arbeitsplätze, Scanner,
Multimedia, Videoschnittplatz)
30
Dell
Dual Core 3,2 GHz
1
4
Sun
SPARC Verschiedene
1
0,5-1GB Compute-Server (2 davon für allg. Nutzer, 2
davon LRZ-intern)
2-32
4-92 GB Zentrales Verbundsystem, Lokalsysteme (Datenbanken und OPACs)
4 GB Arbeitsplätze in Kursräumen
BVB- Server und Storage
21
Sun
SPARC Verschiedene
14
Sun
Verschiedene
1-8
46
FSC
Verschiedene
1-8
SUN
Storage FC und SCSI
Anzahl
Hersteller
Typ
8-32 GB Firewall, Suchmaschinen-Cluster
1-8 GB Suchmaschinencluster, OPACS, weitere Webdienste, Allegro Datenbanken, Windows und
Citrix Server, Mailserver, Netzüberwachung.
16 TB Storage für Datenbanken
Anz.
Proz.
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
35 Linux-Server für Maildienste
18
Advanced
Unibyte
Xeon bis 3,60 GHz
2-4
2-8 GB -
17
VMware
Xeon 2,53 GHz
1-2
1-4 GB -
Aufgabe
Anzahl
Hersteller
Typ
191
Anz.
Proz.
Hauptspeicher
Aufgabe
51 Linux-Server für Webdienste
1
Advanced
Unibyte
Xeon 2,80 GHz
4
21
VMware
Xeon 2,53 GHz
1-2
0,5-8 GB Moodle, Proxy, Apache, Zope
29
Sun
AMD Opteron
bis 2,59 GHz
1-4
8-16 GB Apache, Zope
Anzahl
Hersteller
Typ
Anz.
Proz.
2 GB Zope
Hauptspeicher
Aufgabe
18 Linux-Server für Datenbanken
14
VMware
Xeon 2,53 GHz
4
Sun
Anzahl
Hersteller
Typ
1-2
0,5-16 GB SQL
4
16 GB SQL
Anz.
Proz.
Hauptspeicher
Aufgabe
62 Linux-Server für e-Directory-Dienste
53
VMware
Xeon 2,53 GHz
1-2
1-6 GB SIM
9
Sun
1-2
2-8 GB SIM
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
33 Linux-Server für Konsolzugänge und Leitwarten-PCs
15
Avocent
-
1
1
VMware
Xeon 2,53 GHz
2
8
Dell
Pentium III bis 1,4 GHz
2
8
Dell
Pentium 4 3,20 GHz
1
Dell
Core2 Duo 3,00 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
18 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
5
FMS
2
3-7 GB Grafik-Cluster
2
Dell
Xeon bis 3,0 GHz
2-4
4
VMware
Xeon 2,53 GHz
1-2
2
Sun
2
2-8 GB Grafik-Test
0,5-2 GB Printing, Streaming
2 GB Printing
192
Anzahl
Hersteller
Typ
Anz.
Proz.
Hauptspeicher
Aufgabe
25 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
17
VMware
Xeon 2,53 GHz
1
Dell
Pentium III bis 1,4 GHz
3
Sun
AMD Opteron
bis 2,59 GHz
Anzahl
Hersteller
Typ
1-8
4-16 GB e-Learning, Webservice
8 GB e-Learning
0,5-32 GB Hosting
2
2-4
Anz.
Proz.
- KDE
2-8 GB VMware-Server, Bibliotheksverwaltung
Hauptspeicher
Aufgabe
66 Linux-Server für verschiedene Dienste
6
Advanced
Unibyte
Xeon 2,80 GHz
2-4
48
VMware
Xeon 2,53 GHz
1-4
1
Dell
Pentium III 1,26 GHz
9
Sun
2
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
7.3
193
Netzkomponenten
7.3.1 Router
Aktive
Ports
10GE
Aktive
Ports
1GE
Aktive
Ports
FE
Aktive
Ports
Ethernet
48
236
8
0
LRZ-Router 71
56
1
0
Anzahl
Hersteller/Typ
Einsatz
8
Cisco
6509
Catalyst BackboneRouter
4
Cisco
6509
Catalyst
1
Cisco 7206VXR
Anbindung
Triesdorf
0
2
0
0
1
Cisco 2821
Anbindung
Straubing
0
0
2
0
18
Cisco 1811/1812
Standortanbindung
0
0
42
0
7
Cisco 1721
Standortanbindung
0
0
0
14
6
Cisco 1811/1812
Site2Site
VPN
0
0
13
0
1
Cisco 801
ISDNBackup
0
0
0
2
2
F5 BigIP 8900
Server Load
4
Balancer
0
0
0
3
F5 BigIP 3400
Server Load
0
Balancer
11
0
0
51
Router gesamt
305
66
16
123
7.3.2 Switches
Anzahl
Hersteller/Typ
2
HP E8212zl
23
HP E5412zl
62
HP E5406zl
3
HP5308xl
175
HP E4208vl
44
HP E4204vl
verfügbare TP-Ports
verfügbare
ports
Glasfaser-
10/100/1000
10GE
100/1000
10GE
5.217
32
2.177
157
259
-
6
-
23.381
-
627
3
194
verfügbare TP-Ports
verfügbare
ports
21.410
-
3.232
-
24
-
-
-
240
-
-
140
686
-
10
5
1.704
73
-
40
1.188
-
12
-
HP3400cl-48G
618
-
6
8
4
HP 6410cl-6XG
-
16
-
8
51
HP 2824
25
HP 2848
2.415
-
9
-
10
HP E2610-48
51
HP E2610-24
117
HP E2610-24pwr
5.233
-
60
-
3
HP E2610-48pwr
8
HP E2610-24/12pwr
11
HP E2615-8-PoE
51
HP E2650
60
HP E2626
2
HP E2626-pwr
4
HP E2600-8-PoE
2
HP6108
7
Anzahl
Hersteller/Typ
177
HP 4108gl
111
HP 4104gl
1
HP 4000
5
HP E6600-24XG
5
HP E6600-48G-4XG
7
HP E2910al-24G
11
HP E2910al-48G
7
HP2900-24G
32
HP2900-48G
22
HP E2810-24G
14
HP E2810-48G
13
109
Glasfaser-
1
4.140
-
76
-
HP E2510
170
-
8
-
5
HP 2524
125
-
1
-
1
Cisco Nexus7000
-
-
-
256
1.126
Switches gesamt
66.919
121
6.225
617
7.3.3 WLAN-Komponenten
Anzahl
Hersteller/Typ
Verwendung
Standards
Radios
1077
HP MSM 310
Access Point
802.11b/g
1
195
Anzahl
Hersteller/Typ
Verwendung
Standards
Radios
14
HP MSM 310
Gebäudeanbindung
802.11a/g
1
39
HP MSM 320
Access Point
802.11b/g
2
296
HP MSM 422
Access Point
802.11b/g/n
2
12
HP MSM 422
Gebäudeanbindung
802.11n
1
1
HP MSC3200
Controller
6
HP M111
Wireless Client Bridge
802.11b/g
1
1445
WLAN gesamt
7.3.4 Netz-Server
Anzahl
Hersteller/Typ
Verwendung
Betriebssystem
4
Cisco ASA5540
VPN-Server
proprietär
1
Cisco 3030E
VPN-Server
proprietär
2
Cisco AS5350XM
Modem/ISDNServer,
SIP- proprietär
Gateway
1
Cisco ASA5580
Firewall
proprietär
2
12 GB
1
Meinberg Lantime
NTP-Server
Linux
1
32 MB
4
Oxygen X2201
DNS-Server
Linux
4
4 GB
1
Sun Fire X2100 M2 DHCP
Linux
2
2 GB
2
Oxygen X1101
DHCP
Linux
2
1 GB
2
Sun Fire X4100
Radius
Linux
4
2 GB
1
Sun Fire X4100
VoIP
Linux
2
4 GB
3
Sun Galaxy
VoIP
Linux
2
4 GB
2
Oxygen X3200
Natomat
Linux
4
4 GB
1
Sun Fire X4100
Natomat
Linux
4
16 GB
3
Sun Fire X4150
Secomat
Linux
8
64 GB
1
Dell PE2550
Accounting
Linux
1
2 GB
1
Dell PE2550
IDS
Linux
1
512 MB
1
Oxygen X3200
Monitoring
Linux
4
4 GB
2
Sun Fire X4150
Netzmanagement Linux
8
8 GB
1
Dell GX150
DSL-Server
Linux
1
256 MB
2
Sun Fire X2100
Bibliotheksproxy Linux
2
2 GB
𝟑𝟕
Server gesamt
Prozessoren Hauptspeicher
52

2010 - LRZ

Transcription

Similar documents

2006 - LRZ

Neuordnung der Berufe – Neuordnung des pädagogischen

02-03 News/Inhalt

IT-Sicherheit

2014 - LRZ

für Kleine und Mittlere Unternehmen am 26.05.2015 im Proviant

2008 - LRZ

2007 - LRZ

Die Folgen des Klimawandels – ZDF 2007

2015 - LRZ

Installationshandbuch Powerproject 12

E-Mailversand beim BVB

Freier Wissenszugang mit der Suchmaschine YaCy